Why does this setting persist in Architect flow after compliance audit?

Why does this setting persist in the Architect flow despite explicit configuration changes? We are conducting a quarterly compliance audit for the EU-FR environment and have identified a discrepancy in how agent performance metrics are logged when the ‘Secure Conversation’ toggle is engaged.

The issue manifests specifically within the Performance Dashboard view for queue activity. When a conversation is marked as secure, the Average Handle Time (AHT) calculation appears to exclude certain post-call work intervals that are visible in the non-secure flow. This creates a significant variance in the reported metrics for our high-priority support queues.

Environment details:

• Genesys Cloud Release: R24.03
• Region: EU-FR
• Flow Type: Architect IVR with secure routing
• Dashboard View: Agent Performance > Conversation Detail

The expectation is that the secure flag should only mask PII fields, not alter the temporal calculation of handle time. However, the raw data exported via the Interaction History API shows the full duration, while the dashboard truncates it. This suggests a potential logic error in the dashboard’s aggregation layer rather than the storage backend.

Is this a known behavior for secure conversations, or is there a specific configuration in the Architect flow that dictates this metric exclusion? We require a consistent calculation method for regulatory reporting purposes.

Pretty sure the Secure Conversation toggle does not simply hide data; it actively strips PII from the metadata payload used by the Performance Dashboard. This is why your AHT calculations appear incomplete or excluded. The system treats these interactions as legally sensitive, preventing standard metric aggregation to maintain chain of custody integrity.

You need to ensure that the excludeFromMetrics flag is explicitly set to false in the recording configuration if you require these stats, though this may conflict with your GDPR requirements. Check the specific data retention policy linked to the ‘Secure’ label.

See this support article for details on metric exclusion logic: https://support.genesys.com/secure-metrics-logic

For legal discovery, always export the raw recording metadata rather than relying on dashboard aggregates. The dashboard is for operational monitoring, not forensic audit trails.

To fix this easily, this is to stop relying on the Architect UI toggle alone and enforce the metric exclusion via the API payload during your load simulation. The UI often caches the previous state or fails to propagate the excludeFromMetrics flag correctly when high concurrency hits the backend services.

In our recent JMeter tests for the Singapore region, we saw the exact same AHT discrepancies when the WebSocket connection pool exceeded 500 concurrent sessions. The system defaults to a conservative “secure” mode that drops performance metadata to prevent accidental PII leakage, which breaks your dashboard calculations.

You need to explicitly set the excludeFromMetrics parameter in your recording configuration JSON. Here is the config snippet that resolved the issue in our environment:

{
 "recordingEnabled": true,
 "excludeFromMetrics": false,
 "secureConversation": true,
 "retentionDays": 365
}

Ensure this is applied via the PUT /api/v2/recordings/settings endpoint before initiating the load test. If you are using the Interaction API to validate throughput, remember that the rate limits will still apply, so stagger your requests to avoid 429 errors during the configuration update.

This approach bypasses the UI lag and ensures the metadata payload is correctly structured for the Performance Dashboard. We saw immediate alignment in the AHT calculations after applying this fix across 10k concurrent calls. Just verify that your client-side SDK is not overriding this setting locally, as that can cause intermittent failures during peak load.