Before you start
- The Amazon Lex integration stack deployed against your Amazon Connect instance.
- An Operata API token with admin permissions. See Authentication.
- The list of Amazon Lex field paths you want to allow, deny, encrypt, or transform. The schema and the mandatory keep-list live in Lex redaction schema.
Steps
1. Draft your rules
Path notation is dot-delimited against the Lex V2 conversation log JSON payload. Rules apply at every depth. A wildcard segment such asinterpretations.intent.slots.*.shape matches every slot name.
Common drafts:
sessionId, bot, interpretations.intent.name, and the x-amz-lex:* session attributes — see Lex redaction schema for the full list.
2. Send the policy to Operata Support
The customer-facing API for Lex redaction policies is not yet public. Send your drafted ruleset to Operata Support with the Operata Group ID you want it applied to. Operata installs the policy against your Lambda and confirms when it is live.3. Wait for the Lambda to pick up the new policy
The redaction Lambda reads the active policy on each invocation. Allow up to a minute for in-flight events to drain under the previous policy. The new policy has no effect on events the Lambda already collected — redaction runs at ingest time, not retroactively.Result
Place a test contact that routes through your Lex bot, then read the matching contact back through the Operata API. Denied slot or transcript fields drop from the response, the mandatory keep-list survives, and every other field’s value isnull until Allow, Encrypt, and Transform reach end-to-end enforcement.
Related
- Lex redaction schema — field tiers, mandatory keep-list, and processing order.
- Privacy and redaction — the cross-integration model.
- Configure Contact Flow Log redaction — the sibling rollout for Contact Flow Log data.