Overview - ION Manual

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.

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.

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) ...