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.
- Transfer block configuration
- Wrap-up time settings
- Queue routing rules
- Flow trace analysis
- Performance dashboard metrics
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.