A Neat Trick For Deploying Security Settings in Change Sets
Have you ever used a change set to deploy, only to find things like record types, field level security, or object access didn’t carry over to production? I came across a neat trick over the weekend that I wanted to pass on.
All of these things are technically profile settings, so you must include the profile in the change set unless you want to reconfigure everything manually in production!
From Salesforce’s Change Sets Best Practices documentation:
Add permissions and access settings to outbound change sets
Adding profiles or permission sets to outbound change sets allows administrators to migrate permissions for users so they can access the new functionality. Profiles contain access settings for more components than permission sets, including page layouts, record types, and tab settings. However, permission sets contain access to standard object permissions, standard field permissions, and user permissions (such as “API Enabled”).
Something I’ve recently been shown is to deploy everything with the System Administrator profile. Once I have everything working as expected, I redeploy all of the layouts, custom fields, record types, classes, and Visualforce pages with the profiles that need access to those assets.
I’ve found this trick makes my deployments that much easier, and hopefully it can make your life easier too!
Matt, that’s a really good tip. I’ve always done multiple change sets if there’s custom fields or record types involved. Usually the first change set involves only the fields, record types, and page layouts. Usually, I do any manual configuration and then any apex or visual force changes in another change set.
Not sure why I do deployments that way though, I imagine there was a problem at some point and I’ve never tried deploying permissions or profiles since.
Pingback: Deploying Custom Objects via Metadata – Matt McGuire