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):
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:
I could configure the sharing criteria for 3 folders to include these roles. Or, I could create a public group with the roles:
Then share access to each folder with the group:
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
- 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).
- When groups are referenced in sharing rules, “Grant Access Using Hierarchies” can be extended to group access.
Hi John,
What do you mean the second point in the note section “When groups are referenced in sharing rules, “Grant Access Using Hierarchies” can be extended to group access.” Can you explain with a usecase/ an example?
AJ
VP Sales & Marketing
-Sales Manager
–Sales Rep
-Marketing Manager
–Marketing User
User A- assigned to Marketing User
User B- assigned to Sales Rep
User C- assigned Sales Manager
Group X- contains User A
Grant access via hierarchies checked
Sharing rule: records owned by Group X shared with role Sales Rep
User B gains access to User A’s records via sharing rule
User C gains access to User A’s records via inheritance through group (via sharing rule)
Without granting access via hierarchies user C would not gain access
Thanks John.
Hi John,
Could you share the steps to navigate to this page? Much appreciated.
AJ
You can search “Public Groups” in setup
Ok, just so I understand what has been said in this thread……
Are you saying that, using current versions of SF, that setting up Groups is not really necessary if you have Enhanced Sharing checked?
It all depends – in the old folder sharing model you couldn’t name a user specifically, so you had to use a group. There are many cases where you will want to create a group (naming 50 users that are shared across 4 folders, for example).
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?
I will take a look at beefing up this section – thanks for the feedback
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
Either would work- if you want to share all/most (without manually adding to each record) then I would use a sharing rule.
Thank you
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
I will keep that in mind for material edits!
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.
This should be available in all editions – I would contact Salesforce to see why the menu is not there. https://help.salesforce.com/htviewhelpdoc?err=1&id=analytics_sharing_enable.htm&siteLang=en_US
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
Good Q. If you have enhanced sharing for reports and dashboards enabled (for new orgs it is), then no a group is not required for reports/dashboards.
Otherwise (and in other areas of configuration such as list views) groups are required.
https://help.salesforce.com/htviewhelpdoc?id=analytics_sharing_enable.htm&siteLang=en_US
Hi,
This is another page that is not showing the screen shots. I had to copy and paste this page in a Word Doc.
Thanks
Synthia – I would recommend trying another browser, such as Chrome. I haven’t seen this reported by anyone else.
Typo:
“such sharing rules”
should be “such as sharing rules”
Thanks! Updated
Saw the screenshot later. understood. Thanks!
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.
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.
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?
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.
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!
I’m poking into these:
* Config Workbook: http://www.configworkbook.com/
I* DE install required, but interesting:
http://www.salesforcehacker.com/2013/10/visualizing-users-permissions-across.html
Now that I think of it – I have used something like the template listed here: http://www.adminhero.com/how-to-document-your-salesforce-instance/
Links above look interesting as well
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!
Hi John
some of the material seems to be blank on this page. The roles are not mentioned are missing information.
Not sure I follow – this page is for groups, not roles?