#Partner Team
The Partner Team page is for provisioned partner organisations to manage partner users and see which clients each partner user can support.
#Who Can Use It
| Role | Access |
|---|---|
partner_admin | View members and the organisation's client list, open any member's detail page, view pending invitations, invite partner_user members, revoke pending invitations, change another member between partner_admin and partner_user, remove other members, and preview another member's client access. |
partner_user | View the partner team and their own assigned clients in read-only mode, and open their own member detail page. |
Customer roles and internal AiDial roles do not use this partner-team surface. For those roles, /partner-team and every /api/partner-team/** route answer with a non-enumerating not-found response.
The page depends on an active partner organisation membership. If AiDial has not completed partner bootstrap for your organisation, team roster and assigned-client requests may be denied and the page may show an unable-to-load state. Contact AiDial support rather than trying to self-correct partner organisation setup.
Partner administration is a mandatory multi-factor role. A partner_admin session that has not completed MFA enrolment and challenge cannot read or change partner-team data.
#What Partner Admins Can Do
Partner administrators can:
- review the member list with name, email, role, privacy-limited security posture, and a coarse activity indicator when sign-in telemetry is available
- search, sort, and paginate the member list at 10, 25, or 50 rows per page
- open a member's detail page from their name to see that member's email, role, and assigned clients
- invite new
partner_usermembers by email address; the page does not createpartner_admininvitations - review pending invitations with the invited email, assigned role, inviter, send date, and expiry date
- revoke pending invitations
- change another member between
partner_adminandpartner_user - remove another member from the partner organisation
- preview another member's assigned-client list; this preview is render-only and never issues a token or session on that member's behalf
The Assigned Clients section shows the clients visible to your partner organisation, plus a per-member breakdown you expand one member at a time to see that member's own assignments.
Invitations always assign the partner_user role. To create a second administrator, invite the person as a partner user, then change their role once they have joined.
An invited person receives an email containing a link back to the portal. Opening that link prompts an identity-provider sign-in, and membership is created only after they sign in with the invited email address. Invitations expire seven days after they are sent. If an invitation or membership already exists for that email address, the new invitation is refused.
Role change and removal are refused server-side when the action would leave the organisation without a partner administrator.
The portal shows the signed-in member's MFA/security status when available; peer rows show a managed placeholder instead. Peer MFA and peer activity values are removed before roster data reaches the browser, so the activity column reflects only your own row, and it reports a coarse recent or not-recent indicator rather than an exact timestamp.
The portal does not allow a partner administrator to change or remove their own membership from the team table. Self role-change and self-removal attempts are rejected server-side and recorded as denied.
#What Partner Users Can Do
Partner users can view the team roster, view the clients assigned to their own account, and open their own member detail page. They cannot view pending invitations, or perform invitation, role-change, removal, or cross-member assignment actions. Selecting another member's name, or any other request for another member's data, returns a non-enumerating not-found result.
#Security And Scope
Partner Team actions are scoped to your partner organisation, not to a browser-supplied client ID. On every request the portal resolves your partner organisation, membership status, organisation status, and current role server-side, then checks your session, role, and the requested action before it performs protected work.
The browser calls portal BFF routes under /api/partner-team/**; those route handlers resolve the portal session and forward the AiDial-issued access token to aidial_api. Do not send X-API-Key from the browser for partner-team actions.
Reads and mutations are both audit logged, and mutating partner-team actions additionally require portal request verification. Partner-team audit events include invitation sent, invitation revoked, role-change, and member-removal activity. Denied attempts, such as a self-action or an action blocked by the last-administrator rule, are recorded alongside successful ones.
If your partner organisation is suspended or archived, the whole Partner Team surface is blocked, roster reads as well as management actions, until AiDial support resolves the organisation status.
Client assignment itself is not performed on this page. New members start with no client access until an administrator assigns clients separately.
#Unsupported Actions
Use Escalation Boundaries instead of attempting self-service for:
- recovering the last remaining partner administrator
- changing organisation-level partner status
- fixing a suspected cross-organisation assignment issue
- restoring a removed member when the normal invitation flow is not enough
- investigating audit events outside your partner organisation
Do not share passwords, API keys, screenshots containing secrets, or customer PII in support requests.