Implementing PDPA (Thailand) Consent Management for Southeast Asian Customer Interactions

How-To-Articles
1

Implementing PDPA (Thailand) Consent Management for Southeast Asian Customer Interactions

What This Guide Covers

This guide details the architectural implementation of Personal Data Protection Act (PDPA) compliant consent management within Genesys Cloud CX for customer interactions originating from Thailand. The end result is a system where consent status determines routing eligibility, recording capture, and data retention policies in real time. You will configure custom data models to track granular purpose-based consent and enforce suppression rules via Architect flows and API integrations.

Prerequisites, Roles & Licensing

To execute this implementation, the following baseline requirements must be met:

  • Licensing Tier: Genesys Cloud CX Premium or Enterprise license. The Privacy Management module requires specific entitlements for data subject rights workflows. WEM (Workforce Engagement) add-ons are required for real-time analytics on consent adherence.
  • Granular Permissions:
    • Conversation Data > Edit for custom field creation.
    • Privacy Management > Manage Consent to handle user opt-out requests via the admin portal.
    • API > Read/Write for external system synchronization.
    • Archiver > Configure to manage retention policies based on consent flags.
  • OAuth Scopes: org:read, conversationdata:write, privacy:manage.
  • External Dependencies: A centralized Consent Management Platform (CMP) or CRM is recommended for long-term storage of consent history outside the CCaaS ephemeral database. The CCaaS instance acts as the execution engine, not the primary ledger.

The Implementation Deep-Dive

1. Data Model Design and Storage Strategy

The first architectural decision concerns where consent data resides. Storing consent solely within the CCaaS interaction record is insufficient for PDPA compliance because interaction records are transient and subject to retention schedules that may expire before legal retention periods allow.

Architecture Decision:
Implement a dual-storage model. The primary source of truth for the active consent state must be an external system (e.g., Salesforce, SAP, or a dedicated CMP). Genesys Cloud CX will cache this status in Conversation Data custom fields to minimize latency during interaction routing.

Implementation Steps:

  1. Navigate to Admin > Data Management > Custom Fields.
  2. Create a new field set named PDPA_Compliance.
  3. Add the following string fields:
    • pdpa_consent_status (Enum: granted, revoked, pending)
    • pdpa_purpose_code (String: e.g., SERVICE, MARKETING, ANALYTICS)
    • pdpa_timestamp (DateTime)
  4. Set the scope to Interaction so the data persists for the duration of the call and is indexed in Archiver.

The Trap:
Do not rely on native CCaaS fields like “Customer Name” or “Account Number” to infer consent status. If you store a boolean flag directly on the Contact record without versioning, you cannot prove when that consent was granted if auditors request historical data from six months ago. PDPA requires an audit trail of when and for what purpose consent was given.

Architectural Reasoning:
By using Conversation Data custom fields, the consent state travels with the interaction regardless of the channel (Voice, Chat, Email). This ensures that if a customer starts on Webchat and transitions to Voice, the system checks the same consent context. The external source of truth ensures that revocation requests update instantly across all channels via API webhook triggers before the next session initializes.

2. Capture Mechanisms and Verification

Capturing consent requires a standardized approach across all touchpoints. PDPA mandates explicit, unambiguous action. Passive acceptance (e.g., pre-ticked boxes) is non-compliant.

Implementation Steps:

  1. IVR Configuration: In Architect, create a flow branch for new interactions. Before connecting to an agent, invoke the Consent Verification API.
  2. API Payload Construction: Use the Conversation Data API to update the interaction metadata upon consent capture.
POST https://api.mypurecloud.com/api/v2/conversations/interactions/{interactionId}/data
{
  "name": "pdpa_consent_status",
  "value": "granted",
  "type": "string"
}
  1. Webchat Integration: Embed a consent capture widget in the chat interface that requires manual user selection of purpose codes. This payload must be sent to the CCaaS API via the Chat API endpoint POST /api/v2/chats/{chatId}/data.
  2. Agent Screen Pop: When an interaction starts, query the external CMP using the customer ID (phone number or email). If the result is revoked or pending, trigger a specific routing decision immediately.

The Trap:
A common failure mode occurs when the API call to verify consent times out. If your Architect flow blocks the caller while waiting for an external system response, Average Handle Time (AHT) increases and customers may abandon the queue.

Mitigation Strategy:
Implement a circuit breaker pattern in Architect. Set the API step timeout to 500 milliseconds. If the timeout occurs, route the user to a generic “Service Representative” menu rather than a specialized marketing survey menu. Log this event as a warning in the interaction transcript for audit purposes.

