Manual Record Sharing & Auditing

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:

1-11-2013 4-04-07 PM

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:

38 Responses to “Manual Record Sharing & Auditing”

  1. Naved June 20, 2017 at 3:32 pm #

    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?

    • JohnCoppedge June 22, 2017 at 12:55 pm #

      Hm, just tested it and it worked fine in my org.

      Do you have an external sharing model turn on (for communities)?

  2. sachin.qatester December 14, 2016 at 2:36 am #

    John,

    Is it possible for a user to own a record and not see it? Under what circumstances this will happen?

    • JohnCoppedge December 16, 2016 at 11:46 pm #

      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.

  3. Thepride21 November 13, 2016 at 10:38 pm #

    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

    • JohnCoppedge November 16, 2016 at 11:39 pm #

      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.

  4. piyushsharma09 July 20, 2016 at 12:39 am #

    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..?

  5. g.levy@mamacash.org February 6, 2016 at 10:57 am #

    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?

    • JohnCoppedge February 8, 2016 at 2:50 pm #

      Yes, yes, and yes. Spot on

      • jobzmpons@hotmail.com May 25, 2016 at 6:48 am #

        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!

        • JohnCoppedge May 27, 2016 at 3:22 pm #

          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.

      • rashminder@techneosys.com March 1, 2017 at 7:00 pm #

        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

  6. g.levy@mamacash.org February 4, 2016 at 6:43 pm #

    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

    • g.levy@mamacash.org February 4, 2016 at 6:57 pm #

      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)?

      • JohnCoppedge February 4, 2016 at 7:15 pm #

        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).

  7. jsobrien November 5, 2015 at 11:11 pm #

    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.

    • JohnCoppedge November 8, 2015 at 8:03 pm #

      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 🙂

      • sheedhu May 13, 2017 at 7:03 pm #

        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

        • JohnCoppedge May 16, 2017 at 2:38 pm #

          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)

  8. Paresh Joshi August 20, 2015 at 11:21 pm #

    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?

    • JohnCoppedge August 25, 2015 at 2:15 pm #

      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.

  9. Saurabh Gupta March 21, 2015 at 5:48 pm #

    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?

    • JohnCoppedge March 25, 2015 at 4:23 pm #

      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.

  10. Patty Macdonald December 31, 2014 at 8:22 pm #

    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?

    • JohnCoppedge January 6, 2015 at 8:32 pm #

      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!

  11. Mark Aman December 12, 2014 at 5:29 pm #

    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

    • JohnCoppedge December 14, 2014 at 3:38 pm #

      Probably because accounts influence sharing of other related objects (contacts/opps/cases)

      • Mark Aman December 14, 2014 at 5:26 pm #

        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.

  12. Gita Patel October 31, 2014 at 9:48 pm #

    Hi John,

    Please include Navigation of the screen shot. I’ve seen it before but unable to find it.

    Thanks a lot
    Gita

    • JohnCoppedge November 5, 2014 at 9:29 pm #

      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

  13. Petter Wennerström January 2, 2014 at 7:48 am #

    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

    • JohnCoppedge January 2, 2014 at 2:17 pm #

      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.

    • Mark Thomas October 16, 2014 at 4:54 pm #

      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.

      • JohnCoppedge October 19, 2014 at 3:00 am #

        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.

Leave a Reply