Queue Performance Dashboard 'Handled Conversations' Metric Divergence with Architect Flow Logic

General Discussion
1

Hi all,

We are observing a persistent data inconsistency between the standard Queue Performance dashboard and the actual flow execution logs in Architect. Specifically, the ‘Handled Conversations’ metric in the dashboard is significantly lower than the count of conversations that reach the final disposition step in our primary inbound flow.

Environment:

  • Region: EU-West (Frankfurt)
  • Dashboard View: Queue Performance (Last 24 Hours)
  • Flow Version: v4.2 (Published)

Issue Description:
Our inbound flow is configured to route calls to a specific queue. Upon agent acceptance and subsequent hang-up, the conversation is marked as ‘Handled’ in the flow via a specific disposition node. However, when reviewing the Queue Performance dashboard for the same timeframe, approximately 15-20% of these conversations are either missing from the ‘Handled’ count or are incorrectly categorized under ‘Abandoned’ or ‘Offered’.

We have verified that:

  1. The queue ID in the flow matches the dashboard filter.
  2. The disposition code used in the flow is mapped correctly to ‘Handled’ in the analytics settings.
  3. There are no known outages reported in the status page for the EU region.

Could this be related to how the analytics engine processes real-time data versus the flow execution state? We need to ensure our SLA reporting is accurate, as this discrepancy is causing significant reporting issues for our operations team. Any insights into potential latency in the analytics pipeline or configuration mismatches would be appreciated.

2

I see this divergence often when we push high concurrent volumes through Architect. The Queue Performance dashboard relies on specific state transitions that might not align with your custom disposition logic. If your flow uses a “Transfer to Queue” or “Add to Queue” action after some initial handling, the dashboard might count the initial interaction, but your flow logs show the final disposition.

Check if your Architect flow is using the Set Conversation Attribute action before the final disposition. The dashboard metric “Handled Conversations” usually triggers on agent_accept followed by agent_close. If you are using a bot or IVR to handle the call before transfer, ensure the handled_by attribute is correctly set to agent or bot as per your business logic.

Here is a JMeter snippet I use to verify the state transitions during load tests:

{
 "action": "set_conversation_attribute",
 "attributes": {
 "handled_by": "agent",
 "disposition_code": "resolved"
 }
}

Also, check the WebSocket connection limits. If you are hitting the 1000 concurrent WebSocket limit per user, some state updates might drop, causing the dashboard to lag behind the actual flow execution. I saw this in my EU-West tests last week. The dashboard updates are eventual consistent, but under heavy load, the delay can be significant.

Try adjusting your Architect flow to explicitly set the disposition attribute before ending the conversation. This ensures the dashboard picks up the correct count. If the issue persists, check the API rate limits for the reporting endpoints. Sometimes the dashboard fails to fetch real-time data during peak loads.

We usually see this when the flow logic is complex. Simplifying the path to disposition helps. Also, monitor the conversation_id in the flow logs to ensure it matches the dashboard records.

3

I ran a quick load test on this exact metric divergence yesterday using JMeter to simulate 50 concurrent queue entries. The issue isn’t just the flow logic; it’s how the platform batches the handled status updates during high-throughput scenarios.

When you have bursts of completions, the Queue Performance dashboard often lags because it aggregates data from multiple microservices. If your flow completes the disposition step before the queue system fully registers the handled state, you get this split.

Here is what I observed in my JMeter script when forcing rapid dispositions:

// Simulating rapid disposition updates
const updateDisposition = async (conversationId) => {
 await fetch(`/api/v2/conversations/${conversationId}/dispositions`, {
 method: 'PUT',
 body: JSON.stringify({ disposition: "handled" })
 });
 // Note: Dashboard often misses this if called < 200ms after queue entry
};

The suggestion about Set Conversation Attribute is valid for tracking, but for the dashboard metric specifically, try adding a small delay or a conditional check in your Architect flow to ensure the conversation is fully removed from the queue before marking it handled.

Also, check if you are using Transfer to Queue actions. If the conversation is transferred and then handled, the original queue might not reflect the final handled count correctly in the 24-hour view due to how analytics rollups work in EU-West.

I saw a 15% drop in reported handled conversations when I removed the explicit wait step in my flow. Adding a 500ms pause before the final disposition action aligned the dashboard numbers with my Architect logs. Worth a try if you are seeing similar gaps.