Test Orders on a Live Store

Karl Falconer · Updated June 09, 2026 18:54

Sometimes you need to run a few test orders through a store that’s already live — to confirm a new Connection works end to end, or to validate a warehouse setup before going live with a customer. The problem: once a store is live, real customer orders arrive alongside your test orders, and DropStream can’t tell them apart at import. Left alone, both flow to the warehouse and get fulfilled.

The fix is a temporary Order Import rule that lets your marked test orders through and fails every other order. Real orders don’t ship — they wait safely in the Errors queue. When you’re done testing, you disable the rule and retry those orders so they fulfill normally. Nothing is lost.

For 3PLs: run this rule on the Connection you’re testing, and coordinate a short window with the merchant first — while it’s active, that store’s real orders all stop. Keep the window as brief as you can.

Why this uses `fail`

This recipe parks real orders with fail. A failed order lands in the Errors queue with the message you attach, and stays there until someone reprocesses it — so when the test window ends, you turn the rule off and retry those orders to fulfill them normally. Nothing is lost.

The reason to pick fail over reject or archive here isn’t reversibility — all three can be reprocessed. It’s visibility: fail surfaces the held orders in the Errors queue with a reason attached, so it’s obvious that orders are being parked on purpose and clear how to release them. reject and archive take orders out of the flow more quietly, which is the wrong signal when you’re deliberately holding real customer traffic.

Step 1 — Mark your test orders

Because DropStream can’t tell a test order from a real one, you have to give your test orders a marker that real customer orders won’t carry. Pick one and use it consistently. Good options:

A keyword in the order notes — something unlikely to collide, like DS-TEST-7842. Most sales channels let you add an order note or memo at checkout.
A dedicated test email — place test orders as a known address, ideally with plus-addressing (warehouse+test@yourcompany.com).
A test-only SKU — add a line item for a SKU that only exists for testing.

Avoid anything a real order might legitimately contain (don’t key off the word “gift”, a common coupon code, or a real product SKU).

Step 2 — Write the rule

The pattern is fail everything that isn’t a test order. Test orders fall through with no action, so they’re accepted and continue to the warehouse; everything else matches the not (...) block and fails.

rule "Live test window — pass test orders, hold real orders"
  when
    not ( order.notes contains "DS-TEST-7842" )
  then
    fail order with "Test window active — real order parked, not fulfilled. Disable the test rule and retry this order: " & order.id
  end
end

The error message does double duty: it tells whoever opens the Errors queue why the order is there and exactly how to clear it, and it tags the order id so you can find it later.

Variants by marker

Match a test email instead of notes:

rule "Live test window — pass test orders, hold real orders"
  when
    not ( order.customer_email is "warehouse+test@yourcompany.com" )
  then
    fail order with "Test window active — real order parked. Disable the rule and retry: " & order.id
  end
end

Match a test-only SKU on any line:

rule "Live test window — pass test orders, hold real orders"
  when
    not (
      order has any order_lines with ( order_line.sku is "TEST-SKU-001" )
    )
  then
    fail order with "Test window active — real order parked. Disable the rule and retry: " & order.id
  end
end

Accept more than one marker — useful when several people are testing:

rule "Live test window — pass test orders, hold real orders"
  when
    not (
      order.notes contains "DS-TEST-7842"
      or order.customer_email ends_with "@yourcompany.com"
    )
  then
    fail order with "Test window active — real order parked. Disable the rule and retry: " & order.id
  end
end

Step 3 — Test the rule before activating

Open the rule in the code editor (or the visual editor) and use the Test tab to confirm it behaves before it touches live traffic:

Run it against a sample order with your marker — it should pass (no fail).
Run it against one without the marker — it should fail with your message.
Use Suggest mode to pull real recent orders and confirm they’d all be failed.

Step 4 — Activate, test, then clean up

This is the part that’s easy to forget — the rule is deliberately blunt, so turning it off again is the most important step.

Activate the rule. From now on, only marked test orders fulfill.
Place your test orders with the marker and verify they flow through to the warehouse as expected.
Disable or delete the rule as soon as you’re done. See Managing Rules. The window should last minutes or hours, not days.
Clear the parked orders. Open the Errors queue, find the real orders the rule failed (your message and the order id make them easy to spot), and retry them. With the rule gone, they import and fulfill normally.

Tips

Keep it in its own rule. Don’t bury this logic inside a routing or mapping rule — you want a single switch to flip on and off.
Order it first. fail is terminal, so place this rule ahead of your other Order Import rules. There’s no point transforming or routing an order you’re about to park.
Shorter is safer. Every minute the rule is active is a minute real orders aren’t shipping. Coordinate the window, do your test, turn it off.
This recipe is for short, live windows. If you have a sandbox-style setup where certain orders should never fulfill, archive them instead — see the Filter out test orders recipe in Rules for Imported Orders.

Why this uses fail