Troubleshooting Missing Wrap-Up Codes in Analytics Dashboards

How-To-Articles
1

Troubleshooting Missing Wrap-Up Codes in Analytics Dashboards

What This Guide Covers

This guide details the exact configuration, data flow, and debugging steps required to resolve missing or incorrect wrap-up codes in Genesys Cloud analytics reports. You will configure Architect flow assignments, validate agent desktop state reconciliation, map report filters to the correct interaction dimensions, and verify raw API payloads to isolate where the data drops. The end result is a fully traceable wrap-up code pipeline that accurately reflects agent post-call actions in both real-time and historical analytics.

Prerequisites, Roles & Licensing

  • Licensing Tier: CX 1 or higher (Wrap-up codes are core routing functionality; analytics reporting requires CX 1+ with standard reporting enabled)
  • Required Permissions:
    • Routing > Wrapup Code > Read
    • Architect > Flow > Read
    • Analytics > Report > Read
    • Analytics > Report > Edit (if modifying report filters)
    • Telephony > Interaction > Read (for API debugging)
  • OAuth Scopes: interaction:read, routing:wrapup:read, analytics:report:read
  • External Dependencies: None for core platform debugging. If integrating with external CRM or middleware via CTI, ensure the integration respects the Genesys Interaction API lifecycle and does not prematurely terminate the interaction object.

The Implementation Deep-Dive

1. Architect Flow Configuration and Wrap-Up Code Assignment

Wrap-up codes do not exist in a vacuum. They are properties of the interaction object that must be explicitly set before the interaction transitions to the Completed state. In Genesys Cloud, the Architect flow dictates the initial wrap-up requirements, but the final value is determined by the agent action or flow override at interaction closure.

To configure wrap-up assignment correctly, navigate to the routing flow and locate the Wrap-up block or the Set Wrap-up Requirements block. You must define the wrapup.code field using either a static string or a dynamic variable. When using the Set Wrap-up Requirements block, you specify the exact wrap-up code ID from the routing configuration. The flow then pushes this requirement to the agent desktop.

The Trap: Engineers frequently configure the Set Wrap-up Requirements block but fail to place it before the End Conversation or Release block. If the flow ends before the requirement is pushed, the agent desktop receives no wrap-up prompt. The agent clicks “Wrap Up” immediately, and the platform defaults to an empty string or the queue default. Analytics then reports the interaction as having no wrap-up code, even though the flow appears configured.

Architectural Reasoning: The Genesys platform processes interaction state transitions sequentially. The wrapup_requirements payload must be injected into the interaction object while the interaction is still in the Agent-Connected or Agent-Wrapup state. Once the interaction crosses into Completed, the platform locks the interaction metadata. Late-bound assignments are rejected by the routing engine to preserve data integrity for billing and compliance. Always place wrap-up assignment blocks at least two steps before the final release action.

To verify flow execution, use the Architect Debugger. Run a test interaction and inspect the wrapup_requirements event in the trace. The payload should resemble the following:

{
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "type": "wrapup_requirements",
  "wrapup": {
    "code": "WPC_001",
    "text": "Call Resolved"
  }
}

If this event never fires, or if it fires after the completed event, your flow topology is incorrect. Reorder the blocks to ensure the wrap-up assignment occurs during the active agent session.

2. Agent Desktop State Reconciliation and Manual Overrides

Agents interact with wrap-up codes through the Agent Desktop UI or the Soft Phone. The desktop sends a wrapup action to the routing engine when the agent closes the interaction. This action can either accept the flow-assigned requirement or manually select a different code from the available list.

The platform reconciles the flow requirement with the agent selection using a priority matrix:

  1. Flow override (if the flow explicitly sets the code via API or block)
  2. Agent manual selection
  3. Queue default wrap-up code

The Trap: Enabling “Allow agents to skip wrap-up” at the queue level destroys analytics accuracy. When this setting is active, agents can bypass the wrap-up screen entirely. The platform records the interaction as completed with a null wrap-up code. In analytics, these interactions appear as missing data, not as “Skipped” codes. Engineers often blame report filters when the root cause is a permissive queue configuration that allows state bypass.

