We’re Here to Help!!

Find A Solution, Learn Best Practices & Get Support 24x7

Demystifying Profile deployments

Follow

Profile deployments have always been super painful in Salesforce. Flosum eases that issue to a great extent but there is still a lot of confusion on the nitty gritties of profile deployments. This article deals with all the questions we have encountered over our years of experience. 

How do profiles work in Flosum?

RETRIEVAL - When Flosum retrieves a profile from the source org, the entire XML of the profile as published by Salesforce is retrieved. Metadata API, however does not return False values in some cases, only values marked as True. Hence if you mark a value as False, it might not be retrieved and deployed. The details are below for each situation. 

DEPLOY - On the Flosum Deployment screen, there is a setting - "Deploy profile settings only for components included in the deployment". This setting is checked by default. If your Deployment consists of Profiles and other components, then with this setting checked, the deployment will extract only the settings relevant the other non Profile components in Deployment from all the profiles and deploy just those settings for each Profile. Let's explain this with an example. 

Say you have 3 profiles in your Deployment and among other things, each of them has the FLS settings for 2 custom fields in them. Suppose one of those custom fields is only part of the Deployment and not the other one. Then if checkbox is checked when deploying, the FLS settings for only the custom field that is in the Deployment will be migrated to the target org, NOT of the custom field that is not in the Deployment. 

In above scenario, if the checkbox on the Deployment screen was unchecked, then the FLS settings for both the custom fields would be deployed to the target org for all the 3 profiles. 

Salesforce does not change the Last Modified date of profiles even when it has been changed by an FLS change in a custom field for example. You might need to know its last modified date to pull it or use a 0 day snapshot. 

Component types that impact profiles

CUSTOM FIELDS - Field Level Security(FLS) for all fields is stored in profiles. So if you are deploying a custom field and want all its FLS settings to be deployed also, you need to deploy each of the profiles that have been given FLS settings for that custom field. Disabling profile access to a field can be deployed using Flosum

CUSTOM OBJECTS - CRUD settings for all objects are stored in profiles. So if you are deploying a custom object and want all its CRUD settings to be deployed also, you need to deploy each of the profiles that have been given CRUD settings for that custom object. Disabled CRUD settings can also be deployed(if all settings for an object are disabled, the Metadata API does not pick up the object at all and hence this scenario cannot be deployed). 

PAGE LAYOUTs - In order to deploy page layout assignments, you need to deploy the page layout, the record type it is associated with and the profiles together if the checkbox "Deploy profile settings only for components included in the deployment" is checked. Just including the page layout and profiles only will not deploy the assignment if there is a record type dependency as well. 

If there is no record type dependency, then just deploying the page layout and the associated profiles will deploy the page layout assignments. 

RECORD TYPES - If you just deploy a record type without any of its associated profiles from the source org, this record type will not be available to any of the profiles in the target. Deploy the record type along with its associated profiles with the checkbox "Deploy profile settings only for components included in the deployment" checked and the record type will be available to the profiles as well. 

CUSTOM APP / CONNECTED APP - Deploy the Custom App along with its associated profiles with the checkbox "Deploy profile settings only for components included in the deployment" checked and the Custom App will be available to the profiles as well. 

CUSTOM TAB -  In the case of Custom Tab, the Off setting can also be migrated. So if the setting is set to Default On or Default Off or Tab Hidden, they can all be migrated if the Custom Tab and the relevant profiles are in same Deployment and the checkbox "Deploy profile settings only for components included in the deployment" is checked. 

APEX CLASS / VISUALFORCE PAGE - For both classes and visualforce pages, profile access can be granted and revoked. Keep the class or visualforce page in the Deployment along with the relevant profiles. Doing the deployment with the checkbox "Deploy profile settings only for components included in the deployment" checked, should allow to grant and revoke access both(Managed package class and Visualforce permission settings cannot be deployed) . 

NAMED CREDENTIALS / EXTERNAL DATA SOURCE / CUSTOM PERMISSIONS -  For all these component types, profile access can be granted and revoked. Keep the component in the Deployment along with the relevant profiles. Doing the deployment with the checkbox "Deploy profile settings only for components included in the deployment" checked, should allow to grant and revoke access both. 

FLEXIPAGE - Please refer to this link

Deploying Administrative Permissions/General User Permissions

In order to deploy the settings in the Administrative Permissions/General User Permissions section of any profile, we have to deselect the "Deploy profile settings only for components included in the deployment" checkbox in the Deploy screen and have the profile as part of the Deployment. Doing this will deploy the profile as a whole. False values cannot be deployed. 

Deploying IP Logins

In order to deploy the IP Login records of any profile, we have to deselect the "Deploy profile settings only for components included in the deployment" checkbox in the Deploy screen and have the profile as part of the Deployment. Doing this will deploy the profile as a whole. Any IP login records in the profile in target org that do not exist in the source profile will be deleted and only the ones that exist in the source org profile will exist in target org profile after deployment. 

Deploying Login Hours

To deploy the Login Hours associated with any profile, we have to deselect the "Deploy profile settings only for components included in the deployment" checkbox in the Deploy screen and have the profile as part of the Deployment. Doing this will deploy the profile as a whole including the login hours.  

Deploying Session Settings and Password Policies

To deploy sessions settings and password policies, use the "ProfilePasswordPolicy" and "ProfileSessionSetting" objects. The profile needs to exist in the target org but does not need to be part of the Deployment to deploy these settings. 

Deploying a brand new profile

If you need to deploy a brand new profile in its entirety, then  please make sure to deselect the "Deploy profile settings only for components included in the deployment" checkbox if you do not want to include all the other components it references as part of the Deployment. This would be the most efficient way to deploy a new profile. 

 

Other Points 

If you check the "Deploy profile settings only for components included in the deployment" checkbox , only settings related to other components in the Deployment will be deployed. No other profile settings, even the ones not related to any component, will be deployed. 

Print Friendly and PDF
Was this article helpful?
0 out of 0 found this helpful

Comments