These rows are a quirk of how Salesforce returns profile permissions, not a sign that anything is wrong in your org. Some standard objects, such as Document, aren't listed by the Salesforce Metadata API, so Gearset can't retrieve their permissions from an org. If the other side of the comparison does include those permissions, the profile's permissions for that object show as New or Deleted. This article explains what the rows look like, why they appear, and what to do about them.
What does this look like in Gearset?
In your comparison results you see object permission rows for a standard object, such as Document or ActionPlanTemplate, marked as New or Deleted. The object itself doesn't appear on either side of the comparison. The permissions belong to a custom profile.
You won't see them on a standard profile such as Admin, because Gearset doesn't show object permissions for standard profiles: Salesforce doesn't allow those permissions to be changed, so there's nothing to deploy.
Comparison results on the New tab, showing a Document Permissions row with metadata type Custom object permissions:
Why does this happen?
Object permissions in a profile depend on the object being retrieved at the same time, and Gearset can't always know that a standard object exists. The chain is:
Salesforce returns object permissions for a profile only when the object is retrieved in the same request. Salesforce's Metadata API documentation puts it this way: when retrieving object or field permissions, you must also retrieve the associated object.
Gearset finds out which objects exist in an org with a Metadata API call,
listMetadata. Some standard objects, includingDocument, aren't returned by that call, and Salesforce doesn't let a wildcard stand in for all standard objects: each one has to be named.Because Gearset doesn't know the object is there, it never asks for it, so the profile Gearset retrieves from the org comes back without permissions for that object.
If the other side of the comparison does hold those permissions, for example a repository that was seeded with a tool other than Gearset, Gearset shows the difference as a
NeworDeletedpermissions row.
The permissions are still in your org. A Workbench retrieve that names both the object and the profile in the same package.xml returns the profile with its Document permissions included, because the object is part of the same request.
What should I do?
Nothing needs fixing in your org. To keep the rows out of a deployment:
Leave the permission rows unselected when you choose what to deploy.
Use the
Difference type,Metadata type, andNamecolumn filters to find and skip them quickly. See Exploring comparison results for how the filters work.
If you see this for an object that isn't covered here, or the rows are blocking a deployment, please send a message to our support team, who will be happy to help.