Different Commit Operations - "Commit Files" vs "Full Profiles and Permission sets"
Commit Files Operation - Incremental Changes
As a best practice, we will always use the "Commit Files" operation, which allows us to commit the profile/perm set changes incrementally (only commit & deploy what has changed, and not the full permset/profile).
For this, we will have to select the profile or permset, and additionally select as "retrieve only" the metadata for which permission has been modified (you can add the metadata without "retrieve only" if you also need to include the metadata change in the commit).
For example, to commit a profile where a field permission has been updated, and an apex class permission has been updated, it would look like the following (the same would apply for permission sets):
(Note that this is just an example)
On deployment of this, copado will only deploy the changed permissions, and will not touch any other permission, even if orgs are misaligned. This is why this is a safe operation.
Copado provides documentation about how to do this, the most relevant link is Commit incremental changes in Copado.
Full Profiles & Permission Sets Operation
⚠️⚠️⚠️ This should only be used when we want to commit the full profile/permission set, and never when we just want to update a few permissions on it ⚠️⚠️⚠️.
⚠️⚠️⚠️ For example, if we have just created a profile/permset and we want to quickly commit it, we can use the operation. However if the profile/perm set already exist in production, we should not use this operation, because if there is any minor difference between the org where the commit is done and production, production will be accidentally overriden. ⚠️⚠️⚠️
An example of using this operation can be seen in the next screenshot. On this example, copado will retrieve the complete set of permissions (of objects, fields, classes, system permissions, app permissions, ... everything) and will commit it to the branch.
Copado provides documentation about how to do this, the most relevant link is Copado Full Profiles and Permission Sets, be mindful of the Important considerations on it.
Issue: Deployment Failure of Permission Sets with "View All Data" Permission
The DevOps team added permission sets containing the "View All Data" permission to the `.gitignore` file in GitLab. As a result, these permission sets can no longer be deployed using Copado user stories. When included in a user story, the deployment fails with the following errors:
- `[Convert_Files] An object 'Convert_Files' of type PermissionSet was named in package.xml, but was not found in zipped directory`
- `[z_View_All_Data] An object 'z_View_All_Data' of type PermissionSet was named in package.xml, but was not found in zipped directory`
Permission Sets in `.gitignore`
The following permission sets were added to the `.gitignore` file, preventing their deployment through Copado user story:
- `permissionsets/API_integration_Own_Backup_Restore_Modify_All.*`
- `permissionsets/API_Integration_Qlik.*`
- `permissionsets/System_Admin_Rights.*`
- `permissionsets/z_View_All_Data.*`
- `permissionsets/CommerceSession.*`
- `permissionsets/Convert_Files.*`
Solution: Deploying "View All Data" Permission Set
To deploy permission sets with "View All Data" permission, use Salesforce Change Sets to deploy these permission sets to target orgs.
Going forward, all deployments of permission sets with "View All Data" permission should be handled via Salesforce Change Sets in the target orgs to avoid similar issues.
The best way to get IT support is to use the new
Service One Platform.