---
title: "Roles and Permissions"
description: "A permission is a single, atomic access right — \"can view products\" or \"can create purchase orders\"."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 — grants View, Create, Update, Delete and Export together |

**Manage does not include Approve.** Approving is a separate responsibility from editing:
someone who raises and amends purchase orders is not automatically the person who signs
them off. If you want a role to approve things, tick **Approve** explicitly.

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 Role

Every new organization starts with a single **system role** 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. |

All other roles — "Admin", "Member", "Warehouse Supervisor", whatever your team needs — are yours to create from **Settings → Roles**. This keeps the initial setup minimal and lets you design the role structure that matches how your organization actually works.

A built-in role is marked **System** in the list and cannot be deleted, singly or in a selection. You can still open it to read what it grants.

## Custom Roles

On the **Roles** list, **System = No** in the filter panel is your custom roles only; the panel also takes **Active** and a **Priority** range ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)).

Create custom roles to match how your organization actually works:

1. Go to **Settings → Roles** and click **New**.
2. Give it a **name** (e.g., "Warehouse Supervisor") and optional **details** explaining what this role is for.
3. Save. The role now has a **Permissions** tab beside its details.
4. Open that tab and tick what the role may do. Permissions are grouped by module, so you can expand a module to see its resources and actions, tick them one by one, or use **Grant all** and **Revoke all** for the whole module at once. Each tick takes effect immediately — there is nothing further to 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

1. Go to **Settings → Members**.
2. Find the user and click to edit their role assignments.
3. Assign one or more roles.
4. 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](policies.html) come in.

### Checking Effective Permissions

To understand what a specific person can do, open one of their assignments from **Settings → Members** and switch to the **Effective Permissions** tab. It answers the question directly rather than leaving you to add up their roles by hand — see [Members](members.html#seeing-what-someone-can-actually-do).

> **Remember:** Roles are just the first layer. Even if a role grants a permission, it can be further restricted by [policies](policies.html), [row access rules](row-access-rules.html), or [field rules](field-visibility-and-editability.html).

Source: https://docs.beelocity.com/en/access-control/roles-and-permissions/index.mdx