Ran into a weird issue today with our legal discovery bulk export jobs where the predictive routing wait time metadata is completely absent from the manifest files. We are using Genesys Cloud v2024.06.0 and initiating exports via POST /api/v2/analytics/conversations/export for digital channel conversations specifically involving Web Chat and SMS. The requirement is to have the exact queue wait duration and routing strategy ID for chain of custody verification. However, when the export job completes successfully, the manifest.json contains null values for queue_wait_time_seconds and routing_strategy_id. This is critical because our legal team needs to prove that calls were not delayed or misrouted during the incident period. We have verified that the data exists in the UI for individual conversations, so it is not a data availability issue. The API call returns a 202 Accepted status, and the job status eventually moves to completed without any error logs in the job history. We are using the standard legal hold export profile which should include all routing attributes according to the documentation.
We have tried adjusting the filter criteria to include only conversations with specific routing strategies, but the result remains the same. The metadata fields are consistently null across all exported records for the last 30 days. This is blocking our ability to finalize the discovery request for a client audit. We are operating in the London timezone, so all timestamps are UTC+1. The issue seems isolated to predictive routing scenarios; standard skills-based routing exports contain the expected metadata. We have also checked the audit trail for any changes to the export profile, but nothing has been modified recently. Could someone clarify if there is a known limitation with predictive routing metadata in bulk exports for digital channels? We need a workaround or a fix to ensure the chain of custody remains intact. The lack of this data is causing significant delays in our legal compliance process. We have escalated this internally, but no resolution has been provided yet. Any insights into why the API might be stripping this specific metadata would be appreciated. We are considering switching to individual conversation exports, but that is not scalable for the volume of data we are handling.