Introduction
Writing a large batch of Deals straight into a production CRM — doesn't just imagining it make you a little tense? If there's a mapping mistake, hundreds of wrong Deals could get created.
That's why I adopted the idea of a Dry Run. Write nothing, and confirm "what would happen" first. Just this one extra step makes production rollout feel completely different. This article explains the mechanism and the operating procedure.
What a Dry Run is
A "confirm without writing" mode
A Dry Run runs the sync all the way through but skips only the writes to the CRM. It fetches transactions, matches identities, and converts to Deals and LineItems just as usual, then outputs "what would be created or updated in production" as a report.
Fetch → transform → write to CRM. Data is actually created and updated
Fetch → transform → report results. No writes, just confirm the content
In other words, it follows the same road as production but stops one step short. That's the crux of safety verification.
Why it's needed
Sync bugs are, more often than not, found "only when real data flows." Things like notation drift you missed in the test environment, unexpected store codes, or identity-matching misses.
Undoing after writing is hard
Bulk-deleting or fixing mistakenly created Deals afterward is a task heavy on both effort and risk. Catch it in advance with a Dry Run, and you just fix the mapping or table and re-run. Having a "place to pause" is your operational safety net.
What to check in a Dry Run
Counts and the breakdown of creates/updates
In the Dry Run report, first check the overall sense of scale. "How many new Contacts, how many links to existing ones, how many Deals would be created" — if these numbers are far from expectations, it's a sign something is off.
Especially when "new Contacts are extremely high," matching keys likely aren't working well — proceed with caution.
Validity of matching and Owner
Beyond counts, check the content by sampling. Pull a few records and visually verify "does this transaction tie to the right customer and the right rep."
For matching: is this transaction of this customer number hitting the right existing Contact? For Owner: is this store code resolving to the correct rep? You can confirm whether the mapping design and Owner map behave as intended before touching production. If something feels off here, revisit mapping design or the Owner map.
Switching to production and operation
Roll out to production in stages
Once the Dry Run confirms no issues, it's finally production. Even so, don't push all records at once the first time — go to production small, scoped by period or store, confirm the results in the CRM, then widen to the whole.
Check counts, the breakdown, and sample validity
Fix mapping or the table, and Dry Run again
Sync scoped by period or store, and confirm results
If fine, do all records, then move to daily auto-sync
Rather than aiming for perfection in one shot, widening while confirming turned out to be the fastest and safest.
Combining daily sync with manual runs
Once production is stable, leave steady-state operation to the daily auto-sync via QStash. Pulling in the previous day's transactions each day keeps the CRM automatically up to date.
Keep manual runs too. They're useful for "I want to re-sync a specific period" or "fill a gap right now," and you can also "first Dry Run manually after changing settings." A setup that lets you switch between auto and manual, and between Dry Run and live, raises your operational freedom.
Conclusion
A Dry Run is a safety net that lets you confirm "what would happen" before touching the production CRM. Check the count breakdown and sample validity, fix issues, then roll out to production in stages — just following this makes syncing large data far less scary.
For details on the mapping and Owner content checked in a Dry Run, see mapping design and Owner map operation. For the overall aim of the effort, see the hub article.