# Dispatch vendor change: records retention timeline | SourceX

Canonical: https://refer.sourcex.si/guides/preserve-emergency-work-order-prioritization-records
Last updated: 2026-10-19

Before a dispatch vendor change, inventory each record class against its own deletion point: call recordings usually go first, then priority change history held in audit logs, then SLA timers once the old platform is decommissioned, and closed work orders when read-only access ends. Open jobs, sites and assets normally move to the new vendor. For each class, record the years covered, the owner, the real date in writing and who must approve keeping it. Keep the inventory at metadata level.

This retention timeline is part of the [emergency work order prioritization guide](/guides/workflow-emergency-work-order-prioritization). The hub follows one upgraded job through its records; this page asks what happens to those records when the dispatch platform is replaced, and in what order they disappear.

## What a dispatch migration carries forward, and what it leaves

A migration project is judged on day one: can dispatchers book jobs on the new platform? So it carries what is needed to work. Open work orders, customer sites, assets, technicians and the current priority codes travel. The history that explains past decisions often does not.

| Record class | Usually migrated | Usually left behind |
|---|---|---|
| Open work orders | Yes | Nothing, if every open job is imported |
| Sites, assets and technicians | Yes | Retired assets and former technicians |
| Priority codes and target times | Current set | Earlier versions of the rule book |
| Closed work orders | Sometimes, as summary values | Change history, notes and attachments |
| Priority change history | Rarely | The audit trail of who changed what, and when |
| Moved bookings | Rarely | The link between a moved job and the emergency that bumped it |
| Response-target records | Rarely | Warning, failure and completion times per job |
| Service desk calls and recordings | Separate system | Recordings at the end of their retention period |

The left-hand column is what a dispatcher needs tomorrow. The right-hand column is what explains how urgent calls were handled for the past six years.

## The retention timeline, record by record

Each record type tends to have its own clock, set by the company's configuration, its contracts or the vendor's terms. The timeline below is Illustrative, for a fictional 510-person facilities maintenance contractor with a cutover date it has confirmed in writing.

| When | Event | Record at risk | Who must approve keeping it |
|---|---|---|---|
| Cutover minus 120 days | Migration field list agreed | Anything not on the list | Service operations director |
| Cutover minus 90 days | Call recording retention rolls forward | Oldest escalation recordings | Service desk manager, with counsel |
| Cutover minus 60 days | Audit log retention reviewed | Priority change history | Dispatch system administrator, approved by the COO |
| Cutover | Old platform set to read-only | Moved bookings and SLA timers lose their working view | Service operations director |
| Cutover plus 30 days | Response-target setup retired | Response-target records and their warning and failure times | Contracts lead |
| Cutover plus 90 days | Read-only access ends with the contract | Closed work orders, notes and photos | COO or CFO, who signed the vendor contract |

The audit row is the one that surprises people. On Microsoft Dataverse, for example, the administrator sets how long audit logs are retained; the default is Forever, but when another period is chosen, logs are deleted at its end and deleted audit logs cannot be recovered. Each update entry records the old and new value, which is exactly the priority history that shows a priority upgrade. A company that shortened retention to save storage may have already lost its earliest years.

## What disappears first, and why it matters

Three record types tend to go before anyone notices:

- **Escalation recordings and call notes.** They sit in a separate system with its own retention period. Without them, a priority change has no recorded reason beyond a dispatcher's short note.
- **Priority change history.** A priority is a field; the record that matters is every change to it. Platforms can express priority in fine detail (Dynamics 365 priorities carry a level of importance from 1 to 10 and a priority value from 1 to 100), but an import that keeps only the final value erases every upgrade and downgrade.
- **Response timers.** Microsoft advises against driving work order SLAs from frequently updated fields because a change can cancel the SLA item. So the response-target history around an upgraded job may already be partial, and a migration that drops it removes the only measure of whether the response was fast enough.

Closed work orders usually last longest, because finance and warranty teams depend on them.

## Who approves keeping each record

Preservation is a decision, and it belongs to the company. A partner's role is to make sure the decision is made before the deadline rather than by default.

- **The service operations director** decides which history matters operationally and convenes the others.
- **The dispatch system administrator** knows the audit and retention settings and can describe them, but does not approve keeping anything.
- **Counsel or the contracts lead** checks whether client contracts require site and incident records to be returned or deleted, and whether recordings must be purged.
- **The COO or CFO**, who usually signed the vendor contract, approves any extension of read-only access or an archive export.

Do not recommend retaining data the company has no authority to keep. Customer contracts may limit site and incident information, and recordings may carry notice obligations. The [who can license decision tree](/questions/who-can-license-emergency-work-order-prioritization-records) covers the licensing side, where the CEO authorizes a discussion and signs.

## The partner's preservation inventory

Fill this in with the service operations director, at metadata level, before the migration field list is final:

- [ ] Rule book versions by year, and when each changed
- [ ] Work order coverage in years, and whether closed jobs leave with the old vendor
- [ ] Priority change history: audited, since when, and the current retention setting
- [ ] Escalation calls: logged with work order numbers, and the recording retention period
- [ ] Moved bookings: visible as moved, with a link to the job that displaced them
- [ ] Response-target records: start, warning, failure and completion times per job
- [ ] Technician notes, photos and follow-up jobs
- [ ] Owner of each system, and who signed each contract
- [ ] The cutover, read-only and contract end dates, in writing

The [system map](/guides/emergency-work-order-prioritization-records-across-systems) shows how these records join. Partners who have worked on asset or contract transitions will recognize the pattern from [construction change order data](/data-types/change-order-data-construction), [engineering change orders](/data-types/engineering-change-order-process) and the [assignee checklist](/resources/abc-assignee-checklist); a sale of the business raises the same questions, covered in the [succession planning checklist](/resources/business-succession-planning-checklist).

The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. What stays unknown until SourceX reviews it: whether the preserved records are licensable, the preparation effort and any offer. Partners sign the Channel Partner Agreement before submitting, and the first valid introduction within the 90-day window is credited when the company submits a verified application.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client's dispatch contract has a documented end date and its priority history lives only in the old platform, [register as a partner](/register), check the company on [who qualifies](/who-qualifies) and read the [program terms](/terms) before the cutover plan is signed.

## Sources

- https://learn.microsoft.com/en-us/power-platform/admin/manage-dataverse-auditing
- https://learn.microsoft.com/en-us/dynamics365/field-service/sla-work-orders
- https://learn.microsoft.com/en-us/dynamics365/field-service/set-priorities
- https://refer.sourcex.si/terms