#PII Unlock Requests

4 min read
RoleAccess Level
Client AdminServer-side permission for call-scoped unlock requests; current client UI does not expose the request form
Client ManagerServer-side permission for call-scoped unlock requests; current client UI does not expose the request form
Client StaffNo PII unlock access

#Overview

The current Calls experience uses inline review from the Call Log. Legacy /calls/<callId> links redirect to /calls?expand=<callId>, 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 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.

  1. Open the required call from the Call Log by expanding the inline review panel.
  2. Review the role-appropriate transcript preview and metadata that are available in the inline panel.
  3. 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:

  • resolves the signed-in next-auth session and forwards the server-side bearer token to aidial_api;
  • allows only Client Admin and Client Manager roles;
  • requires a project-scoped session;
  • requires artifact_scope, reason_code, and a non-empty justification;
  • requires supplemental_reason when reason_code is other;
  • re-checks consent evidence and rejects non-Valid consent before forwarding the unlock request;
  • rate-limits repeated unlock attempts for the same user, call, and source IP;
  • 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. Current reason codes are Quality Assurance, Customer Complaint, Legal Request, Compliance Audit, and Other.

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, AiDial can return unlock request status values such as requested, approved, denied, expired, or revoked, along with the selected scope and any expiry value available to the portal.

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 portal route audits successful and denied unlock attempts, including the call, project, artefact scope, purpose, justification text, supplemental reason when provided, and request reference when available.

#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 project scope, may be missing required justification, may have been rate-limited, may lack valid consent, or may not meet policy.
  • I need to unlock PII urgently. Contact your partner representative if an urgent regulatory obligation requires escalation.