All Collections
Guides on deploying specific metadata types
New custom field with its field-level security settings
New custom field with its field-level security settings

Quickly deploy a new custom field with its FLS

Jason Mann avatar
Written by Jason Mann
Updated over a week ago

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, Profile and Permission 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 field and Custom field permissions.

  • I tick the box for the Custom field to 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 permissions line item, the diff viewer below shows me the Permissions view this is an easy way to visualise what profiles will be affected by this deployment. The XML viewer will 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 NEXT to check the problem analysis and environment variables, before clicking Pre-deployment summary to see the Summary of items to deploy, then click DEPLOY NOW to 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 the Profiles and permissions group. Within that group, each of the individual Profile: Field level security changes 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 field and the Profiles and permissions section 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 NEXT to see the Summary of items to deploy, then click DEPLOY NOW to 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).
โ€‹

Did this answer your question?