Do not automatically send every WooCommerce order to ERP and logistics. Define in advance which statuses, sales channels, payment methods, order types and attributes may start a workflow, and record the applicable rule for every rejection. An explicitly filtered order is healthy; an order that silently disappears is not.
Why “synchronise everything” is risky
An online store contains more than ordinary paid sales orders. Consider test orders, manually entered corrections, failed payments, drafts, subscription instalments, zero-value replacement deliveries and orders handled by another process. If one generic integration treats all of them as new revenue, errors arise that only become visible in administration or the warehouse.
Filters therefore belong before the first external write operation. They must use the current, validated order rather than an isolated webhook record. Give the outcome a recognisable status such as processed, filtered or needs attention. This lets you explain later why order 7319 did not become an AFAS order without reconstructing log entries.
Create a filter checklist for each process
| Question | Example rule | When uncertain |
|---|---|---|
| Is the status suitable? | Only paid or explicitly released | Do not write; set aside |
| Is the sales channel included? | Only store NL, not the test store | Check the workspace and store ID |
| Is this a standard financial order? | A zero-value replacement delivery follows its own process | Classify the order type |
| Which fulfilment method applies? | Post, own delivery or collection | Block unknown methods |
| Is all required information complete? | Valid debtor, address and order lines | Create a task that can be resolved |
Use one filter checklist per workflow, rather than one opaque collection of exceptions for the entire system landscape. The flow to AFAS may have different entry requirements from the flow to a carrier. See connecting WooCommerce and AFAS for why source and destination rules must be defined for each business object.
Fictional example: a test order does not become revenue
Fictional example: furniture store Kader & Kurk uses a hidden payment method for internal showroom tests. An employee places order 11204 to check a new delivery option. The order receives the status “processing”, but its “internal test” attribute and specific payment method exclude it from the financial workflow.
The event remains visible as “filtered: internal test order”. If required, the logistics test can continue in a separate sandbox process without creating a sales entry in AFAS or a real shipment. When an ordinary customer order arrives with the same shipping method but no postcode, that is not a filtering case: the order falls within the intended scope but is incomplete. It moves to “needs attention”, with a task to correct the address. The distinction between out of scope and a recoverable error is operationally essential.
Review filters as product rules
Document each rule's owner, reason and expected lifespan. A temporary block for one campaign must not silently become a permanent business rule. Test positive and negative examples: an order that should proceed, one that should be filtered and one that needs human attention. Ask operations to review the descriptions; “predicate false” is technically correct but helps nobody.
- Can an employee find the filter reason from the order?
- Can you count filtered orders by store and reason?
- Can an order be reassessed after its source data is corrected?
- Have financial and logistics filters been tested separately?
- Does reprocessing avoid running previously filtered side effects twice?
Connect can apply such rules to each configurable flow. Exceptions needing substantive review belong in Desk, together with the order context and a clear next action.
A good periodic review starts with an export of filter outcomes, not the code. Rank reasons by frequency and financial or operational impact. A sudden increase in “unknown shipping method”, for example, points more towards a changed store configuration than poor orders. Then sample each category and ask a process owner to confirm the handling is correct. Separately measure how many filtered orders are submitted again later; a high proportion may mean a temporary source status is being treated too early as a final exclusion. Version the rules and record which example orders serve as regression tests for each change. This makes filters a verifiable agreement between sales, administration and fulfilment rather than a hidden collection of if-statements.
Would you like to turn your order types and exceptions into a filter checklist? Arrange a process review with Yindle.