## ION’s Access Model

ION’s access model has three building blocks:

- A **user** is an individual with sign-in credentials.
- A **role** is a named, reusable set of permissions.
- A **team** is a group of users you assign, notify, and route sign-offs to together.

## How Permissions Flow

Permissions attach to roles, never to users directly. A user’s access is the union of every role they hold, whether assigned to them directly or through a team they belong to. Roles are **additive**: adding one only grants access, so to narrow what someone can do, give them a role with fewer permissions rather than trying to subtract. Teams hold no permissions of their own, but a role assigned to a team grants its permissions to every current and future member. Permissions are organized into groups by feature area. Every create, update, and delete action has a permission; read actions generally don’t, and read access is managed separately. Changes take effect immediately, and removing a permission from a role removes it from every user and team that holds it. To see a user’s effective access, combine the roles on their profile with the roles from their teams.

## Provisioning

| Approach | How it works |
| --- | --- |
| Manual | Invite users and assign roles directly in ION. |
| SSO with role mapping | Roles map from your identity provider’s groups (Okta, Entra ID) when users sign in. See [Set up SSO](https://docs.firstresonance.io/administration/authentication-settings/sso/set-up-sso). |

## Common Roles

Most manufacturing organizations converge on a handful of roles:

| Role | What they can do |
| --- | --- |
| **Operator** | Run procedures, file issues. Can’t edit procedures or close their own runs. |
| **Lead Operator** | Everything an Operator can do, plus run review and close. |
| **Manufacturing Engineer** | Author procedures, manage parts, schedule runs. |
| **Quality Engineer** | Manage issues, dispositions, CAPAs; read across the org. |
| **Buyer / Planner** | Manage POs, receipts, inventory. |
| **Admin** | Org settings, users, integrations. |
| **Read-only** | View everything, change nothing. |

**Admin** and **Read-only** are system roles: grant them directly to a user, not to a team.

Pick role names that age well (“Operator,” not “FactoryFloorTier1”): renaming a role in use across many users is painful. Keep admin and org-settings access to a small circle, and review role permissions periodically as people change jobs.

## Permissions Reference

Permissions control which actions a role can perform, and you assign them to roles, not to individual users. Read permissions (what a role can view) are managed separately and aren’t listed here. To add permissions to a role, see [Manage role permissions](https://docs.firstresonance.io/administration/users-and-permissions/manage-role-permissions).

| Permission | Description |
| --- | --- |
| `addAssetToItem` | Add an existing file attachment as an asset to an item. |
| `addFileAttachmentToItem` | Add an existing file attachment to an item. |
| `addHeaderToWebhookReceiver` | Add headers to a webhook receiver configuration. |
| `addInputToPlan` | Add inputs to a plan. |
| `addInventoriesToReceipt` | Add multiple inventories to a receipt. |
| `addInventoryToPurchaseOrderLine` | Add inventory to a purchase order line. |
| `addInventoryToReceipt` | Add a quantity of inventory to a receipt. |
| `addItemsToReceipt` | Add items to a receipt from a purchase order, or without a PO. |
| `addLabelToItem` | Add labels to an item (run, procedure, kit, etc.). |
| `addLabelToProcedureFamily` | Add labels to a procedure family. |
| `addOauthRedirectUri` | Add a callback URL or allowed origin to an OAuth app. |

... (the complete list of permissions can be similarly transformed) ...