Skip to main content
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

Common roles

Most manufacturing organizations converge on a handful of roles: 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.