#Clients

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, Calls, Analytics, Alerts, Status, Support, and Billing for partner_admin) and opens a bounded summary. The directory carries no provisioning or assignment controls of its own; for partner_admin it links to Partner Team, where assigned clients are shown read-only.

#Who Can Use It

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 (shown only when non-zero). 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. For partner_admin the directory also shows a Manage assignments link to Partner team.

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, an assigned partner staff block, and read-only billing and support flags. The staff block is empty today: no bounded partner-safe staff source is wired to it yet, so it says assigned staff will appear once one is available rather than listing names. 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. The per-client detail route never returns the client's business email to any role, and returns the contact name only to partner_admin.
• 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 portal session and forward server-side bearer authentication to aidial_api.

#Provisioning A Client

There is no partner-facing screen for creating a client profile. The Clients directory carries no provisioning control, and Partner team manages members and shows assigned clients read-only — it does not create clients.

The provisioning route itself is implemented and partner_admin-only: the portal BFF exposes POST /api/partner-clients and forwards it to aidial_api with the signed-in user's server-side bearer session. A client profile is created from:

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

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 — the route is denied server-side for that role.

To have a client profile created, or if an existing profile needs data import, runtime wiring, billing setup, DNS, phone-number registration, or a production cutover, use Escalation Boundaries.

#Assigning Partner Users

Partner-user client assignments are visible in the portal but not editable there. Partner Team lists your own assigned clients, and for partner_admin it also lists each member's assigned clients. The Clients summary points at Partner team for assignment management, but neither surface currently offers an assign or remove control.

The assignment routes are implemented and partner_admin-only: GET/POST /api/partner-clients/{client_id}/users, GET /api/partner-clients/{client_id}/assignable-users, and DELETE /api/partner-clients/{client_id}/users/{user_id}. At least one support contact must remain assigned — the backend rejects a removal that would leave a client with no assigned partner user and returns a conflict instead.

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

To change who supports a client, use Escalation Boundaries.

#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.

#Related Pages

• Partner Team
• Projects
• API Keys & Partner API
• Tenant Scoping
• Roles & Permissions