#Clients

5 min read

The Clients page is the partner view for assigned or partner-managed client accounts. For partner roles it is an assigned-client directory and filter, not a client-control workspace: selecting a client applies the client filter across the partner surfaces (Projects, Monitor, Billing & Support) and opens a bounded summary. Client provisioning and partner-member assignment are partner_admin capabilities reached through Partner Team, not from the Clients directory itself.

#Who Can Use It

RoleAccess
partner_adminView the assigned-client directory and per-client summaries, including billing and contact summaries.
partner_userView the assigned-client directory in read-only mode, with less contact and billing detail.

Both partner roles see the same directory; partner_user requests stay server-denied for any write regardless of what the UI renders. Customer roles and internal AiDial roles do not use the partner Clients page — the /clients route is restricted to partner roles and returns a generic not-found to any other role.

#The Clients Directory

The directory lists the clients in your confirmed partner scope as cards. Each card shows the client's customer-safe business name, a project count, and config-derived flags such as draft and open-support counts. The project count renders an honest state — a neutral "loading" placeholder until the operations source resolves, and an explicit "unavailable" state if that source fails or is degraded, never a false zero.

An in-page search box filters the already-loaded directory; it does not refetch or widen the roster. The directory never receives an unfiltered client roster — its entries come only from the server-resolved confirmed scope.

Choosing Filter & view on a card selects that client. Selecting a client:

  • applies the client filter to the partner surfaces, and
  • opens a bounded selected-client summary.

The selected-client summary shows the client's customer-safe business information, a project-derived health and project list, assigned partner staff (when a bounded source is available), and read-only billing and support flags. It also provides jump links into the client-filtered surfaces: Projects, Calls, Analytics, Alerts, Status & capacity, Support, and — for partner_admin only — Billing. Each jump carries the selected client_id in the URL only as a context hint; every destination still performs its own server-side client or project scope check, and the browser selection is rechecked server-side against your partner assignments.

The summary is a filter, not a workspace. There is no client-level configuration here: runtime configuration lives in the Projects workspace, reusable resources in Integrations, and compliance configuration in a project's Govern tab. Billing, contact, and engagement-note blocks render only for partner_admin; for partner_user those fields are omitted on the wire and the summary shows an "available to partner admins" placeholder instead of the values.

Partner access is assigned server-side. The Clients directory route does not accept browser-supplied client_id or tenant_id scope parameters — sending either is rejected — and client detail or downstream workflow routes deny out-of-assignment clients without revealing whether another tenant exists.

#Scoping Rules

  • Partner administrators see clients owned by their active partner organisation; partner users see only active client assignments.
  • The current request context must also permit the client, including backend visibility checks.
  • The directory list route rejects browser-supplied client_id and tenant_id scope parameters, and out-of-assignment client IDs are denied without revealing whether another tenant exists.
  • Partner users may see less contact and billing detail than partner administrators; restricted fields are omitted from the response, not just hidden in the UI.
  • Other partner surfaces, such as billing, projects, calls, capacity, settings summaries, and integrations, still apply their own client or project scope checks.
  • The browser uses the AiDial Portal session. Browser code must not send X-API-Key; the portal route handlers resolve the next-auth/Zitadel session and forward server-side bearer authentication to aidial_api.

#Provisioning A Client

Client provisioning is a partner_admin capability. It is reached through Partner Team, not from the Clients directory. A client profile is created with:

  • client ID
  • business name
  • web domain
  • contact name
  • business email
  • timezone

Provisioning is submitted through the portal BFF and forwarded to aidial_api with the signed-in user's server-side bearer session. The current backend creates a provisioning-stage client profile, active partner ownership for the caller's partner organisation, and an active assignment for the creating partner administrator. It does not automatically create customer users, customer passwords, runtime telephony numbers, billing configuration, production runtime wiring, or production assistant deployment. Those follow their own approved workflows.

partner_user cannot create clients.

If a client profile needs data import, runtime wiring, billing setup, DNS, phone-number registration, or a production cutover, use Escalation Boundaries.

#Assigning Partner Users

Assigning active same-organisation partner members to a client is a partner_admin capability, reached through Partner Team. The directory itself does not assign or remove users; its summary links to Partner team for assignment management.

When managing assignments, the assignment view lists currently assigned users and eligible users who can be added. At least one support contact must remain assigned: if removing a user would break that requirement, the portal rejects the removal. Removing your own client access requires an explicit confirmation before the request is sent.

Partner users see read-only client access and cannot assign or remove users.

#Not Self-Service

The partner Clients page does not replace AiDial operational workflows for:

  • customer user creation or password recovery
  • production call routing or phone-number provisioning
  • billing-plan activation
  • migration of historical call data
  • customer contract or legal entity changes
  • tenant deletion or restoration

Use Escalation Boundaries for those cases.