Skip to main content
Personally identifiable information (PII) in Operata is any field on a contact record that can identify a real person — phone numbers, agent names, custom attributes carrying customer data — and you decide which of those fields leave your environment by configuring redaction at the edge of your AWS account.

​
How it works

The data Operata ingests carries PII in three places:
  • Contact metadata — customer phone numbers, queue names, custom attributes set by your flows, and any other field on the Amazon Connect Contact Trace Record (CTR) or the Genesys Cloud / NICE CXOne equivalents.
  • Agent context — agent usernames, machine identifiers, and any account-level attributes you map to agents.
  • Conversational content — Contact Lens transcripts and sentiment fields, Amazon Lex slot values, and contact-flow log entries.
Operata does not see any of these fields until they leave your environment. Redaction runs at the edge of your AWS account through the Cloud Collector, so the fields you redact never reach Operata in the first place. There is no Operata-side “delete PII” step — if a field is in the payload Operata received, the field is stored. The redaction model is allow-list or deny-list per field path. You configure it through the redaction API and apply it to one or more sources: CTRs, Contact Lens, contact-flow logs, and Lex events.

​
Why redaction runs at the edge

Redacting at the edge means your AWS account remains the boundary of PII control. Operata cannot accidentally store fields it never received, audits are simpler (the redaction config is the single source of truth for what crosses the boundary), and the contract is reversible — change the config, and the next CTR honors the new rules. The allow-list and deny-list shape is deliberate: a deny-list is easy to start with (“don’t send me phone numbers”), an allow-list is the safer default for high-regulation tenants (“send only the fields I name”). Both compile to the same execution.