Architectural Reasoning: The Agent Desktop maintains a local state object that mirrors the server-side interaction. When the agent clicks the wrap-up button, the desktop evaluates the wrapup_requirements payload. If the requirement exists, the UI blocks the close action until a code is selected. If the requirement is absent or the skip flag is true, the desktop sends an immediate complete action with an empty wrapup field. The routing engine accepts this to preserve agent productivity, but it sacrifices data granularity. To maintain analytics integrity, disable skip permissions on all queues that feed critical dashboards. Enforce mandatory wrap-up selection through flow requirements rather than UI toggles.

To audit agent behavior, inspect the interaction history via the API. Retrieve a specific interaction ID and examine the wrapup field in the response:

GET /api/v2/interactions/{interactionId}
Authorization: Bearer <access_token>

Response payload excerpt:

{
  "id": "xyz-123-abc",
  "type": "voice",
  "state": "completed",
  "routing": {
    "wrapup": {
      "code": "WPC_005",
      "text": "Transferred",
      "agentId": "agent-uuid-here"
    }
  }
}

If wrapup.code is absent, the agent bypassed the requirement or the flow failed to assign it. Cross-reference the interaction timestamp with the queue configuration to determine if the skip permission is active.

3. Analytics Report Filtering and Dimension Mapping

Analytics reports in Genesys Cloud evaluate dimensions and filters against the aggregated interaction dataset. Missing wrap-up codes in dashboards are frequently caused by incorrect filter syntax, dimension misalignment, or report type limitations.

When building a report, you must select the correct metric group. Use Agent Interactions or Routing Interactions for wrap-up code analysis. Navigate to the Filters tab and add a filter for Wrap-up code. The platform exposes this dimension as wrapup.code in the API and as a dropdown in the UI. You must select Is not empty or explicitly list the valid codes you expect to see.

The Trap: Engineers frequently use wrapup.text instead of wrapup.code in custom filters or API-driven reports. The text field is a human-readable label that can be translated, localized, or overridden by admin naming conventions. The code field is the immutable system identifier. Filtering on text causes mismatches when labels are updated or when multiple queues share the same label but use different internal codes. Reports then return zero results or exclude valid interactions.

Architectural Reasoning: The Genesys report engine indexes dimensions at the time of interaction completion. The wrapup.code dimension is stored as a normalized string key. The wrapup.text dimension is stored as a localized display value. The analytics pipeline prioritizes the code for aggregation because it guarantees referential integrity across data exports, Data Warehouse sync, and third-party BI tools. Always filter and group by wrapup.code. Use wrapup.text only for display columns in the report grid.

To validate report filter behavior, export the report as JSON using the Analytics API. This reveals the exact filter payload the engine evaluates:

GET /api/v2/analytics/report/interactions/query
Authorization: Bearer <access_token>

Request body:

{
  "metrics": [
    {
      "name": "interactions",
      "type": "count"
    }
  ],
  "dimensions": [
    {
      "name": "wrapup.code"
    }
  ],
  "filters": [
    {
      "dimension": "wrapup.code",
      "operator": "notempty"
    }
  ],
  "dateRange": {
    "from": "2023-10-01T00:00:00.000Z",
    "to": "2023-10-31T23:59:59.999Z"
  }
}

If the response returns empty rows despite known wrap-up activity, the filter is excluding the data. Verify that the report timezone matches the interaction completion timezone. The platform aggregates data in UTC. Mismatched timezone filters can push interactions outside the evaluation window, causing apparent data loss.

4. API Payload Validation and Data Warehouse Synchronization

When UI reports and flow debugging yield no results, you must inspect the raw data pipeline. Genesys Cloud streams interaction data to the internal data warehouse, which powers historical analytics. Real-time reports query a separate cache layer. Synchronization delays or schema mismatches can cause wrap-up codes to appear missing in dashboards.

Use the Interaction API to pull raw interaction records and verify the routing.wrapup structure. If the API returns the code correctly but the dashboard shows nothing, the issue resides in the report aggregation layer or the data warehouse sync queue.

