Overview
If your company requests audits around feature access, or if you want to distribute permissions with transparency and future flexibility in mind, we suggest creating groups that let you assign permissions in a way that maximizes both.
Because access needs and privacy preferences vary, and new Users can be created in different ways, there is no one-size-fits-all approach to organizing Group Permissions. Instead, this article outlines general rules to help you keep permissions organized and transparent.
What You'll Need
| Features | Group Permissions |
| Permissions | Admin role OR Users & Groups Administration = Yes |
Supporting Resources
Instructions
Because group and permission structures depend on many individual factors, this recipe doesn’t provide step-by-step instructions throughout. Instead, think of it as a guide for dividing permissions across multiple groups.
To start, we've provided a list of general rules to consider as you plan which groups to create. Next, you’ll find a table that summarizes the suggestions in an easy-to-reference format. Finally, a couple of screenshots show what these suggestions look like once implemented.
General Rules
Set Foundational Access for All Users in the Everyone Group
A user’s permissions don’t have to come from just one or two groups. In most cases, it’s better to create different sets of groups for different types of permissions. While combining all needed permissions for each user into a single group may reduce the number of groups initially, it often means that future changes require creating new groups, ultimately resulting in more total groups and less flexibility.
Single-Purpose Groups for Yes/No or Limited Permissions
Permission settings that are yes/no or have limited options should be controlled by single-purpose groups. In other words, create a group that exists solely to provide access to that feature, and do not grant access via any other group. Examples include:
- AI Assist
- Insights
- Playbooks
Many admin-specific features follow this binary yes/no structure. If some feature accesses always travel together, you can group them in the same single-purpose group (e.g., API + Integrations).
Repository Access
For Repository access, consider splitting view and edit permissions across multiple groups for greater flexibility. For example:
- Use a group that grants View access to records most users need access to. For example, a basic Sales group for all users in the Sales department, providing view access to relevant contracts.
- Provide Edit access through a separate group for a smaller set of users. Using the Sales example, you could create a Sales Approvers or Sales Admins group for edit access, along with any other role-specific permissions.
Workflow Access
Workflow access can follow similar logic as Repository access.
Summary
| Category | Description | Example Permission Categories |
|---|---|---|
| Everyone Group | Provide baseline access that should be granted to everyone at provisioning. | ie Granting of the Dashboard/Repository tab without any specific record access |
| Single-Features Groups | For features with binary or limited permission options, controlling access through a single group lets you view all users with access by checking the group’s membership list. | AI Assist, Insights, User and Groups |
| Broad, Lower Access Level Groups | This approach grants View access to a set of records or workflows that are typically visible to larger audiences, such as an entire department. It is also a good candidate for automatic provisioning through SCORM. | Sales, Procurement, HR, Legal, etc. |
| Narrow, Higher Access Level Groups (ie Role or Department Groups) | Use these groups to layer higher levels of permission on top of the access granted by the broader groups above. Permissions like Edit and Create let you provide advanced access to specific records or workflows, and these groups can also be used to assign Approver roles in workflows. |
Sales Workflow Builders, Procurement Record Editors, etc. If needed, these can be split into narrower groups in order to further limit access to records and workflows. |
| Specific Situations | For limited, one-off, or temporary permission needs, create a separate group with a clear, descriptive name. This makes it easy to spot when a user has been granted extra permissions. | Assign Insights access to someone who doesn’t usually have it, along with view access to a larger set of records, in order to facilitate a specific reporting project. |
Transparency
This configuration of groups and permissions provides greater transparency from both the user and group perspectives.
For users, clear group names make it easy to understand which features they can access. You can also hover over a user’s group membership to view the full list.
From the group perspective, restricting a feature’s access to a single group lets you view all users who have access by checking the group’s membership.