Stuck on a problem and need help troubleshooting a discrepancy between our configured Data Retention policies and the actual data persistence observed in the Architect flow execution logs. We are operating under strict GDPR compliance requirements, which mandate that specific Personally Identifiable Information (PII) fields be purged from call recordings and transcript data within 24 hours of interaction completion. However, the dashboard reports indicate that certain custom attributes defined in our Architect flows remain visible in the ‘Conversation Detail’ view for up to 30 days, despite the retention policy being set to ‘Delete’ after one day.
The environment details are as follows:
- Genesys Cloud Region: eu-west-1 (Frankfurt)
- Architect Flow Version: 4.2 (Published)
- Data Retention Policy: ‘GDPR_PII_Strict’ applied to the specific queue group
- Custom Attribute Type: System-defined ‘Customer_Segment’ and custom ‘Compliance_Flag’
- Dashboard View: Agent Performance and Queue Activity
The issue appears to be isolated to the custom attributes that are written to the interaction object during the flow execution via the ‘Set Custom Attribute’ action. When reviewing the API response for GET /api/v2/interactions/{id}, the PII fields are correctly masked or removed after the 24-hour window. However, the internal Architect logs, which are accessible via the Performance dashboard for quality assurance audits, still display the raw values. This creates a compliance risk, as our auditors require proof that no PII is stored beyond the mandated period, even in diagnostic logs.
We have verified that the ‘Data Loss Prevention’ settings are enabled for the relevant queues. The question is whether the Architect flow execution logs are considered part of the ‘conversation data’ subject to retention policies, or if they are treated as system metadata exempt from these rules. If they are exempt, is there a recommended workaround to ensure these logs do not retain PII, perhaps by avoiding the logging of sensitive attributes altogether? Any clarification on how the retention engine processes Architect-specific logging versus standard call recordings would be appreciated.