It is Adam Torman’s excellent post about dealing with permissions by Metadata API. I only have a few things to add (or more accurately, to complain about MdAPI):
- Despite the similarity between the permissions available for both Profile and Permission Set, certain items can only be put through MdAPI via one, but not the other metadata entity. The most prominent example is the user and system permissions. In essence, the element <userPermissions> is a non-starter with Profile; it’s only available with Permission Set.
- If you construct the package xml by hand, like what I prefer to do sometimes, make sure you group elements together – don’t mix them up with other sibling elements. For instance, if you have several <tabVisibilities> to include and they’re separated by other things, you’d get a “duplicate” error message.
- I wonder why there isn’t a comprehensive list of user permissions in the documentation? There’s a long list of permissions, and without documentation it’s nearly impossible to do things manually. Maybe that is just what SFDC is trying to discourage – create metadata files by hand – in order to avoid problems. But why would you go through all the clone-change-retrieve trouble just so you can have a reusable metadata file to deploy with only minor changes? Wouldn’t a quick manual tweak be more efficient for advanced admins?