Manual Record Sharing
As a general rule, if org-wide defaults for an object are set to either Private or Public Read Only, then the sharing button will be displayed if added to the page layout. Some objects (such as account) may have the sharing button exposed depending on the sharing settings of related objects (e.g. sharing on the account can be used to share related opportunities and cases).
By clicking “Sharing”, a user can then manually share access to this record with other groups, roles, and users:
In order to share access to a record, the user must first have “Full Access” to the record (see Security Overview).
Viewing Record Access
The sharing button also provides an easy way to view who has access to record. Just click “Expand List”.
This gives a very granular view of who has access to the record:
And why:
Is this feature available in lightning?
Nope 🙁
There’s a temporary fix via labs app: https://appexchange.salesforce.com/listingDetail?listingId=a0N3A00000EFp0ZUAT
The below link might be insightful for OWD and Manual User Sharing. This is a video from Salesforce:
http://salesforce.vidyard.com/watch/qVs-VNf4dlXRTtg_clj-UQ
Thanks,
Rishabh
Great information and very helpful, thanks! But when I go into my sandbox, I don’t see the Sharing button on the detail page for a particular Contact. I changed my OWD sharing defaults for Contact from “Controlled By Parent” to “Public Read/Write” and added the sharing button to the Contacts page layout. Also, I enabled the External Sharing Model in Sharing Settings. Still, no sharing button on the contact detail page. Did I miss something?
OWD needs to be set to public read only or private, and you need to be in classic (also make sure the button is on the page layout).
Public read/write won’t work as you’d have no reason to share (as everyone already has access)
Yesssss! It worked after I set my OWD sharing for Contacts to Private. Seems counterintuitive that a Private setting would allow sharing. Also, are there any Objects whose instances cannot normally be shared? But are there any standard objects whose instances/records are naturally resistant to being shared? I’d think you could overcome any sharing restrictions with permission sets or custom objects.
Yeah there are a great many counterintuitive things I think 🙂
The big exception is when objects are set to controlled by parent (or are in master/detail relationships). For the most part profiles and permission sets set the base permissions for the object, but don’t influence record level security (other than the admin type permissions), the security matrix on this site aims to outline that.
Hi John,
I have set my Account & Opportunity objects to Public Read/Write but I can still see sharing button on detail pages. I tested it on custom object but it didn’t disappear. What could be the reason?
Hm, just tested it and it worked fine in my org.
Do you have an external sharing model turn on (for communities)?
Spot on!
Thanks
John,
Is it possible for a user to own a record and not see it? Under what circumstances this will happen?
Technically speaking yes it is possible but not likely.
You can’t assign a record to a user that would not be able to access that record, but if the record is already assigned and access is revoked, then that scenario is possible.
Example:
I am assigned the sales profile which has access to read opportunities. I create an opportunity and therefore own it (or am assigned an opp by someone else).
My profile is changed to support, which does not have read access to opportunities. I still own the opp from before, but I cannot be assigned any new opportunities.
Hi John,
Can you give some insight into Portal users. What are their roles and rights? They come up very frequently whenever any exceptions are sighted!
Is it important to remember these exceptions with the certification in mind?
Regards,
Meher
Not super important for this exam- the key is that the license limits the objects that portal/community users can access. When a customer account is provisioned for access, the contact gets an associated user record. It also creates several roles for the account that are provisioned under the role of the account owner. It is fairly complex, and that level of detail is not expected for the admin exam.
Thanks John!
Can users X and Y view Z’s opportunities, if there are any existing.? Can users view each others opportunities irrespective of their hierarchies, if OWD is set to Public read-only.? Hierarchy doesn’t play any role here? Hierarchy will open more access(Read-write) to those up in that ladder. Regular viewers will be able to view opportunities with current setting..?
May I ask to see if I can recap this?
Scenario:
I have two role hierarchy Role A and its subordinate role Role B. I have one Profile “Programme” . The OWD for opportunity os Public Read-Only. I have two user records with this profile and role B, user X and user Y. Lastely User Z with same profile but with Role A.
The object setting for opportunity for profile ” programme” is CRE.
Conclusions:
1. User X can only read User Y’s opp. and vice-versa?
2. User Z can Read, Write both user X and user Y oppoortunity – because s/he is higher in the hierarchy?
3. If I will create a Sharing rule for user X and user Y with read/write option, they both will be able to read/and edit each other opportunities?
* I can create sharing rule based on defined user groups or roles.
Am i on the correct track?
Yes, yes, and yes. Spot on
Hi John, i have tried above scenario and confirmed them.. i am just confused with #1, does this mean that OWD setting (public RO) supersedes the object setting CRE at the profile? thanks!
OWD grants record-level access to all records at the level specified. For example, public read grants read access to all records.
You need access at all levels – e.g. to view the “commission” field on an opp, you need read access to the record, view access to the field, and view access to the object.
Hi John,
A little clarification..in the example above for #1 if the OWD setting was set to PRIVATE I will have to set up sharing rules for user X and user Y to access each other’s opportunities right?since according to the who sees what video ,record access horizontally in a role hierarchy can be achieved by sharing rules if OWD is set to PRIVATE.
thanks
rashminder
Yep
I have similar question to the one I posted earlier:
The OWD setting for opportunities in our org. is Public Read Only
What is the difference between using Sharing (button) and Opportunity team (related list)?
Thank you,
Gil
I have also noticed that if a user creates an Opportunity; when i press on the sharing button I can see that automatically the record has been shared with others. Why is that? how can I control that (as admin)?
Sharing rules would automatically create access for other users, as would the role hierarchy. Manual sharing only influences security- Teams both influence security and provide a record as to who is working on the opportunity (they are quite similar).
Hi John,
You state that “in order to share access to a record, the user must first have “Full Access” to the record”
Which user? Record owner or the user being shared with?
Below is from the security overview section, it says record owner is granted full access; however, full access cannot be shared.
“Full Access” is granted to:
The record owner.
Users higher in the role hierarchy than the record owner (when “Grant Access Using Hierarchies” is enabled).
Users with “Modify All” object-level permission (this includes system administrators).
Members of a queue to all records owned by the queue.
It is not possible to share “Full Access” via sharing rules or other mechanisms at this time.
The user sharing the record must have full access.
The user receiving sharing would most likely have less than full access (otherwise there would be no point to sharing the record).
Hope that makes sense 🙂
Hi John,
I had a question here. What if the user1 has read access on a particular record. Would he not be able to share it with another user2 and give him read access. Why is it neccssary in this scenario for user1 to have full access to the record he wants to share? Kindly elaborate.. Thanks
What if the user1 has read access on a particular record. Would he not be able to share it with another user2 and give him read access.
He would not be able to share that record, correct.
User 1 would need full access (either by being the record owner or being above user 2 in the hierarchy)
John,
How can I make sure that any opportunity created under an account is editable by the account owner?
I cannot find a setting which will do this.
There doesn’t seem to be a way to create a sharing rule (ownership based or criteria based)
Is Apex sharing the only option for such a basic requirement?
Create the sharing rule on the account, and step 5 will give you the ability to grant access to the related opportunities via the account record.
Hello John,
What is the difference between Sharing the particular opportunity manually with a particular user and adding the particular user to the opportunity team and share that particular opportunity?
They provide similar capabilities – however, the opportunity team in addition to providing sharing access also lists who has access and why (which is less obvious with manual sharing), and you can select a default team.
About the Sharing button–it seems that you would either use the Sharing button or set up Account Teams but there wouldn’t be a reason to do both. Is this sound reasoning or am I missing something? Can you think of a scenario when you would use the Sharing button AND Account Teams?
Sure- account team has support rep Bob listed as the dedicated rep. (account team)
Bob needs help solving the customer’s problem, isn’t a named support rep for the account, but still needs access to the data. (manual sharing)
Good question!
Hi John,
The Sharing button toggles on and off as you’ve described for several objects I experimented with, namely, Leads, Opportunities and Cases, however for Accounts, the Sharing button in my org is always visible, even if the Org-Wide default is set to Read/Write. Is there some other setting that influences this?
Thanks,
Mark
Probably because accounts influence sharing of other related objects (contacts/opps/cases)
That was it, John. If either the Opportunity or Case org-wide default is anything less than Public Read/Write, then the Sharing button will be displayed on an Account record, even if the org-wide default for Account is Public/Read Write. It may be helpful to add a note about this behavior to the documentation above.
Thanks, updated
Hi John,
Please include Navigation of the screen shot. I’ve seen it before but unable to find it.
Thanks a lot
Gita
Hi Gita- navigational shots are included above… if the sharing button isn’t present that’s because your org wide defaults on the object are set to public read/write
Thanks for a great site and service.
I was expecting to receive more information about auditing in this section.
From help.salesforce.com you can see that there are a few audit features:
– Record Modification fields
– Login history (covered in the User setup and login process)
– Field history tracking
– Setup audit trail
In my opinion it would be good to include this information here or in a separate section on auditing.
Thanks,
Petter
Thanks for the feedback Petter. Each of these topics should be touched on in the guide, but throughout several different sections. I’ll give some thought capturing this centrally as well.
I agree with Petter about the Auditing. I guess it can be said that as an administrator I can audit user access after reviewing the expanded list. In my case, I discovered a profile that had Full Access that should have had Read Only Access.
Duly noted – will backlog this request. Auditing is a complex topic however, and is probably better suited to advanced admin. That said- covering the basics in one page/section is definitely a good idea.
Profile, permission set auditing is just piece of the puzzle as Petter mentioned. There are also auditing record changes, record deletions, config changes, login history, etc.