Set up your first customer

Create a customer organization, appoint its first administrator, then hand over workspace creation and setup to the customer.

How-to · Updated 2026-10-26 · Describes release 0.1.164

Before you start

Sign in with a platform-staff (superadmin) account. In these chapters, platform staff means whoever holds a superadmin account on this installation; after handover, that is your own platform administrators. Have the customer's organization name, an organization slug and the intended customer administrator's email. A customer organization is a Group; a workspace is a Tenant and holds the isolated operational data. Creating either does not create or invite a user account.

Platform prerequisites before the first customer

Check these with a staff account before creating the customer organization. Each row names the evidence to keep.

Record the deployment build and any prerequisite that remains unresolved before the handover. A runtime heartbeat alone does not prove a datasource read.

1. Prepare the customer administrator account

Open Users (in the product: /ops/users) under Platform. Create the local account with New user, or have the customer administrator sign in once through the configured SSO issuer so the account is provisioned. Confirm that the email matches the intended administrator.

Leave Superadmin unticked in Create user. A superadmin account cannot hold an organization role: step 3 refuses it with platform staff cannot hold a group role — use support access (HTTP 422). This also rules out admin@local, the installation's bootstrap superadmin. The console has no control to clear the flag afterwards; see Limits and gotchas.

Expected result: the customer administrator account is listed and active. Share initial access through your organization's secure process; this console does not send an invitation email for you. Whoever knows the password you set can sign in as this administrator, and after step 3 that includes seating itself in any of the organization's workspaces. When an email relay is configured, send Email reset link from Users (in the product: /ops/users) after step 3 so the administrator chooses a password nobody else has seen; where the customer has single sign-on through the configured issuer, provision the account that way instead. Only this first account needs the console: once it owns a workspace, the administrator invites colleagues from the portal (Members & roles → Invite member), which creates the account and shows a one-time link to set a password — emailed when an SMTP relay is configured, copied and sent by hand otherwise.

2. Create the customer organization

Open Customers (in the product: /ops/customers) and select Add customer. In Create customer organization, enter Customer name and Slug, then select Create customer.

Expected result: one customer organization appears, initially with no workspaces. This action does not create a workspace, choose its owner or record a subscription/payment status. Organization access is a separate explicit choice on the customer detail page.

3. Appoint the first organization administrator

On the new customer detail, open Organization access, select the existing User, choose Role → Administrator, and select Update organization access. Creating the customer record does not perform this step automatically.

Expected result: the intended account is an administrator of this customer organization. Share Workspaces in the customer portal (in the product: /portal/organization) with that person. Organization administration lets them manage their own workspace structure and members; it does not itself grant access to existing workspace content.

4. Hand over workspace creation to the customer

Adopt the workspace the installation created. The installation smoke test already created the first workspace: its slug and its name are the TENANT value the smoke ran with, its owner is admin@local, and it belongs to no organization (on Workspaces (in the product: /ops/workspaces) its Customer organization reads Unassigned). It holds the smoke's synthetic incident (service aiops-smoke-<number>), and its webhook token is the one the smoke minted. Do not create a second workspace for the same estate:

1. On the customer's detail under Customers (in the product: /ops/customers), expand Workspace assignment, choose the workspace under Existing workspace, select Assign workspace and confirm Assign workspace.
2. The customer administrator opens /portal/organization, finds the workspace, and under its Members controls enters their own Email, chooses Role → owner and selects Add / set. To give the workspace a display name, they change Name and select Rename.

Expected result: the workspace lists the customer organization, and the customer administrator is one of its owners. admin@local stays an owner until someone removes it there with Remove. Keep it while the upgrade smoke runs against this workspace: the supplied smoke signs in as admin@local by default and reads its investigation as that account, and an account that is no longer a member gets HTTP 404 there (Upgrade and verify). Resolve the smoke's synthetic incident from its page with Mark resolved so it leaves the open backlog; the service-delivery report still counts it among the incidents opened and resolved in its period.

For each further workspace, the customer administrator opens /portal/organization, whose page title is Workspaces. Under New workspace, they enter Name and Slug, then select Create workspace. The workspace is attached to their organization, and its creator becomes its owner. They select Open workspace and connect data to continue setup.

The customer chooses its own application, team or environment structure and adds existing user accounts through each workspace's Members controls. Staff do not need to create and assign every workspace. Hand over Getting started for the operating path: read connection → discovery/context → optional approved-execution access → alert → incident and follow-up chat.

5. Verify the runtime and setup

All features are included for every enabled tenant/workspace. There is no grant or owner acceptance step.

Review the Pillar agents card and enabled agents. For a private network, provide the private-agent installation guide and publish the actual agent image under Customer connection setup (in the product: /ops/platform#connection-setup). Verify its model gateway and a real datasource read.

Expected result: the intended agents and runner are available, and connection checks show actual access. A heartbeat alone does not prove a datasource read.

6. Support and verify

Use the workspace's Staff data access card only when temporary customer-content access is required. Grant yourself a time-limited, audited support membership, then open the customer portal. Revoke the grant when support work is finished.

Review the Audit log (in the product: /ops/audit) under Config for platform changes and Billing (in the product: /ops/billing) under Platform for aggregate usage. Deactivation stops tenant use while retaining its records; it is separate from data deletion.

Optional: staff-assisted workspace setup

If the customer explicitly needs help, staff can use Create standalone workspace under Workspaces (in the product: /ops/workspaces), provide the existing owner's email, then explicitly assign the new workspace from the customer's Workspace assignment controls. This is an optional support path. See workspace creation and assignment for its membership effects.

Customers and workspaces · Platform configuration · Connecting the LLM gateway.

Next steps

• Next: Customers and workspaces
• All Install and operate the platform pages
• Documentation home