function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

How to query Object Permissions in Profile

I want to migrate Object Permissions (Object CRUD settings) setup in a Sandbox to another Sandbox.

We normally migrate data from one environment to another through the API, with a tool called "XLConnector".

What is the sObject that I should query in order to get the "Object Settings permissions" setup in a specific Profile?

Thank you very much.
Best Answer chosen by EdCode
AbhishekAbhishek (Salesforce Developers) 
You can deploy profiles and permission sets safely, provided you keep a few things in your mind:

1) Profiles work like junction objects when retrieving them from salesforce. In other words, if you ask for the Admin profile and include Account and Opportunity in the retrieve, the Admin profile XML will contain ObjectPermissions, FLS, RecordType Visibility for these two objects and UserPermissions only. No Class Access, Page Access etc because you did not request them in the retrieve. So... if you migrate this Profile XML over, obviously you will not get desired results.

2) Profiles merge on the server. In other words, if you have Object Permission for X set to RWD and you migrate the updated Object Permission for X, it will override existing permissions. But, as part of that migration, if you add Object Permission for Y, it will be added on as well.

3) Profiles are never created in Salesforce. Let me clarify... they are never created; they are cloned and then overridden. So, if you are creating a Profile using the API, you are essentially cloning the PlatformUser profile or StandardUser profile (depending on license type) and then overriding it. There might be artifacts of that Profile in your new Profile.

4) Some Profile sections, like AppVisibility and TabVisibility indicate negative values by absence. This is the most dangerous aspect of Profiles that deserves the most scrutiny. Try this: Retrieve the profile XML along with CustomTabs. Back that up. Now, change the TabVisibility for your favorite tab to Hidden. Now, re-retrieve your XML. Execute a comparison between your Profile XML. You will see that the TabVisibility is missing in your second retrieve. So, if you migrate that to another Org (sandbox or production), you are not going to turn off the Tab as expected because the XML is missing (remember that Profile XML merge).

As long as these basic rules are kept in mind, you are absolutely ready to migrate profiles or permsets anywhere you want. It seems daunting but it is not that bad.

For further reference, you can check the below,

Let me know if it helps you and close your query by marking it as solved so that it can help others in the future.