This guide is for the application administrator receiving a newly deployed installation. Infrastructure operators complete [Azure deployment](https://portal.cjcit.io/knowledge-base/message_ops/1.7/deployment/azure/) 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

1.  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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/reference/operator-commands/#administrator-bootstrap) if needed.
2.  Complete mandatory MFA enrolment on **Complete sign-in**. Save recovery codes securely and acknowledge that they are saved. See [authentication and profile](https://portal.cjcit.io/knowledge-base/message_ops/1.7/getting-started/sign-in-and-profile/).
3.  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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/administration/licensing/).
4.  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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/administration/sso/), 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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/administration/sso/#identity-and-role-mapping).

## 3\. Connect environments and define scope

Open **System → Environments** and follow [Manage environments](https://portal.cjcit.io/knowledge-base/message_ops/1.7/administration/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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/administration/users-and-access/).

## 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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/administration/users-and-access/#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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/administration/service-accounts/) and [API authentication](https://portal.cjcit.io/knowledge-base/message_ops/1.7/reference/api/). 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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/operations/observability/).

## 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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/), [message workflows](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/messages/) and [common errors](https://portal.cjcit.io/knowledge-base/message_ops/1.7/troubleshooting/). Record the validation result and hand operating responsibility back to the [production runbook](https://portal.cjcit.io/knowledge-base/message_ops/1.7/troubleshooting/).