Organization roles#
| Role | Scope and expectations |
|---|---|
| organization_admin | Organization-wide administration, provider configuration, audit and delivery-health access, plus incident response. |
| team_admin | Incident response and selected team-scoped API actions. This role does not unlock all organization-admin configuration screens. |
| responder | Read operational context and take permitted incident response actions. |
| viewer | Read access without incident acknowledgement/resolution or administrative mutations. |
Create and maintain a user#
- In Users, create the person with their email, display name, timezone, role, and active state.
- Set an initial password if password login will be used, and share it through an approved secure process. There is no email invitation workflow in this release; with single sign-on, directory sign-in or SCIM, the identity provider can create accounts instead.
- Add team memberships and configure available contact details and notification preferences.
- Test sign-in and delivery as the intended user. After changing a role, sign out and back in to refresh the navigation.
Deactivation and least privilege#
Use the lowest sufficient role. Before deactivating a responder, update schedules and escalation targets to preserve coverage. Inactive users cannot continue normal authentication. Organization administrators should review team membership, active users, and provider access regularly.
Sign-in methods#
| Method | Configured in | Suits |
|---|---|---|
| Local password | Users (an administrator sets the password) | Break-glass administrators and small teams. |
| Single sign-on (OpenID Connect) | Identity, or deployment-wide environment variables | Keycloak, Microsoft Entra ID, Okta, Authentik, Google Workspace and other OpenID Connect providers. |
| Directory sign-in (LDAP / Active Directory) | Identity | Sites with a directory but no OpenID Connect provider. |
The methods can be mixed per organization, and password sign-in keeps working while SSO or LDAP is enabled. Sign-in uses the organization slug. With Create accounts automatically, a first directory sign-in creates the user with the configured default role; otherwise an administrator adds the account first. Group mappings tie directory groups to teams, team roles and organization roles, and are applied at each sign-in. An SSO account is pinned to its issuer and subject on first sign-in, and later mismatches are refused.
Changes in the directory reach AckNexa at the next sign-in, and a person disabled in the directory keeps an existing session until it expires. Deactivate the user in AckNexa as well, or use SCIM, when a departure is immediate.
SCIM provisioning#
SCIM 2.0 lets Okta, Microsoft Entra ID or Keycloak create, update and deactivate AckNexa users and keep group memberships current, so a departure stops paging at once instead of at the next sign-in. SCIM provisions accounts and groups; people still sign in through SSO, and SCIM-created users have no password.
- Open Provisioning (SCIM) under Identity, enable provisioning and choose the role for new SCIM users: team admin, responder or viewer (default responder).
- Generate the SCIM token and copy it; it is shown once and only its hash is stored. Rotate replaces it immediately and Revoke removes it.
- Configure the identity provider with the base URL PUBLIC_API_URL/scim/v2 and the bearer token, mapping the user's email address to userName.
- Assign test users and groups, then check the last change and last error shown on the Identity page.
Deactivation never deletes a user: it marks the account inactive, revokes every session, disables the person's mobile device tokens and stops them being paged, in one transaction. AckNexa refuses to deactivate the last active organization administrator. SCIM groups use the same group mappings as SSO and LDAP, so use one source of truth for groups. Bulk operations, sorting, ETags and password changes are not supported.
Break-glass accounts#
Keep at least one break-glass account: a local organization administrator with a password, marked Break-glass account in Users. Only organization administrators can set the flag, from a signed-in session, and only on an active organization administrator with a local password.
- SCIM can read the account but every write to it is refused with 403 and audited, including the deactivation an identity provider sends on unassignment.
- Group mappings never change its role or team memberships.
- An SSO or LDAP sign-in with its email is refused and audited; it signs in with its password only.
- While the flag is set, it cannot be demoted or deactivated from the Users page, and API keys cannot edit it.
- Identity warns when SCIM is on without an active break-glass account, and when one has not signed in for 90 days. Sign in with it now and then so you know the password still works.
Organization boundary#
Tenant-scoped API queries and database relationships use the organization boundary. A valid account in one organization does not grant access to another organization's resources. The current read model is not a promise of per-team concealment of every incident inside a shared organization.
Several organizations on one deployment#
One deployment can host several organizations; users, teams, services, integrations, incidents and device registrations are all scoped to their organization. First-run setup creates only the first organization. The operator creates each further organization, with its first administrator, using the bootstrap command in the backend image; it also creates a default team, escalation policy, service, schedule and four integrations, and prints their webhook secrets once. There is no API or Web screen for adding an organization, and no organization delete.