Salesforce has multiple options to deploy profiles from one org to another. Changesets (come with limitations). Standard Objects are not supported with Change Sets. So if the user is trying to migrate Profiles that have standard object permissions, Change Sets is not an option and would have to select one of the Metadata API deployment options (Workbench, Salesforce CLI, ANT Migration tool, and Visual Studio Code ). Salesforce CLI, ANT, Visual Studio Code will need additional setup and configuration before you get started on deployment. This article details the steps that are specific to deploy 'Profile Permission set' using the Workbench tool.
**IMPORTANT: In order to deploy the profiles from one org to other via the available deployment tools, please work with your Admin or, Developer who is familiar with the deployment tools and best practices to avoid any disruptive changes.
Notes: Please refer to the Usage section in the document to learn about considerations for profile metadata.
A walkthrough Video: Using Workbench to Get and Update Organization Metadata is available in the Additional Resources section. The video demonstrates how to navigate Workbench to retrieve and deploy org metadata.
Step 1: Create a Package.xml Manifest
A package.xml manifest file tells Workbench which metadata components to retrieve. The following sample package.xml file retrieves profile permissions for the Account object, a specific Permission Set, and a named Profile. Replace PermissionSetName, ProfileName, and the API version (xx.0) with your actual values before using this file:
<Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>Account</members> <name>CustomObject</name> </types> <members>PermissionSetName</members> <name>PermissionSet</name> </types> <types> <members>ProfileName</members> <name>Profile</name> </types> <version>xx.0</version> </Package>
To include multiple objects, add additional member elements under the CustomObject type as shown below:
<types> <members>Account</members> <members>Case</members> <name>CustomObject</name> </types>
Note: The above package.xml is a sample only. The Salesforce package.xml Builder can help automate this process, but it is a publicly available tool and is not a Salesforce-approved tool.
To retrieve an existing package.xml manifest for all components in your org using Workbench: log in to your source org, select Environment (Prod/SBX), click Login to Salesforce with OAuth, and select All Components.
Step 2: Retrieve Metadata from the Source OrgRetrieve the metadata using Workbench:
Step 3: Deploy Metadata to the Target Org
References:
Profile Metadata reference (with package.xml examples towards end)
mdapi commands
000384061

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.