What are your best practices in migrating profiles and permission sets? I have been trying to migrate them from one org to another org. However it is not working. Do you have to move the entire code base at once to migrate the profiles. Please advise.

  • possible duplicate of Can including a profile in a changeset remove a permission/FLS? – Ashwani Sep 28 '14 at 16:22
  • One best practice is to manually check all the profiles and permission sets in the target org have the correct permissions after deployment. This applies whichever method of deployment you use as it seems like none of the tools give a perfect result on deployment of these types of metadata. – Dave Humm Apr 22 '16 at 10:40

Moving profile depends on difference of profile in Sandbox and the production.

If you are doing with continuous integration process then you can move profile by changeset.

To move profile with changeset you must have source profile same as target organisation and added new permissions and modified permissions. If there is some permission which is missing in source profile then there can be chances of unexpected behaviour. Login IP ranges, FLS can be reset by doing this. So, carefully examine permissions then deploy.

It is always preferred to make those changes live manually in production instead of changeset. It is difficult to know which access changed.

Profile permissions always need to be examined. Each component in organisation is part of Profile whether it is class or vf or a field.

A profile moved in other environment must have accessibility setting for all components for all component exist in target environment.

Copied from: Can including a profile in a changeset remove a permission/FLS?

| improve this answer | |

For permission sets, it's pretty easy to move them using dataloader.

This article might be of use: https://help.salesforce.com/articleView?id=000322112&language=en_US&type=1&mode=1

| improve this answer | |
  • Welcome to Salesforce SE! While this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – identigral Mar 29 at 3:36

Migrating profile/perm sets is an endeavor on its own. Technically you can create a package.xml with required profile/permsets names and corresponding entities (if you are migrating field perms the include those fields) and deploy that full package to target org.

That you can accomplish using any of the metadata migration based tools like workbench/ant migration/realfire and others.

Another way is to use profile comparison tools which compares the profiles/perm sets for required entities, and lets you copy over the perms.

Realfire provides profile/perm sets comparison feature which allows you visualize, copy permissions across connections, and save them. This process provides most easiest approach but if you have CI/CD, you will have to refresh that backup of metadata after making changes as you will be making changes to access in target org directly.

enter image description here

[0] https://www.datasert.com/products/realfire

[Disclaimer: I'm part of the team that builds Realfire]

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.