Onboard a tenant
A tenant is the isolated organisation every later call is scoped to. This journey reads the existing tenants first, registers the new one, waits for provisioning to finish, and confirms the public endpoints its credentials will advertise.
Complete first: nothing. This journey is the starting point.
Steps and why they come in this order
| Step | Why here |
|---|---|
| 1. Review existing tenants | Slugs are permanent host labels. Check that the organisation does not already have a tenant before creating another. |
| 2. Register the tenant | Registration creates the isolation boundary and starts provisioning. Nothing tenant scoped exists until it completes. |
| 3. Confirm public endpoints and runtime discovery | Later steps take base URLs from discovery, not from the slug. Confirm the tenant is reachable where its credentials will point. |
Who runs this journey
The platform operator runs every step here with platform operator authorization, on the platform origin rather than on a tenant host. Tenant-scoped configuration starts only after the tenant owner has activated their account and registered a confidential tenant application, which is described on the Platform foundations overview.
Deeper reference
Onboard a tenant walks the same sequence with captured requests and console screenshots. First tenant covers deployment-side failures.
Next journey
Continue with Connect Azure KMS with BYOK and BYOC.