First time while I was preparing
for my Administration Exam I watched this video “Who Sees What: Overview on salesforce” (https://www.youtube.com/watch?v=jDYfTfaqclk
)… I was very impressed! Later while
working hands on I realized things can get really messy and could easily go out
of hand if we don’t really keep strong strategy and control.
Too many roles, too many sharing
rules, complex Account teams, too many permission sets, these all could lead to
loss of control on data visibility aspects in your Org. It is advisable to administer
the sharing with strong change management process in place.
Who Sees What in Salesforce is
fine, but when we come across a situation where we need to figure out why a
particular entity, record or a field is being visible / editable by some other
user – how should we approach such problem statement ?!
Recently in one of our
engagements, post data migration – we had this exact issue to solve. Client said that a particular USER was not
supposed to see other account information, whereas when we simulate and log in
behalf of the USER, we could see much more accounts than he / she we thought
should be seeing in actual!
Now, Is there a logical way to solve or get to the root
cause of these kind of sharing issues! Let’s
check out. I am considering an ACCOUNT record visibility issue for illustration
here:
PROFILE / PERMISSION SETS
Profile / Permission set controls CORE CRUD
permissions for Object as well as Fields, so let’s say this is bit easy. Hence let’s focus more on Record visibility,
ability to read or edit the records of some other user which is where a lot
many permutations / combinations are possible!
OWNERSHIP:
Is the USER in question is actually the current
owner of the Account record? check for this first
DEBUG LOGS:
Ok – Shall I enable Debug logs? And trace the
log for any clue?! -- Nopes, this won’t
help. In salesforce the sharing reason
is not revealed via debug logs …
OWD:
Hey!! What about OWD? Is it Public Read-only /
Public Read write already? If yes, then you already got your answers… else if
OWD = private, keep checking further…
SHARING RULES (Public group, Role, Role/Subordinate, Queue):
Is there any Sharing rule on Account? Is sharing
rule based on Public group? Or Role and its subordinates? If yes, then quickly
see if the USER in question is part of Public group!? Or see
if the Sharing rule is directly sharing to a particular ROLE? Or Access is rolling up the hierarchy? Or sharing rule is for ROLE+Sub-ordinates?! If No sharing rule is found, then move on…
SHARING RULE OVERRIDE:
See if there are any Sharing rule over-ride? I.e. exactly PROFILE / PERMISSION SET with
VIEW ALL / MODIFY ALL permissions?! Permission
set - not associated either.
ACCOUNT TEAM:
Account team – is a feature to enable users with
different level of access on a particular Account so they can work as a team,
hence check if the USER in question is part of Account team?! Or at-least see
if any of the Account team user is beneath this USER in the ROLE hierarchy? Or if the USER is manager of the Account team member?!
ACCOUNT TEAM MEMBER / ACCOUNT SHARE:
You may use Workbench to query the
Accounteammember entity along with AccountShare entity to see which all
entities are shared with this USER and in what level?! I.e. READ / EDIT?
Did you get to root cause yet?! else keep
continuing …
ACCOUNT SHARE (Implicit, Manual, Owner, Team):
When you search on Accountshare – some sharing
reason will be due to IMPLICIT permission, which means - because the USER is
the owner of some of the child entities (i.e.
if USER is owner of Contact , then implicitly this USER will have READ
access on the Account to which his Contact is linked to ), same applied b/w Opportunity and ACCOUNTs
APEX SHARING:
Code based sharing is possible, however this is
more of invoking a Class as system user or as a specific user and execute a
logic
SHARING SETS:
If you are dealing with Communities user –
better to check Sharing sets to see if there are any sharing b/w external users
to internal users?!
OWD RECENT CHANGES:
See if someone changed OWD recently? This might
lead to re-calculation of sharing – but at times, this will take more
time. This might have led to USER ability
to see the record.
SFDC SUPPORT:
Are you tired, still not able to figure out root
cause, raise a SFDC case and hope for some help!
Dear readers, IF you find any points above are technically
incorrect, plz shout back – I shall revisit those points, also if you have some more additional
investigative tips, kindly do share through your valuable comments. Knowledge is worth sharing…
*THANKS YOU*
