# ShipStation automation rules Source: > Audit every active ShipStation automation rule against the last 90 days of orders. Cut dead rules, fix conflicts, document the rest. Operators can predict what each tag does. ## The problem Rules accumulated over years. Multiple operators added rules that conflict, fire unexpectedly, or have not fired in months. Adding a new rule means hoping it does not break something nobody documented. One recent audit found 53 ShipStation rules on a single tenant; only 18 were actually firing. On the upstream OMS for the same business, 5 of 7 OrdersRuleEngine rules were "disabled" but operators still toggled 2 of them on for individual problem orders — the disabled-rules-as-tools anti-pattern. The rule engine no longer meant what it said. - **Competing rules**: two rules match the same orders and one wins by accident of priority. Operators learn the workaround. - **Dead rules**: half the rules in the engine have not matched an order in months. They sit in the priority list, slowing every import for no return. - **Mystery rules**: a rule fires that nobody on the current team configured. Touching it is risky because nobody can predict what depends on it. - **Disabled-rules-as-tools**: rules left disabled-in-name but toggled on for individual problem orders. The rule engine becomes operator scratchpad; the team can't reason about which rules apply to which orders. ## The solution We pull every active rule and match each against the last 90 days of order data. Dead rules get cut. Conflicting rules get consolidated with a clear priority. Every surviving rule gets one sentence on what it does and one on why. The team gets a one-page runbook. Then we replay the new ruleset against the last 90 days of orders and diff the results against what actually happened. Anything that would have routed differently surfaces for review before the new rules go live. No "we hope this works" shipped to production. - Every active rule inventoried with conditions, actions, owner, last-fired date, and 90-day match count. - Dead-rule report (zero matches in 90 days) and seasonal-rule flagging. - Conflict resolution: overlapping rules get a deliberate priority order or get merged. - 90-day historical replay before any change goes live. - One-page runbook of every rule for operators. - Tag-driven design so rules survive customer changes and re-imports. ## The outcome A smaller, faster, predictable rule engine. Operators predict what each tag does. New rules get added against documented gaps, not on top of unknowns. Every change is a deliberate choice. ## Frequently asked questions **Will this break our existing flows?** No. Every change runs through the 90-day replay before it goes live. Anything that would have routed differently surfaces for review. You sign off on each behaviour change before we flip the switch. **How long does the audit take?** 1-2 weeks for the audit and inventory; another 2-4 weeks for rebuild plus replay. Fastest path to a clean ruleset is around four weeks. Aim to finish before peak season; do not start three weeks out from Black Friday. **What about ShipStation Legacy versus the new ShipStation?** The audit method works for both. The new ShipStation rule engine handles some conditions cleaner (combined matches, tag-based logic). If you are mid-migration, we audit Legacy, build the new ruleset directly in new ShipStation, and use the migration as the cutover. **Can you maintain the rules ongoing or is this a one-shot?** Either. Most clients run the audit-and-rebuild as a one-shot, then have us back for a quarterly check. Some keep us on retainer to add and audit rules continuously as the business changes. ## Related - [/solutions/workflow](https://www.gotopo.com/solutions/workflow) - [/solutions/batching](https://www.gotopo.com/solutions/batching) - [/solutions/data-hygiene](https://www.gotopo.com/solutions/data-hygiene)