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. Email addresses are compared without regard to capitalization, so two users can't differ only by it, and sign-in matches the email your identity provider sends however it is capitalized. Spaces around an email are removed when a user is added, imported or edited. When the provider sends an email that has no user, the sign-in page shows that email and asks the person to have an admin add them. Factorial attributes configuration changes and manufacturing activity to the user that performed them.
Deactivate a user when the identity should no longer sign in. A deactivated user's sign-in is refused. Deactivation preserves the user and its history rather than removing attribution from earlier activity.
Invitations
Factorial can email a user an invite naming where to sign in and which email to use. It sends no password or sign-in link.
Users with the Invite users permission send invites when creating a user (Send invite email, on by default), from a user's page, or from bulk actions. The API sends one only with send_invite: true. CSV imports and reactivating a user send none, and deactivated users are skipped.
The user's page shows the latest invite's status. Sent means the provider accepted it, not that it arrived; use Resend invite if it went missing. Failed sends retry for about two hours; hover Failed for the reason.
Sign-in Sessions
Each sign-in creates its own session, so a user may be signed in on several devices at once. Signing out ends only the session on that device.
A session expires 24 hours after sign-in by default. A deployment can set a different period, and can let an open page that shows live updates, such as a screen on the shop floor, keep its session active up to a fixed maximum after sign-in. Once a session ends, open live pages stop updating and return to the sign-in page within about a minute.
Removing a person from your identity provider does not end their existing Factorial sessions. Deactivate the user in Factorial to end every session they have.
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
The Pages permission allows trusted authors to create, rename, replace, and delete custom Pages. All signed-in users may open published pages. Each page's API calls use the viewer's own 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.
The Approve procedure permission determines whose reviews count toward a procedure's review policy. Anyone may review a procedure revision, but only approvals and change requests from users with this permission affect release. Factorial checks this permission against the reviewer's current roles each time readiness is evaluated.
The Redline permission allows a user to open, edit, submit, cancel, and apply work order redlines. Releasing a hold that a closed redline left on a task lets the task run again, so it requires the Work orders permission instead. The Approve redline permission determines whose redline reviews count toward the redline review policy, and allows rejecting a redline. Like procedures, anyone may review a redline, and approvals from the person who opened or submitted it never count.
Anyone may raise an issue, link affected records to it, and close an observation. Two permissions control what happens to affected product:
- Disposition determines whose reviews count toward dispositions whose type requires it and toward NCR cancellations, and allows applying them. This is the authority to decide what happens to nonconforming product, often held by a material review board. Assign it through a dedicated role so the roster of people with this authority, and its history, is clear.
- Design authority determines whose reviews count toward use as is and repair dispositions, or any other disposition whose type requires it, and allows applying them. These dispositions accept product that does not fully meet its design, so they are approved by the organization responsible for the design, usually engineering.
The Disposition and Design authority permissions are planned and not yet available, along with the dispositions they govern. See issues.
Some actions are limited to administrators, including changing review policies and dismissing reviews.
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.
The Analytics permission allows read-only SQL queries and CSV exports over the full analytics dataset, including calls from custom Pages and API keys.
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 keys use the user's current roles
A user API key acts as the user it belongs to, with that user's current roles. Changing the service account's roles changes what its existing keys can do immediately, and deactivating the service account stops its keys from working. There is no need to replace a key to change its access.
Everything a service account does is recorded as that account, along with the key it used. See Who did it.
See API Keys and Service Accounts for authentication and key-management guidance.