The Trap: Assuming real-time report data is identical to historical report data. Real-time analytics query an in-memory cache that updates every 30 seconds. Historical analytics query the persisted data warehouse. If an interaction completes during a cache flush or a warehouse partition rotation, the real-time report may temporarily drop the wrap-up code. Engineers often escalate this as a platform bug when it is actually a synchronization window.

Architectural Reasoning: The Genesys analytics architecture separates real-time and historical data paths to optimize query performance. Real-time reports sacrifice completeness for speed, dropping interactions that fail cache validation. Historical reports guarantee completeness but introduce a 15 to 30 minute latency. Wrap-up codes are evaluated at interaction completion. If the completion event arrives during a partition switch, the code may not propagate to the real-time cache until the next sync cycle. Always validate missing data against the historical report or the raw Interaction API before opening a support case.

To debug synchronization gaps, compare the interaction completion timestamp with the report query timestamp. If the interaction completed within the last 30 minutes, wait for the warehouse sync cycle. If the interaction is older than 24 hours and still missing, the data pipeline dropped the event. Inspect the Data Warehouse export files if you have DaaS enabled. The wrapup_code column in the interactions table should match the API payload.

GET /api/v2/interactions/search
Authorization: Bearer <access_token>
Content-Type: application/json

Request body:

{
  "query": {
    "field": "routing.wrapup.code",
    "operator": "contains",
    "value": "WPC_001"
  },
  "size": 10,
  "page": 1
}

If the search returns zero results, the wrap-up code was never written to the interaction object. If it returns results but the dashboard is empty, the report filter or dimension mapping is incorrect. Use this API to isolate the failure boundary between data ingestion and report rendering.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Flow Override versus Agent Override Conflict

The failure condition: The dashboard shows a wrap-up code that differs from the code the agent selected. The analytics metric counts interactions under the wrong code.
The root cause: The Architect flow contains a Set Wrap-up block that executes after the agent has already selected a code. The flow overrides the agent input during the interaction state transition. The platform prioritizes flow assignments over agent input when the flow block runs closer to the completed state.
The solution: Remove post-selection flow overrides. If dynamic wrap-up assignment is required, use the Set Wrap-up Requirements block to define the available options, not the final value. Allow the agent to select from the constrained list. If the flow must assign the code automatically, ensure the block runs before the agent desktop prompts for input. Validate the block execution order in the Architect debugger trace.

Edge Case 2: Real-Time Report Lag and Aggregation Windowing

The failure condition: Agents complete calls with wrap-up codes, but the real-time dashboard shows zero interactions for those codes for 10 to 20 minutes. Historical reports eventually show the data.
The root cause: Real-time analytics use a sliding window aggregation model. Interactions that complete during a window boundary are held until the next aggregation cycle. High call volume accelerates the window rotation, increasing the delay. The report engine filters out interactions that lack a finalized wrapup.code during the hold period.
The solution: Switch the dashboard to historical mode for accurate counting. If real-time visibility is mandatory, configure the report to use Wrap-up code (real-time) dimension, which tolerates incomplete state. Add a time filter that excludes the last 15 minutes of data to prevent reporting on in-flight interactions. Document the latency expectation for stakeholders to prevent false escalations.

Edge Case 3: Multi-Queue Routing and Wrap-Up Code Inheritance

The failure condition: Interactions routed through multiple queues show the wrap-up code from the first queue, not the final queue. Analytics dashboards attribute the code to the wrong routing context.
The root cause: When an interaction is transferred between queues, the platform preserves the initial wrapup_requirements payload unless explicitly cleared. The final queue inherits the first queue’s requirements. If the final queue does not push a new requirement, the agent desktop displays the legacy options. The agent selects a code that belongs to the original queue context.
The solution: Insert a Clear Wrap-up Requirements block at the start of each downstream queue flow. This forces the platform to discard inherited requirements. Immediately follow it with a new Set Wrap-up Requirements block specific to the current queue. This ensures the agent desktop presents only relevant codes. Validate the transfer flow topology to guarantee the clear block executes before the agent reconnects to the new queue.

Official References