function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
IkoIko 

Access permissions via Public Groups

Is it possible to control access to objects and fields using Public Groups instead (or in addition to) of Profiles. This option exists for controlling access to shared document folders, but I have not seen it for field or object level permissions.
 
Here is the challenge: Profiles are typically assigned depending on user roles. As I understand it, users have one role across the system. Let's take Project Management as an example... you may have multiple projects in your organization, and you have a pool of resources to share for these projects, however, only Project Team Members should have access. Groups would be a good way to handle this because users can be members of multiple groups at the same time.
 
This is just one example, but I am sure this comes up in many scenarios.
 
Any suggestions? Did I miss something?
 
Thanks for your help. 
michaelforcemichaelforce

Profiles are meant as a way to decide which objects a user can access, and what they can do with those objects (edit, create, etc).  It is good to think of this as the foundation.  From there... use the Role Hierarchy, Public Groups, and Sharing Rules to determine which records each user should have access to.

So, in your example, it seems like you have several different project groups that have records owned by their members, and you want to hand pick what users outside that circle need access to those records in order to contribute to that project even though they are primarily assigned to a different project.  Then it would seem that you should use the salesforce entities in the following fashion:

profile distinquishes project members, sales reps, admins, etc.

roles allow for standard sharing of project related records, standard meaning that a manager can see what his project team is doing and define the team layout / hierarchy.

public groups are then defined to include the "roles and subordinates" or a given project and then any other user who needs access to that project's records.

lastly, sharing rules are set up to allow for sharing from a project's section of the role hierarchy with the appropriate public group defined above.

Does that help?

-Michael