Salesforce Test Data Reservation
Salesforce test data reservation leases specific records to a single test run so parallel suites sharing one sandbox never read or modify each other's data. SyntraFlow is designed to lock and isolate datasets per run, removing the collisions that cause flaky, order-dependent failures in shared environments.
This page focuses narrowly on reservation and isolation. For the wider practice of preparing and provisioning test data, see the Salesforce test data management pillar.
When two runs fight over one record
Sandboxes are shared, and running suites in parallel is how teams keep a regression cycle fast. But when two runs pick the same Account or Case, one edits or advances a record the other is still asserting against, and both get unpredictable results. The failure has nothing to do with the code under test — it is a data collision — yet it looks exactly like a real defect, so teams waste hours chasing ghosts and eventually stop trusting the suite.
Test data reservation solves this by treating a record like a shared resource that must be checked out. A run reserves the records it needs, those records are locked to that run for its duration, and no other run may claim them until they are released. It is the data equivalent of a lock: parallel suites keep running side by side, but each works only on data that has been leased exclusively to it.
The cost of skipping reservation is subtle but corrosive. A collision rarely fails the same test twice in the same way, so it presents as intermittent — green on one run, red on the next, with no code change between them. Teams respond by re-running the suite until it passes, adding waits, or quarantining tests, all of which slow the cycle and erode confidence without fixing the cause. Because the symptom looks identical to a genuine flaky test, the real problem — two runs sharing one record — often goes undiagnosed for a long time. Reservation removes the whole class of failure by making exclusive access a guarantee rather than a hope, which is why it becomes essential the moment a team runs more than one suite against a shared sandbox at once.
Reservation controls who may touch a record during a run; returning records to a clean state afterward is a related but separate concern — see test data reset. Reservation coordinates access to data records, not configuration; the objects and fields themselves are metadata, a separate discipline.
How SyntraFlow is designed to reserve and isolate data
These capabilities are available for demonstration and proof-of-concept validation. The aim is parallel runs that never collide on the same records.
Record leasing
Designed to check out specific records to a single run for its duration, so no other run can read or modify them until they are released.
Dataset partitioning
Designed to divide a shared sandbox into per-run partitions so many pipelines can work concurrently, each on its own isolated slice of data.
Reservation registry
Designed to track which records are currently leased, by which run and until when, so allocation is coordinated rather than left to chance.
Automatic release
Designed to free a reservation when a run finishes or a lease expires, so records do not stay locked after a run ends or crashes.
Relationship-aware locks
Designed to reserve a record together with the related rows a test will touch, so a run does not lock an Account but collide on its child Opportunity.
Criteria-based reservation
Designed to claim records matching a scenario — an open case, a renewal-ready contract — so a run reserves what it needs by shape, not by hard-coded ID.
Pipeline integration
Designed to reserve at the start of a CI job and release at the end, so isolation is built into the automated run rather than managed by hand.
Contention handling
Designed to queue or reassign when the records a run wants are already leased, so a run waits or picks an alternative instead of colliding.
Reservation audit trail
Designed to log who reserved what and when, so a suspicious result can be traced back to whether a record was exclusively held during the run.
Isolation strategies compared
There is more than one way to stop parallel runs colliding. Reservation is often combined with the others rather than replacing them.
| Strategy | How it isolates | Trade-off |
|---|---|---|
| Record reservation | Leases specific rows to one run | Maximises shared-sandbox use; needs a coordinator. |
| Dataset partitioning | Gives each run its own slice | Simple isolation; needs enough distinct data to divide. |
| Run-scoped creation | Each run creates its own records | Total isolation; adds setup and cleanup per run. |
| Separate sandboxes | One environment per run | No collisions at all; costly and slow to provision. |
Reservation that spans connected systems
An end-to-end run may touch the same customer in Salesforce and an ERP at once, so isolating the Salesforce record alone is not enough. SyntraFlow is designed to coordinate reservations across Salesforce and connected systems such as Oracle ERP, SAP, Workday and NetSuite, so a shared entity is held exclusively on every side for the duration of a cross-system test. Explore the counterpart discipline in the Oracle ERP testing tool.
What reservation is designed to achieve
No parallel collisions
Leasing records to one run at a time removes the shared-data conflicts behind flaky, order-dependent failures.
Trustworthy results
When a failure can no longer be a data collision, a red test is far more likely to mean a real defect.
More parallelism
Many suites can safely share one sandbox, so a regression cycle finishes faster without extra environments.
Efficient sandbox use
Reservation gets more value from a shared org rather than spinning up a costly sandbox per run.
Hands-off isolation
Pipeline-integrated reserve-and-release builds isolation into automated runs with no manual coordination.
Traceable allocation
An audit trail shows whether a record was exclusively held, so odd results can be investigated with facts.
Test data reservation FAQs
What is Salesforce test data reservation?
It is leasing specific records to a single test run for its duration so no other run can read or modify them. Like a lock on a shared resource, it lets parallel suites share one sandbox while each works only on data reserved exclusively to it.
What problem does reservation solve?
Data collisions. When two parallel runs pick the same Account or Case, one changes a record the other is asserting against, producing flaky, order-dependent failures that look like defects. Reservation prevents the overlap so those false failures disappear.
How is reservation different from data reset?
Reservation controls who may touch a record during a run, preventing collisions while it executes. Reset returns records to a clean baseline between runs so the next one starts fresh. They are complementary: reservation isolates, reset restores.
Does reservation reserve related records too?
It is designed to. Relationship-aware locks reserve a record together with the related rows a test will touch, so a run does not lease an Account but then collide with another run on that Account's child Opportunity or Case.
What happens if reserved records are already in use?
Contention handling is designed to queue the waiting run or reassign it to alternative records that match the same criteria, so a run waits or picks another eligible record instead of colliding with the run that already holds the lease.
Are reservations released automatically?
Yes. A reservation is designed to be freed when a run completes or its lease expires, so records are not left locked after a run finishes or crashes and the sandbox does not slowly fill with stale, unavailable data.
Stop parallel runs from colliding
See how SyntraFlow is designed to reserve and isolate Salesforce test data so many suites share one sandbox without conflict.