#PII Unlock Requests
| Role | Access Level |
|---|---|
| Client Admin | Server-side permission for call-scoped unlock requests; current client UI does not expose the request form |
| Client Manager | Server-side permission for call-scoped unlock requests; current client UI does not expose the request form |
| Client Staff | No PII unlock access |
#Overview
The current Calls experience uses inline review from the Call Log. Legacy /calls/<callId> links permanently redirect to /calls?expand=<callId> (preserving project_id when present), and the current inline review panel does not mount the PII unlock request form, consent evidence panel, or call-scoped sensitive access audit table. The unlock form component still exists in the codebase, but no portal page renders it.
The portal still has a guarded server-side PII unlock route for call-scoped requests, but there is no supported customer-facing browser path for submitting one in the current UI. There is also no separate Compliance > PII Unlock page and no tenant-wide unlock request queue.
#Prerequisites
- You are signed in as a Client Admin or Client Manager for any unlock-capable server-side route.
- Your session has a valid project scope. Unlock requests fail closed when the session has no project scope.
- The call must belong to your tenant and assigned project scope. Scope is resolved server-side from the signed-in session and bearer token, not from browser-supplied project IDs.
- The call must have Valid consent evidence. Sensitive access is blocked when consent is missing or invalid.
- You must have a clear business justification for accessing the requested information.
#Submitting a PII Unlock Request
There is no supported in-browser PII unlock submission path in the current Calls UI.
- Open the required call from the Call Log by expanding the inline review panel.
- Review the role-appropriate transcript preview and metadata that are available in the inline panel.
- If sensitive access is required for a regulatory or operational reason, use your organisation's escalation process or contact your partner representative. Do not attempt to bypass the portal with an API key.
The implemented portal BFF route is POST /api/calls/[callId]/pii-unlock-requests. It is not linked from the current client UI. When a portal surface invokes it, the route:
- enforces CSRF protection on the mutating request;
- resolves the signed-in
next-authsession and forwards the server-side bearer token toaidial_api; - allows only Client Admin and Client Manager roles;
- requires a project-scoped session, and returns
401when the session has no project scope; - rate-limits unlock attempts to 10 per 15 minutes for the same user, call, and source IP;
- requires
artifact_scope,reason_code, and a non-emptyjustification; - requires
supplemental_reasonwhenreason_codeisother.
The portal route does not enforce consent or auditing itself; it forwards the validated request to aidial_api, which:
- re-checks consent evidence and rejects the request with
400when consent is not Valid; - applies its own limit of 10 requests per 15 minutes per actor and call, returning
429when exceeded; - emits sensitive-access audit events for requested, granted, and denied outcomes.
Current server-side artefact scopes are Transcript, Call Summary, Recording, Extracted Entities, and All Artifacts. The reason code taxonomy is Quality Assurance, Customer Complaint, Legal Request, Compliance Audit, and Other, but aidial_api also checks the submitted reason code against the active PII unlock policy, which AiDial administrators maintain and which can allow a narrower set.
The browser must use the signed-in portal session. It does not need to enter or send an API key, and browser requests must not send X-API-Key.
#Viewing the Result and Audit Trail
Because the PII unlock form is not mounted in the current client UI, there is no call-page result panel for customers to review after submission.
If the guarded route is invoked by an authorised portal surface, a successful request returns 201 with status approved. There is no human approval step and no pending queue: when the request passes scope, consent, rate-limit, and policy checks, aidial_api records the request and the grant together and returns the decision immediately. The response carries the unlock request reference, call, project, artefact scope, reason code, and the requested/decided timestamps. It does not return an expiry value — the grant duration comes from the active PII unlock policy and is recorded in the audit event, not sent back to the portal.
Failures are returned as errors rather than as a denied result body. Invalid consent and invalid input return 400, an exceeded rate limit returns 429, and a call outside your tenant or project scope returns 404.
Sensitive-access events are visible through the Activity Log when your role can view audit activity and the events are present in the audit stream. The Activity Log is loaded through portal BFF routes using your signed-in session; it does not require an API key.
Note: PII unlock requests are sensitive actions. The unlock flow audits successful and denied attempts in
aidial_api, including the call, project, artefact scope, purpose, justification text, unlock request reference, source IP, and supplemental reason when provided. Granted requests also record the policy snapshot and the grant expiry; denied requests record why they were denied.
#Common Issues
- I cannot see PII unlock controls. This is expected in the current Calls UI. The inline review panel does not mount the unlock request form, and Client Staff users have no PII unlock access.
- The old call detail link does not open a PII unlock panel. Legacy
/calls/<callId>links redirect to the Call Log inline review URL. - The request is blocked because consent is missing or invalid. The guarded server-side route blocks sensitive access until the call has valid consent evidence.
- The form asks for another reason. If an unlock-capable portal surface sends
reason_code=other, it must also provide a supplemental reason. - My request was denied or failed. The request may be outside your tenant or project scope, may be missing required justification, may have been rate-limited, may lack valid consent, or may use a reason code the active PII unlock policy does not allow.
- I need to unlock PII urgently. Contact your partner representative if an urgent regulatory obligation requires escalation.