Stuck on GDPR Data Subject Request export for migrated Zendesk interactions

Administration
1

Stuck on generating a complete data subject export for users who had tickets in our legacy Zendesk system. We are currently migrating from Zendesk to Genesys Cloud and need to comply with GDPR regulations for our EU users. The issue arises when trying to fetch interaction history for users who had support requests before the cutover date. Our current approach uses the Genesys Cloud Interaction Search API, but it only returns interactions created within Genesys Cloud. It completely ignores the historical data we migrated via the Zendesk-to-GC migration tools last month. This creates a compliance gap where we cannot provide a full data dump to users upon request.

I have verified that the migrated interactions exist in the system by checking the Interaction Search UI with filters for the specific user email. The records appear correctly with the correct metadata and timestamps. However, when I trigger the Data Subject Request export via the API endpoint /api/v2/compliance/dataprivacy, the resulting CSV file only contains interactions generated after the migration date. The historical Zendesk data is missing from the export, even though it is searchable in the platform. This suggests that the compliance export tool does not index or recognize migrated legacy data as part of the user’s interaction history for privacy purposes.

Our environment is Genesys Cloud EU-West, and we are using the latest REST API documentation for the compliance endpoints. The migration was performed using the standard Zendesk migration connector provided by Genesys. I have checked the admin console for any data retention policies that might exclude migrated data, but everything seems standard. The issue seems specific to how the compliance export tool queries the interaction database versus how the search API queries it. I need to ensure that all user data, regardless of origin, is included in the export to avoid legal issues.

Can anyone confirm if migrated Zendesk interactions are supposed to be included in the GDPR data subject request exports? If so, is there a specific flag or configuration setting that needs to be enabled to include legacy data? I have reviewed the admin config for compliance settings but found no obvious toggle for this. Any advice on how to manually append the legacy data or fix the export scope would be greatly appreciated. We are under pressure to resolve this before our next audit cycle.

2

The way I solve this is by bypassing the Interaction Search API for pre-cutover data, since Genesys Cloud cannot query external Zendesk records.

  • Maintain a separate GDPR export pipeline for the legacy Zendesk database.
  • Merge the resulting datasets in your integration layer before delivering the final report to the data subject.
3

How I usually solve this is by warning that merging datasets manually introduces significant compliance risks if timestamps aren’t perfectly aligned. Ensure your legacy Zendesk export includes the exact created_at ISO 8601 format to prevent audit failures during the merge process.

4

The approach above works, but the merge logic needs strict type handling. Genesys Cloud timestamps are Unix epoch in milliseconds, while Zendesk uses ISO 8601 strings. A direct concatenation breaks the sort order.

Convert all legacy timestamps to epoch before merging. Use this JMeter BeanShell pre-processor snippet for validation during your export job:

import java.text.SimpleDateFormat;
import java.util.Date;

String isoDate = vars.get("zendesk_created_at");
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ");
Date date = sdf.parse(isoDate);
long epochMs = date.getTime();

vars.put("unified_timestamp", String.valueOf(epochMs));

Steps to ensure compliance:

  • Parse ISO strings to epoch milliseconds in your ETL job.
  • Append a source tag (gen vs zendesk) to each record.
  • Sort by unified_timestamp descending.
  • Verify no duplicate interaction IDs exist across sources.

This keeps the dataset sortable and auditable. The API rate limits on the legacy side are also lower, so throttle your requests to 100 per second to avoid blocking.