This guide is for the application administrator receiving a newly deployed installation. Infrastructure operators complete Azure deployment first. You need the HTTPS application URL, your founding administrator email and securely delivered password, an authenticator or passkey, and a license file or contact who can issue one.
1. Sign in and secure administrative access
- Open the application URL and sign in with your email and password. There is no browser-based first-run account creation; ask the deployment operator to complete bootstrap if needed.
- Complete mandatory MFA enrolment on Complete sign-in. Save recovery codes securely and acknowledge that they are saved. See authentication and profile.
- If the installation is license-locked, use the license remediation screen to copy its installation ID, obtain the matching license, and upload it. Complete step-up MFA if requested. Confirm the status becomes Valid; see licensing.
- Create a second accountable administrator under Admin → Users, assign the minimum suitable administrative role, and verify that person’s sign-in/MFA before treating the first account as a recovery path. Bootstrap cannot be repeated to recover a lost administrator.
2. Configure sign-in methods and SSO
Open Admin → Authentication. Production local password sign-in is controlled here, not by
AUTH_MODE=local (a development-only header authentication mode). Keep a tested local
administrative account during SSO rollout. Configure and test providers under Admin → SSO
providers, then enable SSO and choose the default sign-in method. Follow the
SSO procedure, including trusted email claims, allowed
providers/domains and Group-to-role mappings.
Verify the entire flow in a separate browser session before ending your working administrative session. A successful provider connection test alone does not prove a user’s sign-in or role assignment. Successful sign-in reconciles that provider’s mapped roles with current claims; external IdP changes are learned then. Mapping eligibility changes revoke sourced grants immediately. Review manual/legacy grants separately, and retain intentional manual grants for local recovery sign-in. See SSO role lifecycle.
3. Connect environments and define scope
Open System → Environments and follow Manage environments. Obtain approved SEMP/messaging endpoints and broker accounts from the broker owner. Infrastructure operators must provide network routes/DNS/trust before application credentials can work. Test the connection, select the environment and Message VPN, then verify queue visibility.
Use Admin → Environment groups when a role should cover several environments. Create the group, save its member environments, and review the assignments panel before changing membership: adding a member extends group-scoped access. See environment groups.
4. Grant people and automation access
Use Admin → Roles to inspect system roles and create custom roles if needed. Assign roles through Admin → Users with Platform, Environment, Group or Queue scope as allowed by the role. Queue scope requires an environment, Message VPN and queue patterns. A Platform Admin manages the platform but does not inherently operate broker messages; use appropriate environment/queue roles. For human queue workflows, assign Queue Viewer or Queue Operator at Queue scope for the intended source and destination queues. Admin → Permissions only lists permissions. Follow queue access and policy limits; environment roles alone do not supply a matching broker policy. Test with an ordinary user.
For automation accounts use Admin → Service accounts, select an active human Sponsor, assign scoped roles, configure an IP allowlist when required and securely issue its token. Broker operations also need a matching persisted service policy: v1.7.1 has no customer UI/API to provision it. Confirm that prerequisite with the supplier before accepting service-account broker automation or topic publishing. A personal token with manual queue assignments supports human-owned queue integrations. A service account cannot sign in to the Web UI. Sponsors without administrative UI access use the supported API; see service accounts and API authentication. Do not give an automation account Global Admin merely to bypass scope errors.
5. Configure product settings and telemetry
Under Admin → Settings, set API token lifetime, retention and dashboard content. Retention changes can delete records after the scheduled purge: agree requirements with the data owner first. Under Admin → Observability, configure the approved collector and test the connection. API and Worker reload saved settings; browser tracing applies on page reload. Network/CA prerequisites belong to the operator; see OpenTelemetry.
6. Accept the application
With an ordinary scoped account, verify sign-in/MFA, environment/VPN selection, Queue explorer, a bounded message search, message detail and permitted payload access. In an approved test queue, submit an operation and follow Jobs to its final item-level outcome; acceptance is not success. Verify audit visibility with an authorized reviewer. Test schedules only with a harmless approved operation and disable the test schedule afterwards.
Give users the product overview, message workflows and common errors. Record the validation result and hand operating responsibility back to the production runbook.