Illustrative workflow data package: a SaaS company's support-to-fix histories

What is a support-to-fix workflow package?#

A support-to-fix workflow package is a set of linked cases, each tracing one customer problem from report to resolution across the systems a SaaS company uses. It differs from a ticket export because every case carries the engineering work and the customer communication that closed it.

AI developers look for this shape because it records the full path of real work: how a symptom was described, how it was diagnosed, what code changed, how reviewers judged the change, when it shipped and what the customer was told. That sequence is useful for training and evaluating both coding agents and support agents.

Everything below describes a fictional company. The structure is the point: record types, join keys, a manifest and written exclusions that anyone could apply again.

Illustrative: the company and its systems#

Illustrative: a fictional accounts payable automation vendor has sold to mid-market finance teams for many years. Support runs in Zendesk, engineering tracks work in Jira, code lives in GitHub, release notes are published from Confluence, and escalations are discussed in a shared Slack channel.

When the CEO and CTO decide to explore a license, they agree on one scoping decision up front: the package will contain only cases where a closed ticket links to a Jira issue. Tickets that never touched engineering stay out, which keeps the package focused on support-to-fix work rather than general support.

The record types and their join keys#

The record types in this package are joined by IDs that the systems stored at the time, not by matching words after the fact. The support team used a Jira integration that wrote the issue key onto the ticket, and engineers put the issue key in branch names and pull request titles by convention.

Where a key was missing, the team did not guess. Cases linked only by a Slack thread or a phrase in a comment went into a separate subset marked as inferred links, so a buyer can include or ignore them.

The manifest: what each case file contains#

The case manifest gives every chain a new pseudonymous case ID and lists the records in that chain, the timestamp of each step and how each link was established. Record IDs are re-keyed for delivery, and the crosswalk back to the original Zendesk, Jira and GitHub IDs stays with the company. A buyer can then filter by product area, resolution code or link method without opening a single record.

At the dataset level, the manifest follows the shape of published provenance standards. The Data & Trust Alliance Data Provenance Standards, for example, group dataset metadata into Source, Provenance and Use, and the specification says that metadata is needed to enable proper dataset selection for AI model training.

The table shows one fictional case entry. Field names are illustrative; what matters is that every hop records its source and its link method.

• 1Case ID, issued for the package and unrelated to any customer account.
• 2Re-keyed ticket, issue, pull request and release references for every record in the chain.
• 3Timestamps for ticket creation, escalation, merge, release and final reply.
• 4Resolution code and reopen flag from the help desk.
• 5Link method for each hop: system field, branch naming convention or inferred.
• 6Inclusion notes, such as a rejected first pull request before the one that shipped.

How cases were selected and excluded#

Case selection in this example follows written rules, so the package can be rebuilt from the source systems and checked by someone who was not involved. Each rule names what is in, what is out and why.

The customer restriction rule came out of the rights review, not the engineering team. Counsel reviewed order forms and master agreements and listed the accounts whose tickets had to be removed, and the export script applied that list before preparation began.

Preparing the package without breaking the chain#

Preparation for a linked package has one extra requirement compared with a flat export: every replacement must be consistent across systems. The engineer who appears as an assignee in Jira, a reviewer in GitHub and a voice in the Slack escalation must receive the same pseudonym in all three places, or the chain stops making sense.

Code needs its own pass. Pull requests and abandoned branches can hold API keys, connection strings and sample invoices used as test fixtures. Secret scanners help; TruffleHog, for instance, says it scans Git, chats, wikis and logs and can log in to check whether a found secret is still live, which calls for care when the credentials belong to a third party.

Timestamps stay, because the order and spacing of steps is part of what the package shows. Customer names inside code comments, commit messages and release notes are replaced with role labels such as customer A.

Mistakes that break a support-to-fix package#

The mistakes that most often break a package like this come from treating it as several separate exports instead of one set of chains. Each mistake below removes a link, a step or a person from the story.

• 1Linking tickets to issues by fuzzy text matching and presenting the result as fact.
• 2Exporting current issue fields without the status and field change history.
• 3Dropping closed, unmerged pull requests, which removes the record of what reviewers rejected.
• 4Pseudonymizing each system separately, so one engineer becomes three people.
• 5Leaving customer-specific code or vendored libraries in the repositories that feed the diffs.
• 6Skipping the release step, so a buyer cannot tell whether a fix ever reached customers.

How SourceX would handle a package like this#

SourceX would run this package through the SourceX five-step transaction. In Supply, a metadata-only fit check asks which systems hold the records, how many years are accessible and how the systems link; in Rights, contracts and repository ownership are reviewed; in Preparation, personal and confidential details are removed with consistent pseudonyms.

In Approval, the company signs off on the manifest and a prepared sample before anything is released, and in Delivery the package stays in the company's own storage or ships on an encrypted drive. The SourceX Evidence Packet then records provenance, licensing rights, permitted use, the privacy record and release authorization.