Deployment: We deployed a custom permission set through Copado tool to Production and the git commit for this permission set contains 2 FLS permissions on User object.

The scenario here is - other OLS/FLS permissions on these permission set exists in Production but it was not in sync with git master branch. After merge, I am seeing that PermissionS Set file is newly ADDED to master branch and it contains below FLS.

<?xml version="1.0" encoding="UTF-8"?>
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <description>Custom perm set to be assigned from v7.x onwards</description>
    <label>CC360 Custom CRUD</label>

Post deployment: we have observed that - it has wiped off other permissions on rest of the objects in Production for the same permission set and contains only above 2 FLS permissions on User object.

Could you please help why the other object permissions are wiped off instead of just appending the User FLS permissions.

As per the Salesforce metadata API behavior - it is stated that "When adding or changing a permission set, you don't need to include all permissions—you only need to include the permissions you're adding or changing." https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_permissionset.htm

  • 2
    It would be copado doing it... Most tools like gearset copado compare xml and only deploy the change(delta). Here as you changed the whole file and added only your change.. it thought that older permissions are deleted. If you just have deployed via force.com migration tool it would have behaved as expected. – Pranay Jaiswal Jan 19 at 11:28
  • 1
    I have replicated the scenario with Workbench, prepared metadata zip file with permission set containing 2 FLS on User object and my target sandbox have other permissions OLS/FLS on Account object. After deploying through work bench it wiped off Account permissions on target sandbox. How can we avoid this in future? Is it tool issue or Salesforce Metadata API behaviour – Salma Khathun Jan 19 at 12:02

PermissionSet returns all permissions on retrieve/deploy (since API 40 and above) and works differently than Profiles. What you're trying to do works with Profiles because it's designed to overlay the existing Profile settings in a target org - meaning, you need to actually include the field with <value>false</value> to remove a field permission and not including it will make no change on the profile.

enter image description here

I would follow up with Copado about PermissionSet behavior if you created it through them and it didn't include all the permissions in it on the commit. PermissionSet, in source control, should contain all permissions and be deployed as such to avoid removals.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.