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
    Commented Sep 28, 2014 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
    Commented Apr 22, 2016 at 10:40

4 Answers 4


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?


Migrating of profiles and permission sets can be quite the pain. Especially if you're working with managed packages. Although I don't do as many profile migrations now, the best tool I found for the task was BlueCanvas. This allowed me to log in to the origin org and destination org then pick the profiles to migrate as well as the individual permissions (field/ object etc) that I wanted to include in the migration for both profiles and permission sets.

Some quirks I noticed when using it:

  • It can freeze when moving large amounts of profiles simultaneously. To get around this I usually ended up migrating them one or two at a time. If you have tens of profiles this may be an issue but I'm not sure you would need that many
  • It is mostly used for object, field, class and page access. Access for things like app permissions don't come across
  • Tab Visibility access doesn't get migrated either.

Although it's got quirks I thought it was a pretty good tool considering how much of an issue this is in the community.

**Disclaimer I do not work for, nor am I associated in any way to Blue Canvas


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

  • 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
    Commented Mar 29, 2020 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]

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .