In our company, we would like everyone to have access to every Account record.
As a baseline, everyone would have access to a limited number of fields of every account record.
To see EVERY field and related list of the Account record, the user would have to be the owner of the record or have the record shared with them (through manual or built-in sharing rule).
I found this thread
https://trailblazer.salesforce.com/ideaView?id=08730000000knSGAAY (https://trailblazer.salesforce.com/ideaView?id=08730000000knSGAAY" style="color:#.1f4e79; text-decoration:underline)
But I really didn’t understand what was meant in the comment by FSL so moved on to trying to pioneer my own solution.
Enter stage right my possibly horrible idea to somehow copy the account info I wanted visible to everyone to an entirely different object that would then be set to Public view. (yes, this is duplicated data – maybe a big no-no? Certainly isn’t clean in my opinion but looking for a work around).
By default, I set our Account Object to Private.
I then made a process builder that took newly created Account records (or if the Account name field was edited) and set it to create a new record on an entirely separate object, “Visible Account” and copy over the Account Name field (and other misc. fields)
I now have a separate object (Visible Account) that is public. Everyone can see the customers we work with and even search the field(s) in a list view. Fantastic.
The next magic trick is associating the “Sales Reps” on each Account record with my new “Visible Account” object records. “Sales Reps” is a separate object that has a lookup field tied to our Account records. An Account can have multiple Sales Reps. This is where I got stuck. Long story short, I still have not figured out a process by which I could easily associate a Sales Rep record to 2 separate objects (Account and Visible Account) that would have the same name.
I pivoted again. I realized that my Sales Reps object was public. There is a lookup field to Account Object on it. People can already see all of our Accounts and know who is working with them in a list view of the Sales Reps object. Well, the downside to this is that when you look at a list view report of the Sales Rep object, you can display the Account Name, but it isn’t searchable in the list view because the Account Object is set to private. This makes sense. My next thought was….is there a way to copy the value of the lookup field (the account name) on the Sales Rep object and then display it in another field on the Sales Reps object that would then be searchable? Basically, spoof the fact that the field is tied to a restricted object, instead just copy and paste the value into another field as plain text. Tried a formula field, set to display the lookup field value. This formula field was not searchable either in the list view.
Is there a way to do this? Copy the lookup field value and re-use it in a new field that wouldn’t associate it with that original, private object?
Long story short, I took two directions in trying to get around this field permission issue on our Account object and in both cases I seem to have backed myself into a corner.
- Tried to make a separate, public object that would auto-create the records with fields that I wanted everyone to see. This worked until I struggled with populating related lists from the original, private object.
- Tried using the public object - “Sales Reps” (related to our Account records via a lookup field) to give our users a list view of the Sales Reps object to see Account info. I can get Account name values to show up on this list view, but the values aren’t available for search or filter.
A lot going on with this post but being fairly new to SF, I thought it best to write everything out in case anyone wanted to comment on why you should never do such a thing, etc. I feel like I’m at that stage where I’m learning some of the tools available to me in SF but not experienced enough yet to know why I should/should not use some of them in X, Y, Z scenario.
Your advice and insights are much appreciated!
1 resposta
Jeff,
Regarding "FSL" in original thread. It looks like it was missprint and "FLS" was mentioned - field level security.
FLS is one of the basic concepts in SF design. And profile is the basis to specify what fields in some object should be visible or editable for user and what fields are not visible at all.
So, you wanna to implement OTHER paradigm and if you wanna to reload FLS by your own design you should be ready to have a fun to hack all created by SF code to implement their original design. Wow!
As I see smbd suggested to re-implement ALL sensible fields as formulas and display different content for those formula fields by using condition "If (user_id = owner_id, "sensitive information = copy from some hidden to all field", "null"). But I don't think this is good idea, just because to edit such sensitive information you should edit some other field and we, again, return to FLS limitations.
