Groups

What is a group?

A group is comprised of users, roles, and other groups.  There are two types of groups:  Public groups and personal groups.

Public Groups

Public groups are created and maintained by administrators, and can be referenced in org-wide configuration (such as sharing rules).

Personal Groups

Personal groups are created and maintained by users, and can only be referenced in select configuration (such as Outlook contact synchronization).

Why use public groups?

Use public groups to streamline the process of sharing access to records and folders with a collection of users.

Common use cases:

1. Sharing access to records or folders with named users (this requires a public group):

1-11-2013 1-11-07 PM

2. Sharing access to several resources to the same collection of users within specified roles.

For example, I want to share access to 2 report folders and a dashboard folder with the following roles:

1-11-2013 3-54-45 PM

I could configure the sharing criteria for 3 folders to include these roles.  Or, I could create a public group with the roles:

1-11-2013 2-54-45 PM

Then share access to each folder with the group:

1-11-2013 3-10-26 PM

Now let’s say that the “Installation & Repair Services” role should no longer have access to the folders.  With a group in place, I simply remove that role from the group.  Folder access is updated automatically.

Without a group, I would need to edit each folder separately to make the change.

Important Notes

  1. There is no way to monitor where groups are referenced (e.g. you have to view each individual report folder, sharing rules, etc.).  For this reason, make sure to have a clear documentation and usage strategy for groups (or at a minimum, a very clear naming convention).
  2. When groups are referenced in sharing rules, “Grant Access Using Hierarchies” can be extended to group access.

1-11-2013 3-34-46 PM

 

25 thoughts on “Groups”

  1. It’s difficult to know how to do this without guidance on what to click in SFDC. Would you mind sharing what to search for, and the clicks after that to really understand by doing?

  2. Hi John,

    In my org. I have a situation where I wish to provide horizontal CRE to a user who is not in the role hierarchy. The record type is an Opportunity. Should I create a Group to allow that or should I use Opportunity Team?

    Thank you,
    Gil

  3. Dear John,
    It would be great if you could share the Path for the above images provided as for a beginner it would be difficult searching for the same. Its just a suggestion.
    For eg: I have been searching for the Point 1 path to goto that page via sharing rules & Groups but the pages are quite different than what is depicted above.
    Thanks

  4. Hi John,

    In developer edition, “Folder Sharing” under Setup| Customize| Reports & Dashboards is not available , however; this option is available in Enterprise edition. Please clarify on this.

    Thanks.

  5. Hi John,

    Can you please confirm public groups are required to share folders with named users?

    My SF Winter’15 allows me to pick users when I’m trying to share a report folder. Am I doing something wron or misunderstood you?

    Thank you.

    Regards,
    Petr

  6. Hi John,

    Could you please elaborate “When groups are referenced in sharing rules, “Grant Access Using Hierarchies” can be extended to group access.”
    group doesn’t have any hierarchy. I am sure I am not following the meaning of this sentence.

  7. I haven’t gotten into enough yet to know, but if this is truly a relational database, that ought to be very doable. Seems like an easy app to create for security management. I’ll be interested to see, when/if I get into the developer part of this if SF lets you do this. It’s all there, you just need to right reporting mechanisms.

  8. As I am going through the security access information I have been building an Excel sheet that I imagine will be useful in implementations. It will document by user their profile, permission set, OWD, Role, field level security and sharing rules for each object. The intent to arrive at a “system access report” that can be used to implement security and/or monitor security afterwards. 2 Questions: 1) Has anyone developed such a tool for use during implementations? 2) Can such a report be generated by SFDC for troubleshooting and/or audit purposes?

    1. I was thinking about this as well, Michael. I just completed a security review/update for a client and had to create a similar record. I’ve also found documentation difficult when implementing new apps and adjusting various settings across the org and one of my prior employers (where I first encountered Salesforce) had their own process. I keep thinking there must be some standardized forms available for administrators that helps keep this information handy beyond just searching in the environment. I guess I see all this information, the way everything seems to overlap and interrelate, and wondering if there’s any way to avoid some of the ‘gotchas’ that are inherent in this kind of work.

      1. That is a really great question guys – I don’t know anything off the top of my head, although I haven’t spent a lot of time looking into it. If you find anything, by all means please post and update us all. Thanks!

    2. Michael, your spread sheet sounds like a great way to organize security settings information for any Sf org. Is there any chance you could share the template with the rest of us? If not, no problem. Thank you!

Leave a Reply