Gearset makes it really easy to move profile and permission changes along with modifications to the structure of your orgs. In this short guide we'll run through how to deploy a new custom field and apply its field-level security (FLS) in one go.
Creating the new custom field
For this document, I created a new custom field called New Checkbox Field on the Account object in my developer org, and set some appropriate field-level security for my user profiles.
Deploying the field and its field-level security settings
To begin, I'll compare the org the change was made in, to the target org to deploy the changes to. In this case, my developer org is the source, and my staging org is the target.
I'm using the default metadata filter, as this includes
Custom object,ProfileandPermission set, which I'll need to deploy my changes.
In the Gearset comparison results, searching for the API name (field name) of New_Checkbox_Field, I can see my new
Custom fieldandCustom field permissions.
I tick the box for the
Custom fieldto add it to my deployment package.There are now two alternative ways to deploy the field-level security (FLS) permissions.
Option 1: All at once, using 'Custom field permissions'
If I want to deploy the FLS for all profiles that are affected by the new custom field, I can simply tick the box for the
Custom field permissions.If I click on the
Custom field permissionsline item, the diff viewer below shows me thePermissions viewthis is an easy way to visualise what profiles will be affected by this deployment. TheXML viewerwill show the exact XML differences - I can confirm and be confident of what will change in which profiles.Permissions view example
XML view example
I can see I'm only changing this small portion of each profile, so I can be confident I'm not going to overwrite any other changes.
Click
NEXTto check the problem analysis and environment variables, before clickingPre-deployment summaryto see theSummary of items to deploy, then clickDEPLOY NOWto deploy the changes.
Option 2: Choosing individual "Profile: Field level security" items
To view individual FLS settings for the
Custom field, I can expand it out by clicking the black arrow next to its name, and then expand out theProfiles and permissionsgroup. Within that group, each of the individualProfile: Field level securitychanges are listed for this new field.To view the detail for any of these FLS changes in the diff viewer, I can click on it. I can see this is the same as in option 1 above, but here the change is listed separately for each profile.
To deploy all the FLS changes, I could simply select the
Custom fieldand theProfiles and permissionssection to include them in my package.
The key difference with this option as opposed to option 1 is that if I want to deploy the FLS change for some profiles but not all (for example, if I initially only want to make the change to the Admin profile, for testing), I can select individual FLS lines, rather than the whole section.
As with option 1, click
NEXTto see theSummary of items to deploy, then clickDEPLOY NOWto deploy the changes.
That's it! The new field has now been deployed and its FLS set, all in one go. The deployment is recorded in my Gearset deployment history if I need a reference later on.
Deploying the false field permissions
A note on deploying custom field permissions or FLS where both the readable and editable permissions are false.
If the metadata returned for a field has the following permissions:
<editable>false</editable>
<readable>false</readable>
Gearset is designed to suppress the resulting XML and does not show this field permissions in the comparison results at all.
The technical reason for this is that false permissions can be returned as not existing by the Salesforce Metadata API, therefore rendering all the field permissions that do not exist would be confusing to display. For this reason, Gearset is intentionally not showing the false field permission, even if it is explicitly returned within the metadata.
An example of the impact from this is that since the FLS would show as deleted rather than changed (since we're not returning this FLS in the source) it won't be deployed by a CI job unless you specify that the CI job needs to deploy deleted changes (this behavior also extends to Apex Class Permission).
