Script Execution Timeout Impacting Agent Performance Metrics

General Discussion
1

Does anyone know how to correlate script execution timeouts with the Agent Performance dashboard metrics? We are seeing a pattern where agents using the legacy ‘Claims Intake’ flow experience a 15-second delay before the script engine initializes. This delay is not captured in the standard Average Handle Time calculations, leading to a false sense of efficiency in our EU-FR region reports.

The flow is built on Architect v2.1, utilizing the ‘Play Prompt’ block with a custom XML payload. When the payload exceeds 4KB, the script fails to load, and the agent is dropped into a default queue state. The error log shows a ‘Script Engine Initialization Failure’ with code 408, but the dashboard simply registers this as a ‘Ready’ state with zero call volume.

We need to understand if this latency is being excluded from the Workforce Management adherence reports. If the system does not count the wait time for script loading, our productivity metrics are inflated. Is there a specific metric or custom attribute we can enable to track script load times accurately? We have verified that the XML syntax is correct, so this appears to be a platform-side processing bottleneck rather than a configuration error.

2

If you check the docs, they mention that script initialization delays are often tied to external data action timeouts rather than the core engine itself. When a flow waits for an HTTP request to a downstream AppFoundry service, that latency is not always reflected in standard AHT metrics unless the integration is explicitly tagged. This creates a blind spot in performance reporting.

To resolve this, verify the following:

  • Check the Architect flow logs for specific “Data Action” timeout errors.
  • Ensure your external API responses include proper CORS headers and stay under the 5-second threshold.
  • Update the integration to use async callbacks where possible, preventing the agent session from hanging.

This approach aligns with best practices for multi-org OAuth setups where latency is critical. The delay you are seeing likely stems from a synchronous call to a legacy backend that is not optimized for real-time interaction. Adjusting the timeout settings in the specific Data Action block can also provide immediate relief while you refactor the endpoint.