Skip to main content
Permission sets, Permission set groups, and Permission set assignments - retrieve and deploy

How to deploy a new Salesforce permission set and other components

Claudia McPhail avatar
Written by Claudia McPhail
Updated over a week ago

Deploying a new Permission set, Permission set group or Permission set assignment is straightforward using Gearset. Depending on whether you are deploying these manually (using Compare and Deploy) or automatically (using Pipelines) the user experience will be slightly different.

Both processes are described below.

How to deploy a new Permission set manually

After creating a new Permission set in your source org (for example your development sandbox), you will need to deploy it to your testing environment.

  1. Navigate to the Compare and Deploy page in Gearset, and select your source and target orgs.

  2. Check that you have your source, target and filter selected. Click "Compare now".

  3. Choose a filter or select your metadata- if you don't already have a custom filter that you use for Permission updates then you can use Gearsets' "Default profiles comparison" which includes everything you need for deploying Permission sets and Profiles.

  4. In the comparison you will be able to easily filter for the new Permission set you have created - look under "New items" and then filter for Permission sets and user permissions for that new Permission set.

    If you have other new items you can filter for these as well using the same method - permissions do not have to be deployed separately to other metadata types.

  5. Once you have found the components you would like to deploy to the target org select them and click "Next".

  6. Gearset will now run Problem Analysis and Static Code Analysis.

  7. Problem Analysis will highlight and remove references in the permission set to components that either don't exist or are not enabled in the target environment.

  8. After reviewing the suggested fixes and warnings you can proceed to the "pre-deployment summary" screen, where you will see a summary of what you are deploying.

    This should be your new Permission set, the user permissions for that new Permission set, and any other components you're deploying at the same time.

  9. When you're ready to validate your changes you can click the "Validate deployment" button.

    After the validation has run you will see a list of the validated components on screen. You can either immediately deploy this to your target org, or schedule the deployment for a later time or date.

    Click "Deploy now" to deploy your changes.

A note on Permission sets and Pipelines

If you have a Pipeline set up in Gearset you will be enjoying automatic validation, testing and deployments.

To have your permission sets deployed as part of your Pipeline you will need to make sure that they're included in your filters - when setting up your Pipeline you will be able to select them for inclusion in your CI jobs.

If you would like some help setting up your Pipeline or have questions about how else you can utilize automation in Gearset please get in touch with the team via the in-app chat.

How to deploy Permission sets and Permission set Groups with a Pipeline

If you need to deploy a Permission set Group as well as a Permission set you can follow these steps.

  1. Start by creating your feature branch.

  2. Next click 'Start comparison'. Once the comparison loads select Permission Set and Permission Set Group from the available metadata on the left hand side.

  3. Select your Permission set, and the Permission set group.

  4. Add a commit message, and commit your changes.

  5. Create a pull request to validate your changes against the first environment in your Pipeline.

  6. The delta of your new changes will now validate against the target environment. If you want to see exactly what changes will be deployed you can click "view details".

  7. This will show you your validated components. To see them in even more detail you can click "back to results".

  8. On this screen you can see the xml that makes up your settings and subcomponents which are about to be deployed to the target environment.

  9. After you are satisfied that the changes are the ones you're intending you can go through your normal process of reviewing the pull request and approving it.

  10. After approval the Permission set and Permission set group can be promoted.

How to deploy Permission set assignments

Permission set assignments are data rather than metadata, so if you’re deploying a new or updated Permission set and have changed the assignments you will need to split this process into 2 steps.

  1. First deploy your Permission set.

  2. I have a new Permission set in my source org, and have assigned it to my user. I am deploying the new Permission set to my target org.

  3. Gearset problem analyzers make sure that the deployment will be successful.

  4. After I have deployed the Permission set, I start a data deployment to deploy the Permission set assignments. By inputting the Permission set ID Gearset can find the assignments associated with that specific Permission set.

  5. At the next stage we see the objects related to the Permission set assignments.

  6. Finally we run the data deployment, and confirm it’s success.

  7. At the end of this process I have deployed my new Permission set and the associated Permission set assignments successfully to the target org.

How can I see what a Permission set has access to?

Sometimes we want to see the impact of a Permission set, before we get to the point of actually deploying it.

This is easy to do - navigate to your Monitoring jobs (if you don't yet have any jobs set up you can follow these instructions, having one Monitoring job for each org is a sensible policy to monitor and track changes).

Once there find the org with the permission set you want to check, and click "View history".

Once you can see the historical job runs, click "Explore permissions" which will open up the permission specific view.

Clicking into this will allow you to explore the permission sets in your org, and see what level of access they have to various components. This information can also be exported as a CSV file.

Did this answer your question?