A solution architect running Dynamics 365 Finance and Operations across forty legal entities kicks off an archive job for General Ledger transactions on a Friday afternoon, then checks back a week later to find eleven entities still sitting in the queue. Each job runs start to finish before the next one begins, so a single line of sequential processing does all the work no matter how much idle capacity sits behind it. That queue is a direct consequence of how Archive with Dataverse Long-Term Retention was originally built: one job in flight per scenario, and everything else waits. Microsoft’s March 2026 private preview changes that constraint, and it does so through one new configuration concept worth understanding before requesting access: the job criteria key that makes parallel archive processing possible.
Why Dataverse Archive Jobs Queue Up Today
Archive with Dataverse Long-Term Retention moves data through three stages: active, historical but retained for compliance, and eventually deleted. Getting a record from the first stage to the second is a six-step background process: replication into Dataverse, marking the source record as eligible, updating its retention status, reconciling that the copy landed correctly, migrating it out of the live table, and finally exposing it to inquiry pages that can still read history. Depending on data volume, that full cycle runs seven to fourteen days, and it runs at a deliberately low priority so it doesn’t compete with transactional workloads during business hours.
The scenarios supported today span general ledger and tax transactions in Finance, inventory transactions, inventory journals, and sales orders in Supply Chain Management, and commerce transactions in Commerce, with more expected in future releases. None of that changes with parallel processing. What changes is how many of those seven-to-fourteen-day cycles a tenant can have running at once. Until this preview, the answer was one, regardless of whether an organization operates three legal entities or three hundred. A multi-entity deployment with a genuine general ledger archiving need could watch a backlog grow for months simply because the platform had no concept of running two independent jobs side by side, even when the two jobs touched completely unrelated data.
What Parallel Archive Processing Actually Requires
The mechanism Microsoft introduced is narrower than “run everything at once.” It hinges on a job criteria key, a partition identifier assigned when an archive job contract is created. When the scheduler sees two jobs with different criteria key values, it checks whether they target non-overlapping sets of records, and if they do, it lets both run concurrently instead of forcing the second to wait. If they don’t, or if the system can’t establish that they don’t, the original sequential behavior still applies.
That non-overlap condition is stated as an absolute in Microsoft’s own documentation: each job with a different criteria key value must process a completely distinct set of records, with zero overlap. There is no partial-credit version of this feature where jobs run concurrently and reconcile conflicts afterward. DataAreaId, the field that already partitions Finance and Operations data by legal entity, is the criteria key Microsoft is leading with in preview, and it’s an obvious starting point precisely because it satisfies that zero-overlap requirement by construction. Two legal entities never share a General Ledger transaction, so keying parallel jobs off DataAreaId is close to a free performance win rather than a configuration exercise with real risk attached, provided the archival scenario itself doesn’t reach across entity boundaries somewhere a solution architect hasn’t accounted for.
Configuring the Job Criteria Key
The scenario itself doesn’t change; the contract does. When an archive job contract is created, the criteria key value is set alongside the usual scope of tables and date ranges, and it’s this value the scheduler reads to decide whether two in-flight jobs can share the pipeline. In practice, that means an implementation planning parallel General Ledger archiving across, say, twelve legal entities creates twelve contracts, one per DataAreaId value, rather than a single contract configured to somehow fan out internally.
Once jobs are running, the Archive with Dataverse Long-Term Retention workspace is where the criteria key earns its keep operationally. It surfaces each job’s key value alongside its status, so an administrator can confirm at a glance that the jobs actually running in parallel are the ones intended to run in parallel, rather than discovering after the fact that two jobs quietly targeted overlapping data. For organizations building custom archival scenarios against custom tables, the sequencing matters here specifically: those custom scenarios and their criteria key logic need to be defined and validated before the first parallel job runs against them, not adjusted afterward, because the zero-overlap guarantee has to hold from the first concurrent execution onward.
Where This Can Go Wrong
The zero-overlap requirement is also where the risk concentrates. A criteria key that looks like a clean partition on paper, a custom dimension that’s supposed to map one-to-one with a business unit, for instance, can turn out to have edge cases where two values legitimately touch the same record, particularly in customized environments where table relationships have been extended past their original design. Because the preview enforces zero overlap by requirement rather than by runtime detection of every possible conflict, the burden of proving that a custom criteria key is safe sits with the team configuring it, not with the platform.
Two other details are easy to miss because they don’t show up until after a job finishes. First, capacity reporting lags the actual archival work: history table capacity reductions from automatic tuning can take up to seven days to appear, and Dataverse’s own capacity figures take up to a day to catch up. Running four jobs in parallel instead of one doesn’t make that lag disappear, so finance and IT stakeholders expecting an immediate storage win on the day parallel jobs complete need that timeline set correctly in advance. Second, organizations that use customer-managed encryption keys should know that long-term retained data lands under Microsoft-managed keys regardless of how many jobs move it there in parallel, which means a CMK migration for that retained data is a separate project, not something parallel processing resolves as a side effect. Finance and operations attachments still aren’t supported in any configuration, and while data that hasn’t yet been archived can be handled through normal processes, data that has already made the trip into Dataverse long-term retention cannot be pulled back to live tables.
Piloting Before You Commit
Because this is a private preview, access starts with an enrollment request rather than a feature flag, and the honest advice for anyone requesting it is to have a specific backlog problem in mind rather than general curiosity about the feature. Organizations with dozens of legal entities and a General Ledger or inventory transaction archive that has been queuing for weeks are the clearest fit. A three-entity organization archiving a modest transaction volume is unlikely to notice much difference between sequential and parallel processing, since the queue was never the real bottleneck to begin with.
Once enrolled, the safer rollout path is to pilot parallel jobs against two or three legal entities in a sandbox first, confirm through the workspace that the criteria keys behaved as expected and that no overlap issues or data inconsistencies surfaced, and only then scale up to the full legal entity list in production. Given that archived data can’t be moved back to live tables, a misconfigured criteria key is not a mistake worth discovering at production scale. Treat the capacity reporting lag and the CMK migration question as items to raise with finance and security stakeholders during that same pilot, not after the first production jobs complete, so nobody is caught explaining an unexpected reporting delay or an encryption gap after the fact. For organizations already running Archive with Dataverse Long-Term Retention against a multi-entity Finance and Operations deployment, this preview is worth requesting now. Routeget has been helping clients sequence long-term retention rollouts around exactly this kind of phased validation, and parallel archive processing is a natural next step for any environment where the backlog, not the archive design itself, has become the actual problem.
#DataverseArchive #ParallelProcessing #LongTermRetention #DynamicsFinanceOps #DataCapacityPlanning #CloudArchitecture
No comment yet, add your voice below!