1

I'd like to define FLS in permission sets alone and not have to maintain FLS per field in profiles. I've been surprised to find that if I do not specify in my profile that the FLS defaults to Read/Write enabled for all fields when I deploy the profile via the Force.Com Migration tool. I note with Objects that unless CRUD is specifically set to false on all access in the profile that standard objects default to certain Read/Write CRUD accesses however I did not think I would need to provide any FieldPermissions in the profile metadata to control field FLS.

Is this a known feature of deploying profiles via the metadata api. That FLS will default to read/write for any field not explicitly set differently by providing within the profile?

FLS maintainability in profiles is a pain so it would be good if it can be applied via permission sets alone.

Any tips/guidance on this would be appreciated.

Thanks.

Improve this question
1
  • Profile is already there in destination sandbox?
    – amitghadage
    Dec 20, 2019 at 14:13

1 Answer 1

Reset to default
0

FLS is not sparse in Profiles. In other words, there is always a reference to every field in your Org to every one of your Profiles. Worst case scenario, every FLS is set to false for everything. That said, for what you are intending to do, there is definitely a way to do it. It is kind of a roundabout way though. Before I talk about that, here is one fact: Profiles are never created, just cloned. This is true whether you use the UI (where you choose the base Profile) or whether you use the API (where the system chooses "Standard User Profile" or "Standard Platform User Profile" depending on the license specified on the incoming Profile. In other words, if I try to create a new "Custom: System Administrator" profile using the API, the system will clone the "Standard User Profile" and then override the settings with the incoming settings. So, if you hand-code the Profile XML to not have any FLS, you still get FLS but they are from "Standard User Profile" and do not get overriden. But, lets say you do the right thing and send a complete FLS in your incoming XML. Great, FLS gets fixed up but now Object Permissions is still a problem (as it came from "Standard User Profile". Makes sense?

Now, here is how you fix this issue: Manually create a null-op Profile in the destination (create a Profile by cloning it off something and then turn everything off in it). Then manually create a new "Custom: System Administrator" Profile with this null-op as a base. Then, migrate your "Custom: System Administrator" XML from source to this destination. This will ensure that only the metadata that you send is set in this new Profile. Yes, this is, technically, not a new Profile anymore but the API matches by name and this method will work.

Once this is done, go to town with PermSets. PermSets' FLS is sparse so you can set only the ones that you want to set and leave everything else behind. This also works for revocations.

Happy to discuss more if you need more info.

Good luck,

Sridhar

Improve this answer
1
  • Hi Sridhar, Thank you for your help. Apologies for the slow reply but I was on Christmas annual leave. I have followed your feedback and tried your suggestion on creating a null-op profile, cloning it for my new profile & subsequently deploying a profile of the same name via Metadata to overwrite the cloned profile. This has seemed to work perfectly. Thank you. I did not realise that even when deploying a profile via Metadata it must clone from a profile already existing in the org. Your help has been very much appreciated.
    – RedQueries
    Jan 4, 2020 at 11:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .