What’s the best way to reconcile the execution time reported in the Architect Flow Performance dashboard against the actual latency observed when invoking a Data Action via the Engage API? The organization operates within the EU-West BYOC environment. A specific Architect flow, designated ‘Customer_Lookup_Integration’, utilizes a Data Action to query an external CRM system. The flow logic includes a timeout setting of 5000ms for this specific integration step. Recent performance reviews indicate that the ‘Average Handle Time’ metric in the Flow Performance view consistently reports a duration of approximately 4500ms for this block. However, when analyzing the raw interaction logs and cross-referencing with the external CRM’s response timestamps, the actual network round-trip time varies significantly, often exceeding the configured timeout threshold before the flow transitions to the ‘Error’ branch. The Conversation Detail view shows the status as ‘Timeout’, yet the aggregate metrics in the Performance dashboard do not reflect this variance accurately, suggesting a potential discrepancy in how partial executions or failed timeouts are weighted in the average calculation. The environment configuration includes a custom SIP trunk setup for voice routing, but this issue is isolated to the web chat channel utilizing the Data Action integration. The expectation is that the dashboard metrics should align with the granular data available in the conversation logs. There is a concern that the current metric aggregation method may be excluding timeout events from the average handle time calculation, thereby skewing the performance indicators for stakeholders reviewing the operational efficiency reports. Detailed logs show the Data Action invocation timestamp and the subsequent timeout event, but the dashboard lacks a filter to isolate these specific failure modes for accurate trend analysis. This misalignment complicates the process of identifying true integration bottlenecks versus transient network issues. The request is for clarification on the metric calculation logic for Data Action blocks when timeouts occur, and whether there is a recommended method to ensure the dashboard reflects the actual operational latency experienced by end-users during these failed transactions.