TL;DR
Just run sf texei skinnyprofile create from your SFDX Project before all your deployments and you’ll be fine 😎
What’s the problem ?
Have you ever tried to deploy a Profile with Salesforce ? If so you know how painful this is.
One of the issue is that the first time you deploy a Profile from an environment to another (main use case, from a development environment (would it be a Sandbox or a Git based source) to a Production environment), the Profile is created but it contains A LOT of extra access rights that are not part of your deployed metadata.
Said differently, create a Profile in a Sandbox, with no access to Account, Contact or Opportunity, and deploy it to Production, either with Change Set or Metadata API.
Have a look to your Profile, and you’ll see that amongst lots of other access, it now has access to Read, Create, Edit and Delete these objects. Some of you may call it a bug, some others may think it’s a security issue exposition your data. What is certain is that it’s the way it works.
A deeper look
Let’s try to create a Profile with only the minimum access. It’s pretty easy from the Salesforce UI, where you can just create a new Profile and select the « Minimum Access – Salesforce » as existing Profile to clone from. Once created, there are still a few checkboxes that you’ll need to uncheck manually (I would assume this profile should be fully empty, but well 🤷♂️), and you just have to save it.
Retrieve the metadata, and you’ll get the smallest profile possible, that would look like that:
As you can see there are just a few permissions, and no Application, Object or Tab permission.
Then just deploy this metadata to another org and look at the Profile. Just looking at the Object Permissions that were empty on the source Profile, you can see a HUGE difference, with access to critical objects like Account, Contact, Opportunity or Contracts:
This printscreen is just a subset of access rights that were added without being part of the deployed profile, feel free to look at the whole picture here, it gets a lot scarier.
So now that we understood the issue, what can we do about it ?
The solution
First it’s worth noting that this issue only happens on Profile creation, deploying an existing Profile will not add any unwanted extra access rights.
So we have 2 ways to fix this:
- find a way to build a full Profile metadata, including all Applications, Objects, Permissions etc, and explicitly set everything to false
- create an empty Profile first, and then deploy our metadata that will just add the needed access rights
The first solution would have to be on a per-org basis, meaning we can’t build a full profile and save it (to git or whatever tool you’re using), because all target orgs don’t have the same set of permissions. For instance Production orgs have Permissions that are not available on a Sandbox, so manually setting the value to false would prevent deploying it everywhere. Also, « manually » looking for access rights for Objects, Permissions etc would need to be updated when new options are added. For instance, when Custom Metadata were added to Profiles in Winter ’20, this would need an update to query these access rights and set them to false.
For the second solution, you can manually create the Profile by cloning the « Minimum Access – Salesforce » and uncheck all unwanted access, but that just works for the « Salesforce » license as there is no equivalent empty profile for other licenses. You could also create the Profile manually using Workbench, as explained by Tom Bassett recently in his video. This works fine, but what if we want to have this automated ?
We just added a new command to our Texeï’s SFDX Plugin that does just that ! Just run the following command in your sfdx project to create empty Profiles:
sf texei skinnyprofile create
It benefits from a new feature introduced in Winter ’22 that let us create a new empty Profile with the SOAP API. What the command does is pretty simple:
The command looks at all custom Profiles that are in your local SFDX Project but not in your target org, and create them as empty via the SOAP API
Then the next time you’ll deploy Profiles, they won’t get created with unwanted access rights, but the just one you want.
Conclusion
This command is intended to be used in automated deployment, for instance scripted in a GitHub Action. Just add it before your deploy command, Profiles will be created empty and then your regular deploy will add the expected access rights.
The command doesn’t provide a way to specify a Profile name as it’s looking on the Profiles that are part of your SFDX Project. Would you want to manually create a Profile you can still use one of the options mentioned above, or as our plugin is open-source feel free to create a Pull Request for it 😉
A few things to note about this command:
- it works for all licenses types, but will obviously fail if one needed isn’t available in your target org
- it will output which Profiles could be created and which couldn’t, but will not rollback any already created Profile in the same command run
- similarly, if the command succeeds but the deployment you launch just after fails, created Profiles will remain in the target org
- it doesn’t solve the issue of currently existing bad profiles (that were deployed with too many access rights)
Point 2 and 3, even though not perfect, are still much better than the actual problem. In this case you’ll just end up with empty Profiles assigned to no one, that you can manually delete (or even script it) if that really bother you.
For point 4, as this is a one time only action to fix this, you can just go to your Profiles and uncheck unwanted access, or even uncheck everything (for instance using the tips from my colleague Mouloud Habchi) and redeploy your project right away.
And that’s it !
In a coming second blog post we’ll give more details on how we handle some other Profiles issues (remember these Permissions not being removed that I was talking about just before ?).
Stay tuned !
