Customer Profiles and Verified Context

Updated 9 September 2026

Staff Workflow

1. Open a ticket assigned to you → Customer Profile in the command bar (Ticket Actions on a phone).
2. Choose Create Profile, or find and preview an existing profile → Link This Case.
3. Record the identity check, tick the confirmation and confirm the link. A matching name is not evidence.
4. Add Contact Preference, Service Reference or Service Requirements, with source evidence. New and edited facts are Unverified.
5. Use Verify Fact only after checking it; record what you checked. Mark Unverified withdraws an outdated verification.
6. Use Unlink Case with a reason to correct a mistaken association. The profile, audit trail and original conversations remain available.

Boundaries

All enabled employees in the existing support pool can read profiles. Only the current owner of an active linked case can change its profile facts or link. Supervisors must recover ownership first. No new directory permissions or infrastructure are required.

Verification is a recorded staff assertion with evidence, actor and time; it is not automated identity proof or messaging consent. Contact preferences never change the case's reply destination, provider window or sending permissions. Profile names can be corrected with Rename Profile and a reason.

Each fact retains its source case and author. Profile History preserves prior values and verification evidence. Removed facts leave the current view but remain in history. Unlinking is not erasure or an access revocation: the same authorized support pool can still find the profile and inspect its audit history.

One profile may explicitly link several cases; each case has at most one current profile. Linking never merges messages, owners or channel identities. No automatic matching, CRM import or AI extraction is included. Search returns up to 30 matching names/profile IDs; narrow the search if needed. History displays the latest 30 events while the database retains all events.

Before real customer traffic, agree identity checks, permitted facts, access boundaries and retention/deletion requirements with the client. Use fictional data for the technical pilot. Profile content is not copied into Teams cards or customer messages; generic profile action labels appear in case activity.

Engineering

Additive SQLite tables store profiles, case links, immutable event snapshots and payload-bound request results. All profile routes inherit Inbox SSO and actor checks. Actions require both the current case version and profile version. Retries with the same request ID and payload return the original result; changed retries or stale edits are rejected. No provider send job is created by a profile action.