Onboarding a client¶
Onboarding is the one part of the workflow with genuine Microsoft-side steps. The goal is a client tenant the platform can resolve tickets to and execute against — with delegated access you can prove, not a password you store.
There are five surfaces to get right. Four are in-app; the fifth (GDAP + consent in Microsoft) is the real work.
1. Establish GDAP¶
Set up a granular delegated admin (GDAP) relationship with the client tenant, scoped to the roles the platform needs to do its job (identity, Exchange, and — where used — compliance administration). GDAP is time-bound and role-scoped by design: the platform never holds standing global admin, and access expires unless renewed.
Scope to what you'll actually run
Grant the admin roles that match the operations you expect to perform for this client. You can widen scope later; start with what onboarding and everyday tickets need.
2. Consent the platform's app access¶
The platform acts through its own app registrations (a Graph app and an Exchange app) using application permissions, authenticated with certificates — not user passwords. An administrator grants admin consent for those apps in the client tenant.
Until consent is granted, discovery and execution calls for that tenant will fail with a permissions error. This is expected — grant consent, then re-run discovery.
3. Register the tenant and discover execution access¶
Add the client in the Portal, then let the platform discover what it can execute. Discovery probes each workload (Graph, Exchange, and compliance where enabled) and records, per workload, whether the platform can actually authenticate and act.
The result is a per-tenant readiness picture:
| Signal | Meaning |
|---|---|
| Ready for execution | The platform authenticated to the workload and can run operations. |
| Consent / permission pending | The app or GDAP grant isn't in place yet — finish steps 1–2 and re-discover. |
| Not reachable | The tenant record or connection details need attention. |
Vanity-domain tenants
Exchange and compliance operations connect using the tenant's *.onmicrosoft.com organization, which is not the same as a client's primary vanity domain. The platform captures and stores that organization during onboarding so execution works on vanity-domain tenants without extra steps.
4. Confirm ticket → tenant resolution¶
When a ticket arrives, the platform resolves it to a managed tenant automatically — by the requester's email domain and other hints. A ticket only proceeds to planning once it has resolved to a single tenant. If resolution is ambiguous or the tenant isn't onboarded, the ticket is held rather than acted on.
5. Connect a PSA¶
Connect the client's PSA so tickets flow in. In the Portal, Settings → PSA connectors, choose the system (HaloPSA today), and enter the connection essentials. Sensible defaults for endpoints and options are pre-filled — you generally only supply what's genuinely per-customer (the instance URL and the API credentials).
- Credentials are stored as secret references, never in plain text.
- You can send a test and confirm tickets pull before going live.
- A connector can be disconnected later, which clears its credentials and stops ingestion.
No PSA yet? You can still work
While a client is being set up you can pull tickets on demand or enter them directly, so onboarding and testing don't have to wait on the PSA connection.
Once a client shows ready for execution and tickets resolve to it, you're ready to run the platform.