Algebrix Identity Tenant Provisioning and White-Label Handoff (Onboarding)

Algebrix Identity Tenant Provisioning and White-Label Handoff (Onboarding)

1. 01

   Confirm the client's identity scope before touching the Algebrix Identity admin console

   Decide which of the four workloads the tenant covers: customer identity (CIAM), workforce identity, B2B multi-tenancy, or AI agent authentication. A B2B client with reseller tiers needs organization isolation configured from the start; a workforce-only engagement does not. Getting this wrong means re-provisioning later, and the platform's published setup complexity is 'medium', so a guided path beats a self-serve rollout.

2. 02

   Provision the tenant using the organization slug and user directory

   Create the tenant record, set the organization slug, and import or sync the initial user directory. For B2B engagements, confirm per-tenant role definitions at this stage rather than after go-live, because role-based access control with custom roles is scoped per tenant.

3. 03

   Connect client applications via OIDC/OAuth 2.0 or the management API

   Register each client application as a connection. Use OIDC/OAuth 2.0 for standard web and mobile apps; use the management API where the client's own backend needs to issue or revoke identities programmatically. If the client runs AI agents, register those as machine identities on the same tenant rather than a separate deployment.

4. 04

   Enforce MFA and map custom roles to each application

   Turn on MFA for the tenant, then bind the custom roles defined in step 2 to specific application scopes. Test with one admin account and one end-user account per role before opening access, since a misconfigured role is the failure mode that erodes client trust fastest.

5. 05

   Apply white-label branding and bind the custom domain

   Replace default login pages with the client's brand styling and attach the client's custom domain so end users never see Algebrix Identity branding. This is the step that makes the platform resellable as a managed service rather than a visible third-party dependency.

6. 06

   Choose and document the deployment model

   Select cloud, self-hosted, or dedicated infrastructure based on the client's compliance posture. Healthcare and fintech clients in the target profile usually require self-hosted or dedicated. Record the choice in the client runbook, because it determines who owns patching and uptime.

7. 07

   Set audit log retention and export policy per client contract

   Configure retention windows and export destinations to match what the client's compliance framework requires. Retention policy is a per-tenant decision on this platform, so it belongs in the handoff document, not in a default.

8. 08

   Hand off the admin runbook and train the client team

   Deliver documentation covering user management, role changes, and SSO connection additions, then walk the client's admin through the dashboard. Agencies running this as a retainer should retain the management API credentials and treat tenant changes as a change-request workflow.