16 September 2013

What's in a profile name? Well, apparently a lot! Migrating standard profiles using the MdAPI

I had an interesting scenario come up the other day while trying to migrate some permissions on both standard and custom profiles using the Metadata API (MdAPI).

It turns out that what we call the 'System Administrator' standard profile actually maps to the Admin.profile file in the MdAPI. This means, when retrieving the System Administrator profile, you'll find all of the permissions and settings in the Admin.profile file in the profile directory.

Here's where it goes a little sideways. If you create a custom profile called 'Admin', there's some ambiguity when you try to migrate permissions for the 'System Administrator' standard profile which goes by the same name.

As a result, given the right order of operations, the System Administrator profile will be ignored when migrating permissions for the custom Admin profile using the MdAPI.

The same is true for any of the standard profiles:

Standard Profile Name in the User InterfaceStandard Profile File Name in the MdAPI
System AdministratorAdmin.profile
Standard UserStandard.profile
Marketing UserMarketingProfile.profile
Contract ManagerContractManager.profile
Solution ManagerSolutionManager.profile
Read OnlyReadOnly.profile
Customer Portal ManagerCustomerManager.profile
Customer Portal UserCustomerUser.profile
High Volume Customer PortalHighVolumePortal.profile
Partner UserPartner.profile
Authenticated WebsitePlatformPortal.profile
Standard Platform UserStandardAul.profile

Give it a try - steps to reproduce:
  1. retrieve 'Admin' profile in MdAPI which retrieves the 'System Administrator' profile
  2. add an assigned app visibility to the .Admin profile file and deploy
  3. System Administrator profile updates with additional app visibility
  4. clone System Administrator profile and call it 'Admin'
  5. retrieve 'Admin' profile in MdAPI which retrieves the cloned/custom 'Admin' profile thereby ignoring the 'System Administrator' profile
  6. add an assigned app visibility to the .Admin profile file and deploy
  7. custom Admin profile updates with additional app visibility, System Administrator profile is ignored
Use the following steps to find out if you already have any custom profiles with one of these names and rename them:
  1. log into workbench
  2. add the ability to query parent relationships by going to Workbench > Settings and enabling 'Allows SOQL Parent Relationship Queries' before selecting 'Apply Settings' button at the top of the screen 
  3. run the following query by going to queries > SOQL Query:

SELECT Profile.Id, Profile.Name FROM PermissionSet WHERE
(Profile.Name = 'Admin' OR
 Profile.Name = 'Standard' OR
 Profile.Name = 'MarketingProfile' OR
 Profile.Name = 'ContractManager' OR
 Profile.Name = 'SolutionManager' OR
 Profile.Name = 'ReadOnly' OR
 Profile.Name = 'CustomerManager' OR
 Profile.Name = 'CustomerUser' OR
 Profile.Name = 'HighVolumePortal' OR
 Profile.Name = 'Partner' OR
 Profile.Name = 'PlatformPortal' OR
 Profile.Name = 'StandardAul')

As a result of this edge case, the best practice is to name custom profiles something different from what the MdAPI understands as a standard profile name in order to effectively migrate permissions between environments.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.