Bridging Gaps Through Technology
Blog Home

Best Practices Around Salesforce Security Groups

What Is a Salesforce Group?

If you’re reading this, you are somewhat familiar with Salesforce and maybe even its groups construct. Essentially, a group is a group of users with the same level of access to specific records within the organization. Salesforce offers some great explanations on groups.

Here’s an example: Say there is a marketing department Company Inc., that has just started using Salesforce. Company Inc. can establish a unique set of rules for each department that would later be applied to their respective groups in Salesforce.

Imagine that within Company Inc.’s marketing department, a subgroup has been asked to work on a new marketing strategy, that requires information that normally only the accounting department has access to. It would be inefficient for the marketing department to go through someone in the accounting department every time someone needs information. Adding the marketing team members to the accounting department group, however, would be a serious internal security flaw. Here the need arises to give some, but not all, members of the marketing department access to only some, but not all, accounting information.

This problem can be solved by constructing a new group that has specific permissions to marketing and accounting information. The small subgroup of marketing team members would remain part of the marketing department’s Salesforce group, they just now have more access as long as this newly created group is active and the staff member is a member of said group.

The Who

Groups are defined through roles and group member types. Roles are essentially the specific job title: “CEO,” “Vice President of Internal Affairs,” etc. Roles are a subtype of group member type and will always be positions within the company. Group member types denote the relationship to the company, similar to roles, but do not necessarily come from within the company. For example, customer portal users and partner users are group member types for which permissions can be set, but they are not working members of the organization and do not contribute to the company hierarchy.

Be conservative with assigning permissions when setting up a group: group members should access the data necessary to perform their job functions, but no more than that.

The What

The best way to figure out how to assign permission is in a top-down fashion. Should the President of the organization have access to employee salary information? If yes, then should the Vice President have access to this information and so on and so forth. As soon as we find a level that should not have access, we can safely assume that their subordinates also do not need that level of access and move on to the next object permission, saving us a little time for each object. The most important thing to take away here is that the level of access of each person should be determined before assigning permissions. This will keep the rest of the process simple and straightforward.

The next thing to consider is whether permission for a certain task should be permanent or temporary. If the changes are permanent, it may be better to alter permissions in the role or profile. If the changes are temporary, it may be better to create a new permission set or group. In order to experience the true power of Salesforce, roles, profiles, and permission sets should be used in tandem with groups so that every single employee has exactly the level of information they need.

Roles, Profiles, and Permission Sets

Let’s expand on the Company Inc. example further: Sharon, a member of the marketing team, needs even more access to accounting information than the rest of her group? It would still be insecure to simply put Sharon into the accounting group. If a new group was made every time someone in the organization needed unique permissions, the groups would eventually become far too unmanageable. This is where roles, profiles, and permission sets come into play.

The Salesforce Admin can create a unique role for Sharon to access the specific accounting records that she needs. By default, Sharon’s permissions from her role trickle up to her superiors. Sharon’s permissions are based on the role or group that grants a higher level of access

By editing a profile, the level of access can be determined by each individual field. If Sharon’s profile also needs to be configured to only view certain fields of a record while others remain hidden, Sharon’s profile can be altered.

Set of individual field
Permission sets should be used If permissions need to be granted to up to a select few individuals for a limited time on a field by field basis. Permission sets are defined once, and can then be applied to user profiles individually. Permission sets are part of one’s profile but do not alter the base settings of their profile. It is more of an addendum, like a sticky note with extra permissions on it that you attach to a notebook page of permissions. This makes granting temporary access very easy. Permission sets can be activated and deactivated so there is no need to remember someone’s permission settings before granting more permissions either. One can simply remove a permission set from an individual’s profile, like pulling a sticky note off of the notebook, to remove individual access while keeping the permission set active. Alternatively, one can also delete the permission set in general, removing the access from everyone with that permission set in their profile. Let’s talk about some criteria for creating groups.
criteria for creating groups

Now You Know How; Here’s How to Well

And now for the main event! Now that you know a little about groups in Salesforce, we can finally get to some good practices to ensure that your data is as secure as possible.

1. Audit regularly: Change is a natural part of growth, and organizations are no exception. It makes sense that as your organization changes, so will the privileges that should be available. Auditing the privileges of all members of the organization is crucial to maintaining the integrity of the data of your organization. It will prevent privileges from accumulating on old accounts and users, and may even reduce some redundancies of your groups and permissions sets because there will be at least one person with detailed knowledge about the hierarchical structure of your organization.

2. Use the principle of least-permissions: As stated before, groups should only be able to see as little information as necessary in order to still complete their work. This ensures that all unnecessary data, regardless of content, is safely protected from any possible internal threats. Assign divisions that will need permanent access to the same records to groups. Assign roles to individuals that will need permanent access to records their group does not have permissions to access. Assign permission sets to individuals that will need temporary access to information that their group does not have permissions to see.

3. Keep it simple: The organization should be developed using as few groups as possible. By using as few groups as necessary, the data stays restricted, leaving fewer users as potential vulnerabilities. It is also easier to manage.

4. Utilize roles, profiles, and permission sets: Roles, profiles, and permission sets make up for all possible impediments created by using groups. No matter what type of access someone needs and no matter how long they will need it, Salesforce has ensured that you will be able to give them this access as quickly and fluidly as possible.

Salesforce does a great job of providing the tools for us to secure our data. By utilizing good practices, you can create complex but secure hierarchies that allow your business to blossom without worrying about security vulnerabilities from within your organization.

The following two tabs change content below.
Christopher Mudd

Christopher Mudd

Christopher Mudd is a senior at the University of Maryland, College Park, double majoring in Psychology and Computer Science. He is passionate about software development and hopes to someday develop something used ubiquitously throughout the world. When he is not learning new coding techniques, he is (excitedly) preparing for his soon-to-be-son, Jaxon.
Christopher Mudd

Latest posts by Christopher Mudd (see all)

Comment Image

Leave a reply