We're deploying from Stage to Prod via VSCode and package.xml. We're concerned of overwriting certain existing Profiles on Production. We haven't updated Stage from Prod in too long.

We still need to deploy those Profiles as they relate to the new fields and other metadata in our package.xml

If we use SFDX (we are thinking of retreating to ant migration for this) still, we need to be assured: A) that anything that doesn't exist in the Profile on Stage, does not remove it from Profile on Prod B) that Profiles in Prod will only receive the changes associated with fields in our package.xml

Please help, as I cannot find official documentation for this most important topic.

2 Answers 2


Profiles only take on changes that are specified in the XML. If you don't specify a permission, it remains whatever it was before the deployment. This allows you to build incremental changes to permissions across multiple packages.

That said, as you move to DX, it may be time to start migrating towards Permission Sets instead. These are far more flexible, can be applied to many users at once, users can have more than one assigned to them, and they work better with packaging.

  • When you say Profiles only take on changes that are specified in the XML, do you mean package.xml? Or the XML that makes up the Profile definition? Mar 3, 2022 at 20:13
  • 1
    @SwisherSweet I mean the profile XML files. The package XML only specifies which files should be included in the deployment.
    – sfdcfox
    Mar 3, 2022 at 21:51

Profile deployment and tracking is hard, use permission set as @sfdcfox had mentioned.

Additionally having a version control system is a must with any software development, usually that is overlooked with salesforce development.

And CI-CD helps in automating all the manual tasks, there are many online tools like circle CI or Jenkins that is open source offers lot of configuration.

  • Also look at the open source version CumulusCI that is build by Salesforce Org and offers great flexibility. David Reed has presented amazing session on that.

  • Setting up continuous integration is easy, but to get it right as per your requirement or company takes sometime. Once setup, speeds up the whole development process and GIT offers nice history of changes in case something goes wrong.

  • With CI-CD in place, additional benefit is that we can :

    • Integrate static code analysis with commits as well.
    • Have nightly jobs to run all unit tests for production in case tests fail.

You must log in to answer this question.

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