0

As we all should know, the OOTB Salesforce way of doing manual sharing is give a user (who is typically not belonging to the same recordType) access to VIEW the record. As in below screenshot :

Case Manual Share

However , there is some user requirement where all the Case RECORDS can be seen by all divisions (division A & B).

The exceptions are that on these records, they can only see:

  • Global fields that can be seen by all (e.g. Subject, Description, OwnerId)
  • Division A specific fields can be seen by their own division (e.g. Div_A_Specific__c)
  • Division B specific fields can be seen by their own division (e.g. Div_B_Specific__c)
  • The real head-scratcher is when the user wants to share a Division A record with a user with Division B PROFILE, the Field-Level-Security (FLS) of Div_A_Specific__c field should be read-only from no visibility for that specific user

So my initial setup is like this :

  • Case OWD = Private
  • Case Sharing Rules: Criteria based sharing rule of Case Record Type = Division A to be shared with Division A & B (Read Only)
  • Case Sharing Rules: Criteria based sharing rule of Case Record Type = Division B to be shared with Division A & B (Read Only)
  • Division A Profile/permission set access : Case Record Type = Division A, Remove FLS for Div_A_Specific__c and Edit for the rest of the Case fields
  • Division B Profile/permission set access : Case Record Type = Division B, Remove FLS for Div_B_Specific__c and Edit for the rest of the Case fields
  • Have a custom button that will somehow update FLS for the specific user of Division B profile of Div_A_Specific__c from no visibility to read-only??

Any ideas how this can be done in a easily maintainable way?

1 Answer 1

2

There isn't a good way to do this. There's a few not-so-good ways whose tradeoffs might or might not work for you.

If you only need the sharing to work in the record UI (not in the API and not in reporting), you could:

  • Create a custom UI component that deliberately ignores FLS for the Div_A_Specific__c fields, and presents those fields to the user. The component can check the profile of the running user to validate that it's Division B.
  • Show this UI component on the Record Page for the Division B profile and Case Record Type Division A.
  • Create the same components for the reverse situation.

That means users can only see these fields on shared records when directly viewing the record in the UI. No API, no reports, no List Views, etc.

The reverse approach would be:

  • Grant FLS to all of those Div_A_Specific__c fields to the Division B profile.
  • Use Dynamic Forms on your Record Pages to show those fields if and only if the user is Division A or Division B.
  • Do not show these fields in any List View or Report Type.
  • Do not allow users to create or edit Custom Report Types.
  • Accept that fields will be visible in the API.

The former is a better solution in my mind, as the latter is full of potential disclosure pitfalls. Of course, if the data isn't that sensitive, that may not matter to you.

There are other options, depending on how much you're willing to bend your data model and/or use programmatic functionality.

Best of all is to find a way to rethink this business requirement to fit better within the Salesforce permissioning model. Any solution you create here is going to be a partial one.

3
  • A colleague of mine was proposing to create another custom object (called CommonCase__c) and then create that CommonCase__c automatically when a Case is created copying over all the 'global' fields to CommonCase__c with a Lookup to the Case. I was like oh god no! But yea the business requirement doesn't make sense in a Salesforce context doesn't it? And they wanted to try do it OOTB or with Omnistudio lol
    – compski
    Jun 13, 2023 at 16:06
  • 1
    @compski Yeah, I don't like that option either, but it raises another possibility to me - move the division-specific fields only to an adjunct object, use Apex-Managed Sharing on the child object, and show it with a related record component on the record page.
    – David Reed
    Jun 13, 2023 at 16:11
  • 1
    I was thinking the latter, creating a Div A record and a Div B record, both referenced via Lookup field from Case, but actually not moving the fields at all and instead using cross-object formula fields (which ignore sharing) and then managing visibility of these related objects using appropriate sharing. (Obvs, the formula field approach only good for read, not edit.)
    – Phil W
    Jun 13, 2023 at 16:13

You must log in to answer this question.

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