To grant a user access to an object, associate an ObjectPermissions record with a\n PermissionSet that’s assigned to a user. ObjectPermissions records are only supported in\n PermissionSet, not in Profile.
\n\ncreate(), delete(), describeSObjects(), query(), retrieve(), update(), upsert()
\n\nAs of Summer ’20 and later, only users with the View Setup and Configuration permission\n can access this object.
\n\n| Field Name | \n\nDetails | \n\n
|---|---|
| ParentId | \n\n\n
| \n\n
| PermissionsCreate | \n\n\n \n\n | \n\n
| PermissionsDelete | \n\n\n
| \n\n
| PermissionsEdit | \n\n\n
| \n\n
| PermissionsModifyAllRecords | \n\n\n
| \n\n
| PermissionsRead | \n\n\n
| \n\n
| PermissionsViewAllFields | \n\n\n
| \n\n
| PermissionsViewAllRecords | \n\n\n
| \n\n
| SobjectType | \n\n\n
| \n\n
Some user permissions have dependencies on object permissions. For example, if a\n permission set has the “Transfer Leads” permission, it also has\n “Read” and “Create” on the leads object.
\n\nYou can query from ObjectPermissions up to the parent PermissionSet object. For\n example:
\n\nSELECT Parent.Name, Parent.PermissionsTransferAnyLead, PermissionsRead, PermissionsCreate\nFROM ObjectPermissions\nWHERE SobjectType = 'Lead'
When using SOQL to query object permissions, be aware that some object permissions are\n enabled because a user permission requires them.
\n\nThe exception to this rule is when “Modify All Data” is enabled. While it\n enables all object permissions, it doesn’t physically store any object permission\n records in the database. As a result, unlike object permissions that are required by a\n user permission—such as “View All Data” or “Import\n Leads”—the query still returns permission sets with “Modify All\n Data,” but the object permission record will contain an invalid ID that begins\n with “000”. This ID indicates that the object has full access due to\n “Modify All Data” and the object permission record can’t be updated\n or deleted. To remove full access from these objects, disable “Modify All\n Data” and then delete the resulting object permission record. This ensures that\n when using SOQL to find all the objects that have full access, it returns all objects\n that have this access regardless of whether it’s due to “Modify All\n Data” or because an administrator set full access.
\n\nFor example, the following will return all permission sets that have\n “Read” on the Merchandise__c object, regardless of whether it’s\n explicitly defined on the object or implicitly defined through “Modify All\n Data.”
\n\nSELECT Id, Parent.label, SobjectType, PermissionsRead,\n Parent.PermissionsModifyAllData, ParentId\nFROM ObjectPermissions\nWHERE PermissionsRead = true and SobjectType = 'Merchandise__c'
SELECT Id,Name,PermissionsTransferAnyLead,\n(SELECT Id, PermissionsRead from ObjectPerms where SobjectType='Lead')\nFROM PermissionSet\nWHERE PermissionsTransferAnyLead = true
As a result, it’s possible to traverse the relationship between the PermissionSet and\n any child-related objects (in this case, ObjectPermissions). You can do this from the\n PermissionSet object by using the child relationship (ObjectPerms, FieldPerms, and so on) or\n from the child object by referencing the PermissionSet with Parent.permission_set_attribute.
\n\nIt’s important to consider when to use a conditional WHERE statement to restrict the result set. To query based on an attribute\n on the permission set object, nest the SOQL with the child relationship. However, to\n query based on an attribute on the child object, you must reference the permission set\n parent attribute in your query.
\n\nSELECT Id, Name, PermissionsModifyAllData,\n(SELECT Id, SobjectType, PermissionsRead from Objectperms)\nFROM PermissionSet\nWHERE PermissionsModifyAllData=true
SELECT Id, SObjectType, PermissionsRead, Parent.Id, Parent.Name, Parent.PermissionsModifyAllData\nFROM ObjectPermissions\nWHERE SObjectType='Merchandise__c'