Roles and Permissions
A permission is a single, atomic access right — “can view products” or “can create purchase orders”. A role is a named bundle of permissions that you assign to users. Instead of granting permissions one by one to each person, you create roles that match job functions and assign those.
This means when a new person joins the team, you assign them a role and they immediately have the right access. When someone changes roles in the company, you swap their Beelocity role and their permissions update everywhere at once.
How Permissions Are Structured
Every permission follows the pattern Module > Resource > Action:
- Inventory > Product > View — can see products.
- Inventory > Product > Create — can add new products.
- Procurement > Purchase Order > Approve — can approve purchase orders.
- IAM > Role > Manage — full control over role definitions.
Actions
Actions define what the user can do with a resource:
| Action | What it grants |
|---|---|
| View | Read-only access — can see the resource but not change it |
| Create | Can create new records of this type |
| Update | Can modify existing records |
| Delete | Can deactivate or remove records |
| Approve | Can approve pending items (purchase orders, adjustments, etc.) |
| Export | Can export data to CSV or other formats |
| Manage | Full control — implies all of the above for this resource |
Permissions are grouped by module in the interface, so when you are setting up a role you can quickly grant all inventory permissions, all procurement permissions, or pick individual ones.
Built-in Roles
Every organization starts with three system roles that cannot be deleted or renamed:
| Role | Purpose |
|---|---|
| Organization Owner | Every permission in the system. Automatically assigned to whoever creates the organization. This is the only role that can manage other Owners. |
| Organization Admin | Can manage users, roles, and invitations. Has broad view access to all resources but does not have full manage access to everything. Ideal for IT administrators or team leads. |
| Member | Basic read-only access to non-sensitive resources. A safe default for new team members who need to see data but not change it. |
These three roles provide a starting point, but most organizations will want custom roles that match their team structure.
Custom Roles
Create custom roles to match how your organization actually works:
- Go to Access Control > Roles and click Create Role.
- Give it a name (e.g., “Warehouse Supervisor”) and an optional description that explains what this role is for.
- Select permissions — they are grouped by module. You can expand each module to see its resources and actions, then check the ones this role should have.
- Save.
There is no limit to how many custom roles you can create.
Designing Good Roles
A few guidelines for building a role structure that scales:
- Name roles after job functions, not people — “Warehouse Supervisor” is better than “Ahmed’s Role” because it remains meaningful as people come and go.
- Start narrow, then expand — it is easier to grant additional permissions later than to realize someone had too much access. Begin with the minimum a role needs and add more if users report they cannot do something.
- Avoid one-role-per-person — if every user has their own custom role, you have effectively recreated per-user permissions and lost the benefit of roles. Aim for 5-15 roles for a mid-sized organization.
- Use descriptive names — “Procurement Manager” tells you exactly what this role is for. “Role 3” does not.
Assigning Roles to Members
- Go to Access Control > Members.
- Find the user and click to edit their role assignments.
- Assign one or more roles.
- Optionally set valid from and valid until dates to make the assignment temporary — useful for covering someone on leave, granting elevated access for a project, or onboarding with time-limited training access.
A user can hold multiple roles at the same time. Their effective permissions are the combination of all of them.
Effective Permissions
A user’s effective permissions are the union of all their active role assignments. If Role A grants “View Products” and Role B grants “Create Products”, the user can do both.
There is no conflict resolution needed at the role level — permissions are purely additive. A role can only grant access, never deny it. If you need to restrict something that a role allows, that is where Policies come in.
Checking Effective Permissions
To understand what a specific user can do, look at Access Control > Members, find the user, and review their assigned roles. The combined set of permissions across all their active roles is their effective access.
Remember: Roles are just the first layer. Even if a role grants a permission, it can be further restricted by policies, row access rules, or field rules.