Mass Update Profiles with Dataloader


As an admin, we check a lot of boxes on the profile and permission set user interfaces. It can be daunting for admins of large organizations with lots of profiles or permission sets. Wouldn’t it be easier if you could update / insert Field Permissions, Object Permissions, Custom Permissions, App Access and more? Well, you can do just that!

There are a few important objects to be aware of:

  • PermissionSet – This object is an object that joins PermissionSets and Profiles. This is the object that allows for you to insert the records.
  • FieldPermissions – Contains field read access, edit access for profile or permission set. The absence of a record means the field is not accessible by the profile.
  • ObjectPermissions – Object Permissions for a profile or permission set. Absence of a record means that the object is not accessible by the profile.
  • SetupEntityAccess – Contains Application, Custom Permission, Apex Class, Visualforce page and Conneced Application access for a profile or permission set. Absence of a record means that no access is extended.

Now that you know the important objects, let’s do an exercise!

Go ahead and grab a new developer org to walk through this exercise. We will be using the profiles that they create out of the box.

Run the below query by going to workbench.developerforce.com:

SELECT Id, IsOwnedByProfile,IsCustom, Label, Profile.Name
FROM PermissionSet
ORDER BY IsOwnedByProfile

You should get results back like the below. Notice that the “IsOwnedByProfile” field indicates that the permission set is owned by a profile. “IsCustom” indicates if it is a standard profile.

There are some things you cannot insert for standard profiles, for example, object permissions cannot be modified for system administrator because it has the “Modify All Data” permission. The system has these restrictions for your protection. Don’t be surprised if you get an error.

We want to make a modification to profiles that start with “Custom:” (the profiles that come with your dev org. Run the below query to get them:

SELECT Id, IsOwnedByProfile,IsCustom, Label, Profile.Name
FROM PermissionSet
WHERE Profile.Name LIKE 'Custom:%'

Go ahead and create a new field on account called “Tier” of type picklist. Values should be “Gold”, “Silver” and “Bronze”. When selecting Field Level Security, remove all values. We’re trying to emulate that this is a new field in a higher environment such as a field that was moved to UAT or Production.

Now, in a spreadsheet, we are going to add the values from the above query, plus four fields and values:

  • SobjectType – “Account”
  • Field – “Account.Tier__c” – this is the Sobject + the field API Name
  • PermissionsRead – “true” – this extends read access
  • PermissionsEdit – “true” – this extends edit access

Your spreadsheet should look like the below:

Now go to Workbench, select “Data” from the menu and “Insert.” Find the FieldPermissions object and select your file for upload. Make sure to map the “Id” field to the “ParentId” field upon mapping. All other fields should be automatically mapped. Confirm your insert. You should see three successful record creations. Let’s confirm!

Navigate to object manager, find the Account object, select the “Tier” field and “Set Field-Level Security” button.

Success!

Now, this may seem like quite a bit of work for just three profiles/permission sets, but when you have a net new field that you need to deploy to dozens of profiles, it can be a real time saver, especially when migrating a field from environment to environment.

You can also use this same process to remove FLS, OLS, etc. This is really handy for when deprecating fields too!

Some errors you might encounter and how to resolve

Insufficient Access Rights on Cross-Reference Id – This means that the profile or permission set does not exist. Make sure that the record exists. If the record exists, make sure you queried the “PermissionSet” object and not the “Profile” object. The record Ids are different.

Duplicate Value Found:┬áDuplicates Value On Record With Id: – This means that the record already exists. You should make sure to query the FieldPermissions / ObjectPermissions / SetupEntityAccess objects and change the existing value.

How much time has this saved you? Add your comments below!

Leave a comment

Your email address will not be published. Required fields are marked *