Data Masking Configuration Impact on Queue Performance Metrics

Quick question about the interaction between Genesys Cloud’s data masking policies and the calculation of metrics within the Performance Dashboard.

Our organization recently enforced strict GDPR compliance measures, activating field-level data masking for Personally Identifiable Information (PII) across all Architect flows and recording transcriptions. While the security team confirms that the masking rules are applied correctly at the source, we are noticing a discrepancy in how certain performance indicators are rendered in the Queue Activity view.

Specifically, the “Average Handle Time” (AHT) metric appears to be calculating correctly for calls that do not involve sensitive data entry. However, for interactions where PII fields are populated and subsequently masked, the AHT seems to include a significant portion of the post-call work (PCW) time that should theoretically be excluded based on our current flow routing logic. The discrepancy is approximately 15-20 seconds per interaction.

The environment is configured with the latest Architect version, and the masking policy is set to “Redact on Transcription” and “Mask in UI”. We have verified that the data actions writing to the contact attributes are not throwing errors, and the conversation detail views show the masked values as expected. Yet, when aggregating this data into the Performance Dashboard, the metric definitions do not seem to account for the processing latency introduced by the masking engine during the transcription analysis phase.

Is this a known limitation of the current metric calculation engine? We require accurate AHT data for our service level agreements (SLAs) and workforce management forecasting. If the masking process inherently adds latency that is captured in the handle time, we need to understand if there is a way to exclude this processing time from the AHT calculation or if we should adjust our SLA targets accordingly.

Any insights into the technical behavior of metric aggregation post-masking would be appreciated.

The easiest fix here is this is…

"masking_config": {
 "apply_to_metrics": false,
 "preserve_analytics_tokens": true
}

Data masking strips tokens needed for queue calculations. Disable masking on analytics fields to restore metric accuracy without compromising PII compliance.