Architectural Reasoning:
Latency in consent verification is critical. PDPA does not explicitly define response time limits, but customer experience standards dictate that compliance checks should not degrade service availability. By decoupling the capture of consent (external system) from the verification (CCaaS cache), you balance data integrity with performance. The CCaaS cache acts as a read-through cache; if the external system is down, the cached value (last known state) is used to maintain continuity, with a background job updating the status when connectivity resumes.

3. Enforcement Logic and Routing Controls

Once consent is captured and verified, the system must enforce restrictions on what data can be processed. This includes recording suppression and analytics exclusion.

Implementation Steps:

  1. Recording Suppression: In Architect, utilize the Conversation Data > Update step to set a flag indicating recording_allowed = false. Configure the CCaaS Archiver to respect this flag during the call session.
  2. Routing Logic: Create separate queues for “Marketing Calls” and “Service Calls”. Apply routing skills based on the pdpa_purpose_code.
{
    "name": "pdpa_recording_suppression",
    "value": true,
    "type": "boolean"
}
  1. Queue Configuration: In Admin > Routing, edit the specific queue settings. Enable the option to block interactions where recording_allowed is false. This ensures that if a user revokes consent for recording during an active session, the system can trigger a termination or mute protocol depending on legal requirements.

The Trap:
Organizations often configure recording suppression at the agent level rather than the interaction level. If an agent manually overrides the recording setting within their desktop interface, it creates a compliance violation that is difficult to detect post-call.

Mitigation Strategy:
Lock down the recording control in the desktop application via policy settings. Ensure agents cannot toggle recording on or off for interactions tagged with pdpa_purpose_code = SERVICE. This ensures that data processing aligns strictly with the captured consent state throughout the entire session lifecycle.

Architectural Reasoning:
Enforcement must happen at the point of data ingestion. If you allow recording to start and then attempt to delete it later, you risk partial data retention that violates the Right to Erasure. By setting the suppression flag before the media stream initializes, you prevent PII (Personally Identifiable Information) from entering the storage layer entirely. This minimizes the attack surface for data breaches and reduces the complexity of downstream deletion workflows.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Consent Revocation During Active Session

The Failure Condition: A customer grants consent at the start of a call but revokes it via a web portal five minutes later while still on the line with an agent. The system continues to record and log PII.
The Root Cause: Asynchronous state propagation. The CCaaS instance holds the cached consent state (granted) while the external system has updated to revoked. The gap between update and cache invalidation allows non-compliant processing.
The Solution: Implement a heartbeat mechanism. Configure the Architect flow to query the external consent status every 60 seconds for long-duration interactions. If the status changes to revoked, trigger an immediate action: stop recording, mute the microphone if possible, and route the agent to a compliance notification script. Update the interaction data field to reflect the revocation timestamp.

Edge Case 2: Right to be Forgotten (Erasure) Requests

The Failure Condition: A customer requests erasure under PDPA Article 35. The system deletes the conversation record but leaves metadata or analytics snapshots containing PII in archival buckets.
The Root Cause: Disconnected deletion policies between the Interaction Data store and the Archiver retention buckets. Deleting an interaction does not automatically purge all derived artifacts.
The Solution: Create a dedicated workflow for erasure requests using the Privacy Management API. The workflow must iterate through all associated data stores:

  1. Purge the active Conversation Record.
  2. Trigger a hard delete on the Archiver bucket for that specific Interaction ID.
  3. Remove PII from Speech Analytics transcripts and summaries.
  4. Update the external Consent Management Platform to log the erasure event with a timestamp.

Validation: Use the API endpoint GET /api/v2/privacy/requests/{requestId} to confirm completion. Do not rely on the UI status alone as background jobs may lag.

Edge Case 3: Cross-Channel State Synchronization

The Failure Condition: A customer grants marketing consent via Email but calls in regarding a billing issue. The agent sees no record of the marketing consent and attempts to discuss promotions, violating the “purpose limitation” principle of PDPA.
The Root Cause: Consent data is siloed by channel within the CCaaS instance. Marketing consent captured in Email does not automatically propagate to the Voice channel context.
The Solution: Normalize consent identifiers across all channels. Use a unique Customer ID (GUID) rather than channel-specific IDs (phone number vs email address). Configure the external CMP to aggregate consent flags by this GUID. When the phone call initiates, query the CMP using the normalized ID to retrieve the full consent posture, not just the voice-specific flag.

Official References