Overview
Role-Based Access Control (RBAC) is a security model that restricts platform access based on assigned roles and permissions. Instead of configuring access user by user, you define roles with specific permissions, assign those roles to groups of users, and let the system handle the rest. RBAC in this platform is built around two special concepts you’ll use on every account: the Admin Role and the Default Role.Core Concepts
The Admin Role
Every organization has a single, automatically created Admin Role. Users in this role have one permission: Manage Users — the ability to manage user roles, user groups, and permissions. This role cannot be edited or deleted. Users who previously held the “Organization Manager” permission were automatically migrated into this role.The Default Role
The Default Role is the baseline applied to every single user in the organization, regardless of any other role assignments. Whatever permissions are toggled on in the default role, every user gets them. Additional roles assigned to a user are additive on top of the default role — they never subtract from it.For most organizations, setup is simply: configure the default role with the right baseline permissions. Only then layer on additional roles for groups that need more.
Groups
A Group is a collection of users. Roles are assigned to groups, not directly to individual users. To give a set of users a specific permission, you:- Create a group and add the users to it
- Create a role with the appropriate permissions
- Assign that role to the group
Roles
Roles define a set of permissions. Name roles based on what access they grant, not the job title of who holds them. A role like “Farm Sales Access” or “AI Tool Access” is reusable across different user groups. A role named after a specific team is harder to reuse and harder to audit. Good role names:Farm Sales Access, User Engagement Reports, AI Tool Access, Crop Insurance Policies
Avoid: Marketing Team, Andrew's Group, Sales
Initial Setup
For most enterprise organizations, initial setup follows this pattern:Configure the Default Role
Go to Settings → Users & Roles → Roles and open the Default Role. Toggle on permissions for all features the organization currently has access to.When in doubt, over-provision. Enable everything the org is used to seeing and let them dial back anything they don’t want. It’s much easier than troubleshooting why something is missing after go-live.
Create Groups for Specialized Access
If certain users need permissions beyond the default (e.g. a leadership group that should see engagement reporting, or a team with crop insurance access), create a group for them under Settings → Users & Roles → Groups.
Create Roles for Those Groups
Create a role with the relevant permissions and assign it to the group. The users in that group will now have the default permissions plus the additional ones.
Creating a Group
Add Members
Add the relevant users to the group. You can assign a role during creation if one already exists, or skip this and assign it later.
Creating a Role
Name the Role
Use a permission-describing name, not a person or team name. Good: “Engagement Reports Access”. Bad: “Marketing”.
Configure Permissions
Toggle on the permissions this role should grant. Permissions are grouped by feature area — expand each section to review.
How New Feature Permissions Work
When a new feature is released that introduces a new permission, that permission will not be automatically added to existing roles. Admins will need to go in and explicitly enable it on any role they want it applied to.Best Practices
Principle of least privilege. Start with the features all users should have access to Name roles by what they grant, not who holds them. Roles should be reusable across groups. “AI Tool Access” could apply to a sales team and a leadership group and is easy to identify what permissions belong to that role. Create groups for exceptions, not the rule. Most users should be covered by the default role alone. Groups and additional roles are for users who need something beyond the baseline.Frequently Asked Questions
Can a user have more than one role?
Can a user have more than one role?
Yes. A user receives the default role automatically, and they receive additional roles through any groups they belong to. Their effective permissions are the combined set of all of those roles. There is no limit to how many groups a user can be in.
What is the difference between the Admin Role and the Default Role?
What is the difference between the Admin Role and the Default Role?
The Admin Role has exactly one permission: Manage Users. It controls who can configure RBAC settings. The Default Role is a baseline applied to every user in the organization and defines what everyone can do. These are separate and serve different purposes.
Do I have to assign the Default Role to users?
Do I have to assign the Default Role to users?
No. The Default Role is applied automatically to all users. You only need to configure its permissions.
What happens when a new permission is introduced for a new feature?
What happens when a new permission is introduced for a new feature?
New permissions are not automatically added to existing roles. An admin must go in and enable the new permission on any role they want it applied to.
Can I check what permissions a specific user has?
Can I check what permissions a specific user has?
Yes. Use the user permission lookup in User Management to see the full list of effective permissions for any user. This accounts for the default role and all group-assigned roles combined.
What happens if a permission is missing for a user?
What happens if a permission is missing for a user?
They simply won’t see or be able to access that feature. Nothing breaks — it’s just hidden or unavailable. Identify the missing permission, add it to the appropriate role, and they’ll regain access immediately.