CFL - Data Privacy Controls

Operata processes your Contact Flow Logs entirely within your AWS account before any data reaches our platform.

• We provide a pre-built redaction layer that removes sensitive fields at source using a deterministic four-pass filter.
• You control which fields to allow, deny, encrypt, or transform via configuration.
• Operata maintains a mandatory list of fields required for system analysis, which takes precedence to ensure the platform continues to function.
• All filtering executes in a Lambda function provided by Operata in the CloudFormation template. The function runs in your AWS account and region, and you can audit the code.

❗️

Note: This is for IVR Flow (CFL) integration only.

Security Architecture: Data Never Leaves Unfiltered

All filtering executes in a Lambda function running in your AWS region, within your VPC boundary. Raw logs are streamed from CloudWatch to your Lambda, filtered according to your rules, then only the approved payload is transmitted to Operata. At no point does Operata receive data you've marked for Deny or Encryption.

How Data Privacy Controls work

Operata has a six-tier data redaction framework applied to the data Operata ingests - each JSON event goes through a deterministic, ordered filter pipeline.

The framework assigns every field in the event payload to exactly one of six tiers:

• A Mandatory tier is defined and maintained by Operata; it supersedes all others.
• Four customer-configurable tiers - Allow, Deny, Encrypt, and Transform these are mutually exclusive: a field may appear in only one.
• A Default tier deals with any fields that are not part of the other six tiers.

Processing Architecture

When the collector processes an event, it applies filtering in four passes:

Pass 1 - Mandatory Override Pass

• Check whether the marked field, or any of its descendants, appears in the mandatory list. If a mandatory field sits under a denied parent, retain the parent and prune all non-mandatory siblings. The mandatory list always takes precedence.

Pass 2 - Deny Pass

• Evaluate every field path against the deny list. Mark fields for removal.*

Pass 3 - Any remaining items

• The remaining filters (allow, encrypt, transform) execute

Pass 4 - Default Nullify Pass

• All remaining field values in the payload outside of the lists will be have the key retained, but the values nullified.

❗️

Currently only Mandatory tier filtering will be possible - listed below

Data Flow Diagram

CloudWatch
   ↓ (raw Contact Flow Log)
Lambda (in your account)
   ├─ Pass 1: Mandatory Override (Operata fields always included)
   ├─ Pass 2: Deny Pass (remove marked fields)
   ├─ Pass 3: Encrypt/Transform/Allow (apply rules)
   ├─ Pass 4: Default Nullify (blank anything unclassified)
   ↓ (filtered payload only)
Operata API

Path Notation

Both lists use dot-notation paths to identify fields.

• A top-level key such as Parameters matches the entire object at that key.
• A nested path such as Parameters.LexVersion matches only that specific subfield.

The processor applies rules at every depth level consistently, so deny-with-mandatory-preservation logic works the same at any nesting depth.

Parent Key Behaviour

When a deny list entry targets a parent key (for example, Parameters) and no mandatory list entry references any child of that parent, the processor removes the entire Parameters key. The result is not an empty object; the key is absent from the output entirely.

When a deny list entry targets a parent key and the mandatory/allow/encrypt/transform list references one or more children of that parent, the processor retains the parent containing only those mandatory children. Every other child is removed regardless of whether it also appears explicitly in the deny list.

Mandatory List for CFL

ContactFlowId
ContactFlowModuleType
ContactFlowName
ContactId
ErrorDetails
ErrorDetails.ErrorCode
ErrorDetails.Message
ExternalResults.error
ExternalResults.status
ExternalResults.statusCode
ExternalResults.statusMessage
Identifier
ModuleExecutionStack
Parameters.AudioPrompt
Parameters.BotAliasArn
Parameters.ContactFlowId
Parameters.FlowModuleId
Parameters.FunctionArn
Parameters.InvocationType
Parameters.LexVersion
Parameters.NoInputTimeout
Parameters.Parameter.x-amz-lex:*
Parameters.Queue
Parameters.ResponseValidation
Parameters.TextLexTimeoutSeconds
Parameters.TextToSpeechType
Parameters.Timeout
Parameters.TimeoutSeconds
Parameters.Type
Parameters.ViewResourceId
Timestamp

Example

//raw log
{
  "ContactFlowName": "CustomerService",
  "ContactId": "abc123",
  "Parameters": {
    "CustomerCardNumber": "4111-1111-1111-1111",
    "Queue": "billing",
    "TextInput": "I want to renew"
  }
}

// config - used and processed in Lambda

Deny: Parameters.CustomerCardNumber
Allow: Parameters.Queue
Encrypt: Parameters.TextInput

// Received by Operata afte
{
  "ContactFlowName": "CustomerService",
  "ContactId": "abc123",
  "Parameters": {
    "Queue": "billing",
    "TextInput": "8d3a2f9b2c1e..." (hashed)
  }
}

---------------------------------------------------------------------------------------------------

// Common Scenarios

"I don't want customer agent notes in Lex"
-> Deny: Parameters.AgentNotes

"I need to see queue names but not customer IDs"
-> Allow: Parameters.Queue, Deny: Parameters.CustomerId

"I want to hash customer phone inputs but keep flow analysis"
-> Encrypt: Parameters.PhoneDigitsEntered, Allow: Parameters.Queue, Parameters.FlowName