Skip to main content
Operata redacts at the edge of your AWS account, before contact data leaves for Operata, using a single allow-list or deny-list configuration that you control through the API.

​
How it works

Redaction runs inside the Cloud Collector, in your AWS account, on the path between Amazon Connect and Operata. The Cloud Collector reads Contact Trace Records (CTRs) from Kinesis, applies the active redaction config, and ships only the fields that survive the filter. Operata never sees the dropped fields — they are removed before the request crosses the AWS boundary. The redaction config is a single JSON document stored against your Operata account. There is one config per account. It is one of two shapes, distinguished by value.type:
  • WHITELIST — allow-list. The Cloud Collector ships only the mandatory CTR fields plus the fields you name.
  • BLACKLIST — deny-list. The Cloud Collector ships every CTR field except the ones you name.
A small set of mandatory CTR fields — for example ContactId, InitiationTimestamp, Queue.Name — ships regardless of the config. A deny-list cannot remove them; an allow-list cannot omit them. They are the minimum Operata needs to attribute a record to a Contact and place it on a timeline. When no config exists, the Cloud Collector applies the privacy-first default and ships only the mandatory fields. Reading the config endpoint in that state returns 404. The default is restrictive on purpose: a misconfigured or unconfigured account leaks nothing past the mandatory minimum. The Cloud Collector caches the active config and refreshes it from the Operata API on a 30-minute interval. When you change the config through the API, the new policy takes effect on the next refresh — there is a propagation window of up to 30 minutes during which contacts in flight ship under the previous policy. If a refresh fails, the Cloud Collector falls back to the mandatory minimum until it can reach Operata again.

​
Why redaction runs at the edge

Running the filter inside your AWS account, before the record crosses the boundary, is the only way to give you a hard guarantee about what Operata receives. A server-side filter would still require Operata to read every field before dropping it; an edge filter does not. The trade-off is that the Cloud Collector has to run in your account, with the IAM surface that implies — see Cloud Collector for the components, and IAM Role and Policies for the role and policy contract. The single-config-per-account rule simplifies the propagation contract. Multiple configs would force the Cloud Collector to evaluate which one applies per record, which adds latency and a class of misconfiguration bugs. One config means one cached document and one refresh interval to reason about. The 30-minute propagation window is the shared-responsibility line. You own the config; Operata propagates it. Until the window closes, contacts in flight can still ship fields the old config allowed. For changes that must take effect immediately, stop the EventBridge pipe, update the config, wait for a refresh, then restart — this is documented in Configure CTR redaction.