Every order that comes into a warehouse carries dozens of small decisions. Which warehouse should fulfill it? Does it need a signature? Should it ship on the customer's own FedEx account or yours? Is this the kind of order that needs a second look before it goes out the door? At low volume, a person can make these calls one order at a time. Past a few hundred orders a day, that stops being realistic, and the decisions either get skipped, get inconsistent, or get pushed onto whoever is fastest at the shipping station that day.
An order management rules engine is a system that automatically evaluates incoming orders against defined conditions and applies actions such as warehouse routing, carrier selection, order holds, or product substitution, without a person reviewing each order individually. It's how growing fulfillment operations replace that manual decision tree with logic that runs the same way every time.
This guide walks through how a rules engine works, the specific rules that solve the most common fulfillment problems, and where the automation continues once an order moves from the warehouse to the carrier.
Techdinamics offers two platforms that handle this logic at different stages:
An order management rules engine is a system that evaluates incoming orders against a set of conditions and automatically applies actions based on the result, without a person reviewing each order individually. A rule is built from three parts: a trigger that defines what starts the evaluation, a condition that defines what must be true, and an action that defines what happens next.
For example, a rule might say: if an order ships to a province in Western Canada and the western warehouse has enough stock, route the order there. If not, check the next region. That single rule replaces a warehouse team manually checking province and inventory on every order that comes in.
Rules engines exist across order management systems, from enterprise platforms to lightweight Shopify apps, because the underlying problem is universal: fulfillment involves too many conditional decisions to handle manually once volume grows past a certain point.
Before building rules, it helps to understand two concepts that determine how they behave once orders start flowing through them: triggers and priority.
A trigger defines what starts a rule. In techOMS, this can be API-driven (a sales channel integration sending in a new order), UI-driven (a warehouse team member manually allocating and fulfilling an order), or a combination of both.
Priority determines the sequence in which rules execute. This matters more than it might seem. If two rules share the same priority and both could apply to the same order, the result can be unpredictable. The recommended sequence is routing decisions first, order-level reference actions second, and line-level actions last. Setting priority deliberately, rather than relying on the order rules happen to be created in, is what keeps a growing rule set predictable as it scales.
Many of the rules covered in this guide are demonstrated live in this techACADEMY:
The most foundational rule in most fulfillment operations is routing: deciding which warehouse should fulfill a given order. There are two approaches, and most operations start with one and grow into the other.
Static routing assigns orders to a warehouse based on a fixed, predefined condition, most commonly geography. For example, in Canada, an order shipping to Ontario or Quebec might always route to an Ontario warehouse; an order shipping to a Western Canadian province routes west, if warehouse has stock. If neither condition is met, the rule can fail over to a default location.
Static routing is quick to set up, requires no additional integration, and gives an operations team a clear, predictable answer to "where will this order ship from." Its limitation is that it doesn't account for real-time variables. A border case, like an order shipping to eastern Quebec, might be cheaper to fulfill from an eastern warehouse than from Ontario, but a static rule using province alone won't catch that. Static routing also can't react to carrier rate changes, so a routing decision that was optimal when the rule was written can quietly become the wrong call as shipping costs shift.
As techOMS Product Manager Adam Lavergne has said before: "Back in the day, if an order was headed to the West Coast, you shipped it from your West Coast warehouse. Simple, but not smart anymore. What happens when you have five, six, or ten fulfilling nodes?"
Dynamic routing solves this by evaluating each order against real-time data instead of a fixed rule. Using techSHIP's rate-shopping integration, techOMS can compare estimated shipping cost and delivery time across every warehouse with sufficient stock, then select the location using a defined priority: lowest estimated shipping cost first, with time-in-transit as a tiebreaker, and warehouse priority as a final tiebreaker if both are equal. Operations can also flip that order and lead with time-in-transit when speed matters more than cost.
Dynamic routing is more complex to configure and depends on a techSHIP integration, but it evaluates every order individually instead of relying on a rule that was accurate the day it was written.
The right choice depends on the operation. Static routing fits simple, cost-sensitive setups with a small number of fulfillment nodes. Dynamic routing fits operations focused on scalability and cost optimization across a larger, more complex network.
For a side-by-side walkthrough of both approaches in the techOMS interface, watch this techTALK episode:
Split shipments, where a single order fulfills from more than one warehouse because no single location has full stock, are expensive. Each additional shipment adds its own carrier cost, packaging, and processing overhead. Lavergne has described averaging 1.26 splits per order in a prior retail operation as unacceptable, and notes that the fix is getting routing right at the source rather than managing the symptoms downstream.
Rather than leaving split decisions to chance, a rule can define exactly when a split is acceptable. A common configuration: if no single warehouse can fulfill the complete order, allow a split into a maximum of two shipments, but only if the primary shipment covers at least 50% of the order (by item count or order value). If a second location can't cover the balance, the remainder is automatically backordered rather than forced into a costly third shipment.
This turns an expensive, unpredictable outcome into a controlled one. The alternative, letting splits happen wherever inventory happens to fall short, is how split rates climb without anyone deciding they should.
Not every order should move straight to the warehouse. Some need a second look first, and a rules engine can isolate exactly those orders without slowing down everything else.
A common example uses fraud scoring data that some sales channels provide as part of the order payload. If a channel like Shopify flags an order as medium risk or higher, a rule can automatically set that order to a draft status, which prevents it from being sent to the warehouse management system for fulfillment. The customer's team can then review the order, check the details, and manually release it if they're comfortable proceeding. If the order does turn out to be fraudulent, that release action becomes part of the audit trail.
A similar pattern applies to high-value orders. A rule might flag any order above a defined dollar threshold, moving it to draft status and triggering a notification so someone can confirm the order before it ships.
The bigger operational win is keeping questionable orders out of the warehouse entirely while they're pending, on top of catching fraud or flagging large orders for review. A held order sitting in techOMS doesn't show up in a pick wave, doesn't require a warehouse team to filter it out manually, and can't accidentally ship before it's been reviewed. The warehouse keeps moving at full speed on everything else while these edge cases wait in a separate queue.
Some destinations don't fit a standard shipping rate or timeline, and a rules engine can flag those before they become a fulfillment problem instead of after. Orders shipping to Hawaii, Alaska, Puerto Rico, or Canadian territories like Yukon or the Northwest Territories often require a custom delivery quote rather than a standard rate. A rule can detect these destinations, place the order on hold, and trigger a notification so the team can confirm pricing with the customer before the order proceeds. The same pattern can apply based on product type, for operations that want to offer a different delivery experience for specific items regardless of destination.
As with fraud and high-value holds, the point is containment. The order isn't lost or delayed indefinitely, it's held in a defined state until a specific condition (customer approval of a custom quote) is met, and it never reaches the warehouse in an ambiguous state.
For 3PLs managing multiple client accounts on a shared platform, one of the more practical rules is also one of the easiest to overlook: matching the right carrier account and billing information to the right client automatically.
Lavergne has seen this failure repeatedly across drop-ship operations: "One of the mistakes I saw most frequently that my drop ship vendors would do, they would forget to log out of my shipping account before they start processing another retailer's orders." Orders shipped on the wrong account surfaced only during monthly carrier bill reviews, which meant paying an analyst to comb through invoices and issue chargebacks to the responsible vendors. As the frequency climbed, non-compliance fees became necessary just to recover the labor cost of chasing the errors.
A rule can eliminate that entire failure mode. Define the condition (a specific company name or sales channel) and the action (the correct carrier, service level, and third-party billing account number for that client), and the system applies it automatically regardless of which shipper is processing the order. One client might ship FedEx Ground on their own account; another might ship UPS Second Day Air on theirs. Neither requires a person to remember which is which, and neither can be shipped on the wrong account by mistake.
This is also where techSHIP's Order Management Rules (OMR) pick up where techOMS leaves off, discussed in more detail below, since carrier and billing decisions often need to be validated again at the moment of rate shopping, not just at order intake.
Product substitution rules solve two different problems, and it's worth treating them separately because the logic and the reason for using them differ.
Out-of-stock substitution replaces an item that's unavailable with a defined alternate, based on a priority order set in the product catalog, or with added conditions (like restricting the substitution to orders from a specific sales channel). This keeps an order moving instead of stalling on a single missing item. Critically, a substitution rule should always raise a flag to an exception dashboard when it fires. The substitution fixes the immediate outcome, but the flag is what surfaces the underlying inventory problem, so it gets addressed, rather than being invisible until a customer notices they received the wrong color and calls in to ask why.
Shelf-life-driven substitution solves a different problem and shows up most often with perishable or dated inventory. If a smaller pack size is running low on shelf life, a time-bound rule can substitute a larger pack size in its place for a defined window, before the smaller pack expires and must be discarded. From the customer's side, this looks like added value. From the fulfillment side, it's considerably cheaper than writing off expired inventory. This kind of rule runs continuously in the background without requiring anyone to remember to apply it during a specific week.
Beyond routing and holds, a rules engine can handle a long list of smaller decisions that add up to meaningful operational and customer experience gains:
The CTO of a logistics and supply chain company using techOMS shared the following in a Capterra review:
"What stands out most about techOMS is its incredibly powerful and flexible rules engine. The ability to map complex reference fields dynamically from various sales channels straight to a warehouse management system without requiring custom code or IT intervention completely changes the workflow."
None of these require a person to intervene once they're set up. They run continuously, apply consistently across every order that meets the condition, and remove one more manual step from the shipping station.
Everything above lives in techOMS, deciding how an order gets built, routed, and released to the warehouse. Once an order starts moving through the shipping process itself, a related but distinct rules engine takes over: techSHIP's Order Management Rules, or OMR.
Where techOMS rules answer "where should this order be fulfilled and under what conditions," techSHIP's OMR answers "what should happen at each stage of getting this order rate-shopped, packed, and shipped." The two systems share the same if-then logic pattern, but they operate on different data and at different points in an order's lifecycle.
OMR runs on defined lifecycle triggers tied to the shipping process itself: After Order Import, Before Processing, Before Rate Shopping v1, Before Shipment Booking, After Rate Shopping (to validate the winning carrier rate before committing to it), and After Shipment Booking (for any post-processing calculations needed once a label is generated). Legacy rules were automatically migrated to this naming convention with no disruption to existing operations.
A few examples of what OMR handles:
Some shipping requirements should scale automatically with an order's total declared value or destination rather than being decided manually every time. A rule can require a signature on delivery for any order above a set declared-value threshold or apply that requirement automatically for international shipments above a lower threshold, since cross-border orders often carry more risk. Available signature options vary by carrier: some support simple enabled, disabled, or default states, while others offer more specific options such as age verification.
The same logic applies to insurance. A single rule can evaluate total declared value once and set both the insurance and signature required flags together, so a $200 threshold covers both requirements without maintaining two separate rules.
What makes this useful at scale is that these thresholds are definable per customer account. One customer might require a signature above $500; another might require insurance on anything above $100. Rather than a single global policy, each account can carry its own logic, and the rules engine applies the right version automatically based on which account the order belongs to.
The clearest illustration of why this matters comes from a real fulfillment scenario our team has worked through directly: a retailer shipping temperature-sensitive products across multiple warehouse locations.
For products like frozen goods, delivery speed and cost trade off in ways that aren't obvious from a spreadsheet. Choosing three-day shipping over next day might save a few dollars in carrier cost but require an extra ten dollars in coolant to keep the product safely frozen the whole way. In these cases, static routing based on geography alone isn't enough, since the real cost of a shipping decision includes packaging and product-specific handling, not just the carrier rate.
Vendor scorecards are where operator judgment meets automated routing. The scorecard itself is something an operations team builds and maintains: which locations hit their SLAs, which handle certain product categories well, which have proven reliable over time. That analysis then gets encoded into the routing rule as warehouse priority, alongside lowest estimated shipping cost and shortest time-in-transit, as sequential tiebreakers. For products where time-in-transit genuinely matters, that doesn't automatically mean air freight. An extra $100 for a guaranteed morning delivery rarely outweighs a cheaper ground option arriving reliably the same evening.
The rules engine encodes a whole set of trade-offs the operations team would otherwise have to reevaluate manually for every order. That consistency is what moves an operation toward the Perfect Order Process.
━━━━━━━━
━━━━━━━━
The rules covered here run continuously across techOMS and techSHIP without manual intervention: routing decisions, fraud holds, carrier selection for a specific client account, and everything in between. If your team is still making these calls manually at the shipping station, it might be time to see what a rules engine built for exactly this kind of complexity can do. Schedule a call with our team to learn more.