What is the reason the transfer block in the flow below results in zero-handle time for the receiving agent in the Performance dashboard? The conversation appears as ‘completed’ but lacks agent interaction metrics. This breaks our SLA calculations for the EU-West instance.
transfer:
type: queue
queue_id: "sales_tier_2"
preserve_context: true
wrap_up_time: 0
The flow is stable, yet the dashboard metrics remain inconsistent. Any insights on the expected behavior?
The best way to fix this is to adjust the wrap-up configuration. Setting wrap_up_time: 0 in the transfer block often causes the system to skip the post-interaction handling phase for the receiving agent. This results in the conversation being marked as completed immediately without logging handle time.
In load testing scenarios with JMeter, we see this behavior frequently when simulating high-volume transfers. The API accepts the transfer, but the performance engine does not register the agent’s active time because the session closes too abruptly. Try changing the wrap-up time to a minimum of 30 seconds. This forces the platform to record the interaction duration properly.
Also, verify that the receiving queue has the correct routing rules. If the queue is empty, the transfer might fail silently or bounce, leading to orphaned records. Check the flow trace in the Architect to ensure the transfer block actually connects to the agent.
Take a look at at the JMeter response payloads during the transfer event to verify if the wrap_up_time: 0 is actually causing the immediate closure or if it’s a race condition in the Performance API aggregation. When running load tests with high concurrency, I’ve noticed that setting zero wrap-up time can sometimes lead to the system dropping the handle-time metric if the next action isn’t explicitly logged. Try adding a small delay or a dummy action block after the transfer to ensure the conversation state persists long enough for the metrics engine to capture it.
Here’s a quick JMeter config tweak to help isolate the issue: use a Constant Throughput Timer set to 10 req/min on the transfer endpoint. This slows down the request rate, allowing you to monitor the real-time queue occupancy and agent state changes without overwhelming the API. If the zero handle time persists even at low throughput, it’s likely a flow configuration issue rather than a load-related bug. Also, check if preserve_context: true is interfering with the metric handoff between queues. Sometimes disabling it temporarily helps clarify whether the context transfer is masking the interaction data.
You need to verify the preserve_context flag isn’t stripping the interaction metadata required for performance aggregation.
From an AppFoundry integration perspective, we often see this when custom attributes aren’t mapped correctly across the transfer boundary. Check the conversation history API payload to ensure the handle time fields are populated before the state changes to completed.
the issue isn’t just the wrap-up time. it’s how the dialog engine handles the state transition when preserve_context is true but the receiving queue has a different routing profile.
when you set wrap_up_time: 0, the system tries to close the interaction immediately. if the receiving agent hasn’t technically “accepted” the transfer in the performance engine’s view before that closure event fires, the handle time metric gets dropped. it’s a race condition between the flow state machine and the analytics aggregator.
i’ve seen this exact behavior in APAC regions where network latency causes a slight delay in the acceptance webhook. the flow thinks it’s done, but the analytics engine is still waiting for the ACCEPTED event.
here’s a safer config pattern:
transfer:
type: queue
queue_id: "sales_tier_2"
preserve_context: true
wrap_up_time: 30 # force a buffer
on_timeout:
action: disconnect # fallback if agent doesn't pick up
setting a non-zero wrap-up time forces the system to wait for the interaction to fully resolve before closing the metric window. it’s annoying, but it ensures the handle time is captured.
also, check your NLU intent logs. if the transfer is triggered by a bot intent, make sure the intent confidence is high enough. low-confidence transfers sometimes skip the standard routing pipeline and go straight to a fallback queue, which bypasses performance tracking entirely.
you can verify this by checking the conversation_history API for that specific interaction ID. look for the state field. if it jumps from RINGING to COMPLETED without an ACCEPTED state, you know the metric is being dropped due to the state machine timing out.
don’t rely on JMeter to catch this. load testing often masks these timing issues because the backend queues are saturated and behave differently than in production. test with a single thread and watch the real-time performance dashboard.
it’s a known quirk in the current version of the dialog engine. the engineering team is aware of it, but the workaround is to always include a wrap-up buffer for transferred interactions.