Architect Flow Audit Logs Missing Sensitive Data Masking Indicators

Administration
1

Anyone free to help troubleshoot this discrepancy in our compliance reporting. We have configured specific data masking rules within Architect to redact PII before storage, specifically targeting custom attributes populated via Data Actions. While the recordings and transcript exports correctly show masked values, the Conversation Detail View in the Performance dashboard continues to display raw, unmasked data for agents with the view:conversation:detail permission.

The environment is EU1, running the latest public release. The masking configuration is set to always for the targeted attributes. We expected the dashboard to respect these masking rules uniformly across all interfaces to satisfy GDPR requirements. Instead, it appears the masking is only applied at the storage layer for transcripts, not for the real-time or near-real-time metrics exposed in the performance views.

Here is the relevant configuration snippet from the flow:

{
 "attribute": "customer_ssn",
 "masking": {
 "type": "partial",
 "visible_chars": 4,
 "position": "end"
 }
}

Is this a known limitation of the Performance dashboard, or is there a separate permission set required to enforce masking visibility in the agent performance metrics? We need to ensure no PII is visible to supervisors during routine queue activity reviews.

2

If I remember correctly, this discrepancy often stems from how the platform caches conversation metadata versus how it renders real-time adherence data. The Performance dashboard pulls from a different index than the transcript export service.

While the recordings and transcript exports correctly show masked values, the Conversation Detail View in the Performance dashboard continues to display raw, unmasked data for agents with the view:conversation:detail permission.

Try checking if your WFM schedule adherence settings are overriding the masking rules. When agents are marked as “Available” but not taking calls, the platform might bypass certain compliance filters to maintain routing efficiency. Also, verify that the wfm:schedule:adherence:view permission isn’t conflicting with your data masking policies. Sometimes, aligning the schedule adherence data with the masking rules in the Architect flow helps. If that fails, consider adding a custom attribute to explicitly flag masked data for the dashboard view. This usually forces the UI to respect the redaction rules.

3

This looks like a synchronization lag between the real-time event bus and the historical analytics warehouse. The suggestion above regarding separate indexing is technically accurate, but the root cause often lies in the specific data flow for Architect masking rules. These rules are applied at the ingestion level for recordings, yet the Performance dashboard queries the conversation entity directly from the operational database before the final archival masking process completes.

To verify this, check the masking_enabled flag in your Architect flow configuration. Ensure it is set to true for both recordings and transcripts. Do not rely solely on the transcript export for compliance audits if the dashboard view is inconsistent.

A common workaround is to force a refresh of the conversation cache by updating a non-sensitive custom attribute on the interaction. Alternatively, query the Conversation API endpoint directly using the view:conversation:detail permission. The raw JSON response often reflects the masked state more accurately than the UI widget, which may be caching older, unmasked metadata from the initial SIP session establishment.