Integrations
Dry run and approval: see what the integration will change before it writes
An integration writes at API speed, so a wrong rule is wrong on 4,000 products within a minute. Every run is built first and written second. A dry run shows the changes, approval holds them for a person, and exclusions and overrides keep your manual arrangements from being overwritten.
A wrong rule is applied 4,000 times
A person who mistypes a price changes one product. An integration that reads cents as dollars changes every product in the run. Shopify accepts 250 items per call, so a supplier feed of 4,160 rows is 17 calls and is in the store within a minute.
Two cases from the flow pages show the size. A truncated export sets 3,910 of 4,160 rows to zero, 94% of the catalog, where the run before it had 212 rows at zero. A typing error in the ERP moves item 10517 from $48.00 to $4.80. With 200 products someone sees it the same day. With 4,000, a customer finds it first: an item that sells 36 units an hour has sold 72 units at a tenth of its price after two hours.
Every run therefore has two steps: build, then write. The controls on this page sit between the two. They apply to all five flows on the integrations overview.
How it works
Build, then write
The build reads the source, reads the current values in the target and compares them. The result is a diff: per record the old value, the new value and the source it came from. The diff is stored for every run, written or not.
run 2026-10-02 06:00 mode: approval feed: stock_20261002.csv rows: 4,160
unchanged 3,812
quantity changed 302 of which 12 to zero
expected date changed 41
held 5 quantity "> 10" is not a number
written 0
3,812 plus 302 plus 41 plus 5 is 4,160: every row is accounted for. A row that fails validation is held with its reason. It is not skipped.
Three modes
| Mode | What is written | Typical use |
|---|---|---|
| Dry run | nothing | a new connection, a changed mapping, a new supplier feed |
| Approval | the diff, after a person releases it | price lists, new products, the first runs of a feed |
| Automatic | at once, unless a hold rule stops the run | stock, order import, tracking numbers |
The mode is set per connection and per flow. One supplier feed can wait for approval while the ERP stock next to it runs automatically.
Hold rules
An automatic run is held when it crosses a limit you set. The limits below are examples; the right number follows from what your own runs look like on a normal day.
| Flow | Example rule | What it catches |
|---|---|---|
| Stock | more than 20% of the rows go to zero | a truncated file, an export that ran halfway |
| Prices | a price moves by more than 30% | a decimal error, a price per box read as a price per unit |
| Product data | a product loses one or more variants | an item set to inactive by mistake |
| Orders | store total and ERP total differ | tax calculated twice, a rounding difference |
A held run waits in the dashboard with the reason. You release it as it stands, release it without the held rows, or discard it and correct the source. The rows that were not held can go through on their own.
Release
A diff that waits gets old. Between the build at 06:00 and the release at 09:40 the store sold 2 units of item 00123456. The diff says: set 90, the store shows 96. The store now shows 94. Each write therefore carries the value the diff was built on. On Shopify that is the changeFromQuantity field of the stock write: the call is refused when the current value is not 96. The integration recalculates that one item, 90 minus 2 is 88, and writes it. The other 342 changes go through as approved.
Parallel run next to what you have now
Replacing an existing integration, or a process someone does by hand, starts with the new integration running next to the old one with writes disabled. It receives the same orders and reads the same stock, builds what it would have written, and compares that with what the old process wrote.
Take a parallel run of 14 days in which the store took 1,260 orders:
| Result | Orders | Cause |
|---|---|---|
| Identical to the old process | 1,231 | |
| Tax total differs | 17 | the old script taxed shipping, the new mapping did not |
| Different customer record | 8 | the old script matched on name, the new one on email |
| Total differs by $0.01 | 4 | rounding per line against rounding on the total |
| Total | 1,260 |
29 of 1,260 orders differ, 2.3%. Each group is a decision. The 17 orders show a rule of the old script that was in nobody's documentation. The 8 show duplicate customer records. For an undocumented script, this comparison is the documentation.
The switch is made per flow. Stock can go live while orders stay on the old route, and the old route remains available until the new one has run without differences. Orders placed during the switch are assigned to one route by order number, so no order is imported twice and none is left out. The notes on replacing an integration cover the cut-over.
Exclusions and overrides
Some values are set by hand on purpose. An exclusion takes a product, a field of a product, a customer or a location out of a flow. An override pins a value. Both carry an end date and the name of who set them.
exclusions
10482 price until 2026-10-10 promotion at 8.99, set by marketing
20731 title no end date campaign title
overrides
00123457 ship date 2026-12-15 until the goods are received
Item 10482 is skipped by the price run until October 10 and returns to it on October 11 without anyone removing the line. The diff of each run reports the count, excluded: 14, so a forgotten exclusion stays visible. An exclusion without an end date is listed separately for the same reason: a product that was excluded two years ago is a product with a two-year-old price. What belongs on that list is the subject of what not to sync.
What it covers
- Dry run. Any run against live data with writes off, and a stored diff.
- Approval. Per connection and per flow, with a release that checks for changes made since the build.
- Hold rules. Limits on zeros, price movement, removed variants and totals, set per flow.
- Exclusions and overrides. Per product, field, customer or location, with an end date.
- Diff per run. Old value, new value and source per record, kept as the log of what changed and why.
Which systems
The controls use what the systems on both sides already have.
| System | What the control uses | Effect |
|---|---|---|
| Shopify | product status DRAFT |
a new product waits unpublished until it is approved |
| Shopify | changeFromQuantity on a stock write |
a stale approval cannot overwrite a sale |
| Shopify B2B | orders submitted as draft orders | an order is reviewed before it is accepted |
| NetSuite | sales order status Pending Approval | an order above your limit waits in the ERP for a person |
| Business Central | sales order status Draft, In Review or Open | an imported order stays a draft until it is released |
| Supplier files | the file itself, archived unchanged | a dry run can be repeated on the same input |
What each flow holds and why is on the flow pages: stock and availability, pricing and customer terms, product data and orders, customers and shipping.
Where standard connectors stop
Standard connectors and iPaaS platforms switch a flow on or off. A flow that is on writes what it calculates, and what went wrong appears afterwards in an error list. Records the mapping could not place are skipped, as the stock page describes for items without a mapping record. A test environment is an edition feature: the entry edition of one large iPaaS platform comes without a sandbox.
There is no stored diff to release, no rule that stops a run in which 94% of the catalog goes to zero, and no list of exclusions with end dates. Failed calls are a separate subject: retries, the queue and the records that still fail are in what happens when a sync fails.
In an integration we build and run for you, the first live run is preceded by dry runs on your own data, and you decide per flow what waits for a person. The dashboard and its logs are shown on how an integration works. Send us one file or one day of orders, and the first dry run shows what it would change. Tell us what you run.
Frequently asked questions
Does a dry run touch our store or ERP at all?
It reads and does not write. The reads are real API calls and count against the same limits as any other call: on a Shopify standard plan that budget is 100 points a second. For a large catalog the build is scheduled outside the busy hours, like a live run would be.
Can approval be on for prices and off for stock?
Yes. The mode is set per connection and per flow. A price list usually waits for approval, since a price is checked once a day and a wrong one reaches an invoice. Stock runs automatically with a hold rule, since a quantity that waits four hours for a person is out of date when it is released.
What happens when nobody approves a run?
Nothing is written and the store keeps the values it had. The dashboard shows the run as waiting, with its age, and an alert goes out when a run waits longer than the time you set. When a newer run is built before the older one is released, the newer diff replaces it, so two diffs are never released on top of each other.
Is a dry run the same as testing in a sandbox?
No. A sandbox is a copy of your ERP from the day it was refreshed, and writes to it are safe. A dry run reads the production systems of today and writes nothing. The sandbox proves that a write works. The dry run shows what that write would do to this morning's data, including the customer that exists twice and the item that was renamed last week.
Who can release a held run?
Anyone with a login to the dashboard. Each release, exclusion and override is logged with the name of the person, the time and the values before and after. That log answers the question a customer asks a month later: why did this price change on that day.
When does a parallel run end?
Per flow, when every difference in the comparison has an explanation. A difference is a fault in the new mapping, which is fixed, or a behavior of the old process that nobody had written down, which is then decided on. Flows go live one at a time, and the old route stays in place until the first live flow has run clean.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase