Having worked as a release manager for the last year, I have had my share of ups and downs in managing deployments. As with most projects, my projects use Visual Studio Code to manage the branching and deployment models. Basically, we put together a simplified delta deployment using Gitlab to manage our releases.
However, even with a fully functional Gitlab deployment to Salesforce, managing profiles and permission sets was (and still is) a very big challenge. If any new feature or branch required a change on a profile, it had to be done manually. This article shares the current limitations for managing profiles or permission sets in a Salesforce environment connected to VSCode, and the tool I created to help out. Let’s get into it.
How Do You Retrieve a Profile?
Before going into the details of why retrieving your profile from your environment is not working, let’s check out how it’s done in the first place. Let’s consider the following example: you’re working on a feature where you create a new custom field on an object.
After creating the field on your developer Sandbox and adding the read/edit permissions to the admin profile, you want to push that change to another environment or your feature branch. To do so using Visual Studio Code, you might use the package.xml file. This is the manifest file that determines the components to retrieve from or push to a Salesforce environment.
It would look like something like this:
Next up, you would use the following sfdx retrieve commands (Salesforce recently moved from sfdx to sf commands):
| SFDX | SF (V2) | |
|---|---|---|
| Retrieve Components using package.xml | sfdx force:source:retrieve –manifest package.xml | sf project retrieve start –manifest package.xml |
| Deploy Components using package.xml | sfdx force:source:deploy –manifest package.xml | sf project deploy start –manifest package.xml |
I’m not sure if it’s the dependencies between the profiles and all the different metadata types that cause this, but if you use either of the retrieve commands, the retrieved profile will look like it’s lost 90% of its content. The only current way to fix this is to either add all the types of Salesforce metadata on the package.xml file or possibly find an extension on VSCode.
Adding all types of metadata on the file is not something easily done and will probably force you to retrieve basically everything from your Sandbox. Using a VSCode Extension could be a solution, but then again, you might not want a complicated add-on with a dozen features.
This is a problem most developers/release managers face and it often leads to extra work. They have to retrieve the changes and then compare them to the initial profile file and add the changes manually, or directly modify the profile file in XML which could lead to regressions and faulty profiles.
In my case, we were leaving all profile-related actions as post-deployment actions. This has caused us issues frequently due to forgetting field access, a record type assignment, ect.
The Profile Generator
From the different challenges presented above arose the idea of the Profile Generator. It’s a light tool that I developed to help me fetch only the differences when retrieving profiles. Let’s check out how it works.
Considering I’m connected to my Developer Sandbox, I just created a new field called TestField on the account object, and I also added the field-level permission for the admin profile. On VSCode, I will edit my package.xml file to add the field I want to retrieve as well as the profile I want to update:
Next, instead of using a command line to retrieve the components mentioned in the package.xml, I’m going to launch the Profile Generator by clicking a pre-configured button. This button will launch the tool to automatically retrieve and update the profiles mentioned in the package.xml (in this case, only admin is updated). The result is as follows:
You can see that the only line modified was that of the new field, with the corresponding read/write accesses. Let’s say after I have retrieved the admin profile, the business decided that they just want the admin to have read access. On the same Developer Sandbox, I would edit the field level permissions and check the read-only permission on the admin profile. Then, I would follow the same steps mentioned above and what I would get is the modification on the specific “editable” line to set it as false.
The biggest advantage here is that we’re managing to retrieve ONLY the modifications without removing any of the other elements that make up the profile, thus saving up a lot of time for any developer, admin, or release manager who wishes to deploy a profile.
What About Permission Sets?
Given that Salesforce has been pushing towards permission sets as a means to manage user permissions and accesses, this tool will be obsolete soon. However, it can also be used to retrieve/deploy permission sets.
All you need to do is open the config.properties file and modify the ObjectType to PermissionSet. Notice that the package and files paths point respectively to the package.xml file and the Salesforce Default Folder that contains the different types of metadata.
Similarly in this case, launching the Profile Generator will retrieve the changes on the permission sets specified in the Package.xml file.
What Can’t It Do?
Even though the Profile Generator works perfectly for adding and updating profile-related differences from a Sandbox, it cannot manage the deletion or suppression of accesses of a profile. In other words, if you delete a field completely from your Developer Sandbox, the Profile Generator would not be able to delete this field from the profile and you would need to delete it manually.
Summary
The Profile Generator is a light tool used to quickly and efficiently update profiles or permission sets from a Salesforce Sandbox. Specifically useful in a release management framework to facilitate deploying profiles and managing them in a Git repository.
I have been using it for the last few months and there has been a continuous effort to improve it, but it has saved me a lot of time.
Comments: