Message Ops

For application administrators; start with application setup.

The admin console (Admin in the sidebar) is where platform administrators manage users, roles, authentication policy and sign-in methods, SSO, and related governance settings.

Sections

Each section has its own entry under Admin in the sidebar:

• Users
• Service accounts
• Authentication
• Roles
• Permissions
• SSO providers
• Settings
• License
• Environment groups
• Observability
• SEMP traffic

Standard users and service accounts are managed in separate sections. The Users section lists only human users; Service accounts are managed on their own page.

Users

The Users section lists standard users — human accounts that can sign in to the web UI. The list shows each user’s name and email, status, username, role assignments, SSO status, and API token status. Operations available:

• creating a new standard user with Create User
• editing an existing user
• viewing a user in read-only mode
• deleting a user
• resetting a user’s MFA configuration
• enabling or disabling API token access for a user
• generating or regenerating a user’s API token (admin)

A standard user record includes:

• display name, email, username, and account status
• role assignments and identity links
• authentication policy flags (SSO status, MFA)
• API token status (access enabled, prefix, creation date, expiry, last used)

Standard users sign in with their email address and password (or SSO). There is no “user type” choice on the form — creating from the Users section always creates a standard user. An admin can enable API access per user, allowing them to generate a personal long-lived API token from their profile page.

Service accounts

See Service Accounts for Sponsors, tokens, IP restrictions and scoped access.

Roles

Role management allows administrators to:

• review system roles and custom roles
• create and update custom roles
• delete custom roles when they are no longer needed

Roles are the source of permissions for users in this platform. Permissions come from assigned roles only — direct permission grants are not assignable.

Role assignment scopes

When you assign a role to a user, you choose a scope: Platform, Environment, Group, or Queue (the available scopes depend on the role’s permissions). For a Queue-scoped assignment you must select an environment first — this loads the Message VPN options — then choose a VPN and one or more queue patterns. A queue-scoped assignment cannot be saved without a Message VPN; this is enforced in both the form and the API.

Authentication policy and sign-in methods

Open Admin → Authentication. Administrators can tune the authentication policy:

• whether local password auth is enabled
• whether MFA is required for local users
• whether MFA is required after SSO sign-in
• whether MFA is required for administrators
• whether MFA is required for platform administrators
• which MFA methods are allowed (WebAuthn/passkeys, TOTP)
• the preferred MFA method
• whether recovery codes are enabled

Under Sign-in methods they also control:

• whether Local password sign-in is allowed
• whether SSO sign-in is allowed (it needs at least one enabled SSO provider)
• the Default sign-in method presented to users (local password or single sign-on)

At least one sign-in method must remain enabled, so the last usable method cannot be switched off. Save with Save Authentication Settings.

SSO providers

See Single Sign-On for provider setup, trust, metadata import and identity binding.

Environment groups

Environment groups are named collections of environments that can be permissioned as a single unit. Instead of creating one role assignment per environment, assign a role to a group and the assignment automatically covers every environment in that group.

Managing groups

Navigate to Admin → Environment groups to:

• view all groups with their member count
• create a new group (name required, description optional)
• edit a group’s name or description
• delete a group (blocked if any role assignments reference it — remove those assignments first)

Creating, editing, deleting, or replacing group members requires a recent reusable MFA step-up. Opening the page and viewing group details or assignments does not prompt for MFA.

Managing group members

Open a group’s detail view and use the Member environments field to add or remove environments. Saving replaces the full member list atomically. An environment_group.members.replaced audit event is recorded with the added and removed environment IDs.

Assigning roles to a group

Anywhere you can assign a role — a user’s admin page and Group-to-role mappings — a Group scope option is available alongside Platform and Environment. When Group is selected, use the group search field to pick the target group.

The role is immediately active for all environments currently in the group. Membership changes take effect:

• immediately for API token users (principal is resolved on every request)
• additions are visible at next sign-in for session users; removing an environment immediately revokes affected sessions, including SSO-derived assignments

Assignments view

The group detail page includes a read-only Role assignments panel showing every user and SSO group mapping that references this group, along with the role granted.

Group-to-role mappings

Group-to-role mappings (under Admin → SSO providers) map external identity groups to internal roles, optionally scoped to:

• the platform
• a specific environment
• an environment group

These mappings can be enabled, prioritized, edited, and deleted.

Observability

See Monitoring and Logging for up to ten telemetry destinations, credentials and connection testing.

Settings

The Settings section contains platform-wide configuration:

API token lifetime

Controls the lifetime of newly generated API tokens (both personal tokens for standard users and service account tokens). The value is in days and must be between 1 and 365. The default is 90 days.

Changing this setting affects only tokens generated after the change — existing tokens retain their original expiry.

Data retention

Controls how long the platform retains records before the scheduled purges remove them. Each value is a number of days (maximum 3650). Audit accepts 0 or 90–3650; message references and compliance evidence accept 1–3650:

• Audit events retention — enter 0 to retain audit events forever.
• Message references retention.
• Compliance evidence retention — applies to evidence generated after the change; existing bundles keep their original expiry.

When no value is saved here, the platform falls back to the retention defaults configured through environment variables. Retention changes are recorded in the audit log and require recent MFA. Reducing audit retention, including changing forever to a finite period, additionally requires Global Admin. Platform Admin may increase it or choose forever. Changes cannot restore already deleted records.

Dashboard content

Edits the platform landing page shown when no environment is selected. You can set the Title, a Welcome message, and a list of Notices (each with an Info, Warning, or Critical severity). The Dashboard’s Edit Dashboard action links here. Save with Save Dashboard.

KPI screen-reader announcements controls the platform-wide default on the scoped operational dashboard. Choose Off, Significant changes only (the default for existing installations), or All changes. Significant mode announces only increases in Failed jobs and Denied/Failed audit; the audit counter is included only for users permitted to read audit events. All mode combines changed numeric KPI values into one polite announcement. Initial loads, environment/VPN changes, and recovery from unavailable/error values establish a baseline silently. This setting affects announcements only; visual KPI cards are unchanged. Save it with Save Dashboard, using the existing recent MFA verification and audit trail. There is no per-user override.

Persistent dashboard notices remain ordinary content, including critical notices. Notices with a server-generated ID receive one polite announcement per browser session; legacy notices without an ID remain visible without an announcement. If session storage is blocked, notices remain visible and are not announced.

License

The License view shows the active license status, the installation ID, the licensed limits (environments and queues), and current usage against those limits. Platform administrators upload or replace the license here (a step-up MFA verification is required). For the full workflow — including what happens when a license is missing or expires — see the Licensing guide.

Choose a role and scope

System roles cannot be changed. A custom role may be assigned at supported scopes, but the API checks both permissions and scope. Except for Global Admin, an administrator can grant only permissions they hold across the complete target scope and cannot administer a more privileged user. A broad page permission does not combine with an unrelated assignment to authorize another environment.

Queue access and policy limits

Admin → Permissions is a read-only catalogue of permission names; it does not edit queue or topic policies. Non-global users need both the relevant scoped permission and a matching access policy for broker operations. An environment/group role alone does not supply that policy.

For a human user’s queue workflows, use the supported queue-assignment form:

1. Open the user under Admin → Users and edit their role assignments.
2. Assign Queue Viewer for reading or Queue Operator for permitted mutations, using Queue scope.
3. Select the environment, Message VPN and queue patterns. * does not cross / in a queue pattern. Include the intended destination queue in the authorized scope when copying or moving messages.
4. Save, complete any required MFA and test with that ordinary user after a fresh sign-in. For a personal API token, these must be manual assignments; SSO-derived grants do not apply to the token.

Human queue assignments also provide matching queue access policies. SSO queue mappings can provide this access for sessions authenticated through their source provider. Neither method grants topic access.

Service-account broker access and topic publishing require matching persisted policies in addition to scoped role permissions. v1.7.1 has no customer policy editor or policy CRUD API, and a service account’s queue role does not supply a matching service policy. If your installation does not already have the required policies, these workflows cannot be enabled through the documented UI/API alone. Ask your supplier to establish whether an approved provisioning procedure is available before planning them; this guide does not assume one exists. Do not substitute Global Admin or direct database edits for a supported provisioning procedure. Test the actual principal and source/destination scope before accepting an integration.

SSO-derived assignments appear read-only with their provider/group provenance. Successful sign-in reconciles that provider’s grants; mapping eligibility changes revoke sourced grants and invalidate affected sessions immediately. External IdP changes are learned at the next successful sign-in. Manual and legacy grants need separate review. Local-password sessions and personal tokens use manual assignments only; see Single Sign-On for the full lifecycle.

SEMP Traffic controls polling and metadata cache settings. These are separate from authentication policies and message permissions.