Appearance
Users, Roles, and Permissions
Table of Contents
Factorial uses users, roles, and permissions to control access and attribute activity. A user identifies a person or service account. Roles group permissions, and permissions authorize specific actions.
Users
A user has a unique email address, a display name, an active status, and one or more roles. Factorial attributes configuration changes and manufacturing activity to the user that performed them.
Deactivate a user when the identity should no longer sign in. Deactivation preserves the user and its history rather than removing attribution from earlier activity.
Roles
A role is a reusable set of permissions associated with a responsibility, such as operator, manufacturing engineer, or administrator. A user may have multiple roles. The user's effective access is the combined set of permissions granted by those roles.
Factorial includes an administrator role with all permissions. Organizations may create additional roles, describe their intended use, assign permissions, and connect them to users.
Permissions
A permission authorizes a particular category of action, such as inviting users, managing parts or procedures, executing tasks, or creating queues. Factorial checks the required permission before allowing a protected change.
Use roles to assign permissions rather than trying to manage access independently for each user. Grant only the permissions required for the user's responsibilities and review role assignments when those responsibilities change.
Service Accounts
A service account is a Factorial user created for software rather than a person. Create a dedicated service-account user for each integration, automation, or AI agent instead of issuing an API key from an employee's account. Give each service account only the roles required for its single purpose. This limits the effect of a compromised credential and keeps automated activity attributable to the correct system.
Use a name and email address that identify the owning system, environment, and purpose. Record an accountable human owner outside the credential itself. Do not share one service account across unrelated integrations.
After assigning the required roles, create an API key for the service account. Store the key in a secrets manager, never in source control or ordinary configuration files. Revoke keys when an integration is retired or a credential may have been exposed.
API key permissions are a snapshot
When an API key is created, Factorial copies the creating user's effective permissions into the key. The key continues to use that copied permission set. Later changes to the user's roles or to the permissions within those roles do not update an existing key.
To change a service account key's access, set the intended roles, create a replacement key, update the integration, and revoke the old key.
See API Keys and Service Accounts for authentication and key-management guidance.