From ERP to Printer in 3 Seconds — The LabelInn Rules Engine

An order arrives in your system. By the time it lands in front of an operator on the line, a long list of decisions has already been made — or should have been. Which carrier handles it. Which design template prints. How many copies. Which printer in which warehouse. Whether anything special applies because of country, weight, or product hazard class. Whether a webhook should fire to a downstream system.

The reflex in most operations is to push all those decisions onto the operator. The operator scans, looks at the order, mentally translates marketplace SKU to internal SKU, picks the carrier, opens the right template, prints, walks the label to the correct station. That works at volume 50/day. It breaks at volume 800/day.

The LabelInn Rules Engine moves those decisions out of the operator's head and into a declarative rule set that runs on every incoming print trigger — automatically, deterministically, and testable before you turn it on.

The shape of a rule

Each rule has three parts:

1. Match conditions — what about the incoming print trigger does this rule apply to? Match by marketplace, cargo carrier, weight, destination country, SKU pattern, customer tier, presence of a specific tag — any field on the order or trigger payload.
2. Actions — what should happen when this rule matches? Set the design, set the copies, route to a specific printer (or printer role), call an MCP tool, call a connector, send a webhook, transform the data, delay.
3. Priority + scope — rules are evaluated in declared order and stop at the first match by default, or fall through if you mark them continue. Scope can be company-wide or per-site.

This is the same conceptual shape every workflow engine uses (Zapier, n8n, Boomi), but trimmed to the surface that label printing actually needs. No general-purpose ETL. No long-running flows. Each rule runs in milliseconds and produces a deterministic outcome.

A worked example — Trendyol orders, mixed carriers

A multi-marketplace seller has 800 daily orders split across Trendyol, Hepsiburada, ikas, and Shopify. The rules in the engine look like this:

RULE 1: "Trendyol → Trendyol Express (light weight)"
   IF  marketplace == "trendyol"
   AND order.weight_kg < 5
   THEN  carrier      = "trendyol_express"
         design       = "shipping_label_pro"
         printer.role = "shipping"

RULE 2: "Trendyol → Aras (heavy weight)"
   IF  marketplace == "trendyol"
   AND order.weight_kg >= 5
   THEN  carrier      = "aras_kargo"
         design       = "shipping_label_pro"
         printer.role = "shipping"

RULE 3: "Hepsiburada → Hepsijet"
   IF  marketplace == "hepsiburada"
   THEN  carrier      = "hepsijet"
         design       = "shipping_label_pro"

RULE 4: "Shopify international → DHL Express"
   IF  marketplace == "shopify"
   AND order.country != "TR"
   THEN  carrier      = "dhl_express"
         design       = "shipping_label_international"
         continue     = true   // fall through to rule 5

RULE 5: "International + heavier than 2kg → also print a customs form"
   IF  order.country != "TR"
   AND order.weight_kg > 2
   THEN  addLabel    = "customs_cn23"
         printer.role = "shipping"

Six rules cover every order shape this seller has. New marketplaces are added by adding rules. Carrier changes are a rule edit. The operator on the line never makes any of these decisions; the label arrives at the printer pre-routed.

The action vocabulary

Dry-run before you turn it on

Production rule sets are dangerous if you push them without testing. The rules editor includes a dry-run mode: paste a sample event payload (a real order export from your ERP works), the engine evaluates the entire rule set against it, and you see exactly which rules matched, what actions would have fired, and what the final print decision would have been. No actual print happens, no webhook fires, no carrier API gets called.

The dry-run output is the same shape as the production evaluation log. The Quality team can scroll through a batch of yesterday's orders, run them through tomorrow's rules in dry-run, and confirm the decisions before the rules go live.

Where rules evaluate — edge vs. cloud

The same rule set can evaluate in two places:

• Cloud evaluation — the default for marketplace-driven prints. The rule engine runs in our cloud backend; the print decision is computed there and the resulting job is dispatched to the right printer.
• Edge evaluation — for plants running the Edge Server, the same rule set is evaluated locally. This means rules that depend on local context (which printers are currently online on this LAN, which line is currently running which work order) can be matched on at the edge in single-digit milliseconds, without a cloud round-trip.

The rule set is the source of truth in the cloud and is synced down to edge nodes as part of normal configuration distribution. A rule edit propagates to every edge node within seconds.

What's on the roadmap

Two adjacent capabilities are designed and scheduled for Q3:

• Transform function runtime — sandboxed JavaScript for the transformData action so a rule can reshape an order payload into the design's variables without a separate transform service. Useful when an upstream system gives you the order in one shape and the design template expects it in another.
• AI-authored rules — describe what you want in plain English ("when Trendyol orders are over 5kg, send them via Aras Kargo on the warehouse-A Zebra"); the system proposes the rule, you approve, it ships into the staging environment first.

Both are visible in the roadmap but not yet generally available. The current rule engine is fully usable without them.