Rules & executions
Why this matters for your business
Rules are easy to build. Keeping them running cleanly over time is where most automation programs fail. Triggers stop firing. Actions silently fail. Conditions reference fields that no longer exist. Without visibility, the team's confidence in automations decays — every "did the rule fire?" becomes a 2-hour investigation.
The Rules & executions surface fixes this. Every fire is logged, searchable, and replayable. Every failure surfaces with a clear reason and a "fix this" button. Stale rules get flagged. Rules that haven't fired in 90 days get suggestions to retire them. The result is an automation program that stays trustworthy at scale.
What this typically unlocks
| Outcome | Result |
|---|---|
| Time to debug a misbehaving rule | 5 minutes vs. 1-2 hours |
| Stale rules accumulating | near 0 — flagged for retirement |
| Confidence "did the rule fire?" | 100% — execution log proves it |
| Rule disable/enable safety | safe — disabled rules don't fire but aren't deleted |
What you actually get
Rule editor
A no-code visual builder:
| Section | What it does |
|---|---|
| Trigger picker | Search the typed catalog (Trigger-action model) |
| Condition builder | Same operators as segments (sales-engine) |
| Action chain | One or more actions in sequence; type-checked vs. trigger payload |
| Dry-run toggle | Preview vs. execute |
| Approval requirement | Per-rule (Agency+) |
| Schedule (cron rules only) | Daily/weekly/custom cron |
Rule list
| Filter | Use |
|---|---|
| Active vs. disabled vs. dry-run | Working state |
| By trigger | "All rules that fire on order_created" |
| By action | "All rules that touch tag" |
| Last fired | "Rules that haven't fired in 90 days" |
| Failure rate | "Rules with > 5% failures last 7d" |
Execution log
Every fire of every rule, with:
- Trigger payload (what data the rule received)
- Conditions evaluated (each condition + result)
- Actions taken (each action + outcome)
- Total duration
- Outcome (
success/partial/failed/skipped/dry_run_preview) - Replay button (re-run the action chain on the same payload)
Searchable by date range, customer, rule, outcome.
Failures dashboard
Aggregated view of every rule that failed in the last 7 days, grouped by reason:
| Failure reason | Suggestion |
|---|---|
| Condition referenced removed field | Update the condition |
| Action target deleted (e.g. journey removed) | Update the action |
| Rate-limit hit (action quota) | Reduce trigger volume or upgrade tier |
| External webhook 5xx | Investigate target system |
| Approval timed out (> 7 days unanswered) | Review queue, approve or deny |
Each failure has a one-click "fix this" that opens the rule editor pointed at the problem.
How it works (without the technical bits)
Idempotency
Every fire is keyed by (rule_id, trigger_event_id). If the
same trigger arrives twice (Shopify webhook retry, Zapier
re-fire), the rule executes once. Replay-safe by default; no
double-tagging or double-charging.
Retries
Failed actions retry with exponential backoff (1s, 5s, 30s, 5m, 30m). After 5 failures, the action is marked failed and surfaces in the failures dashboard — no infinite-retry storms.
Concurrency
The rule engine handles thousands of fires per minute per shop without queuing visible delay. P95 trigger-to-action latency: under 500ms.
Real merchant scenarios
Scenario A — Debugging "the VIP tag rule isn't firing"
Old way: check Slack, ask marketing, hunt through Shopify admin, give up after 30 minutes.
New way:
- Rules tab → search "VIP" → see rule's last-fired = 6 days ago
- Click "Test on customer X" → simulator shows: condition fails
because
predicted_ltv_12mois null on this customer - Cause: customer is too new for predictions
- Fix: add
predicted_ltv_12mo IS NOT NULLto condition - Redeploy — works
Total time: 4 minutes.
Scenario B — Cleaning up stale rules quarterly
Brand has accumulated 47 rules over 2 years. Quarterly hygiene:
- Filter "last fired > 90 days ago" → 18 rules
- Review each: 14 are obsolete (campaigns ended, products removed); 4 are still relevant but waiting for triggers
- Archive the 14 obsolete; document the 4
Result: cleaner mental model, faster rule editor (less to scroll through).
Scenario C — Catching a silent failure pattern
Failures dashboard shows: "5 rules failing with 'webhook 5xx' last 24h." All target the same Zapier integration.
Investigation: Zapier flow was deleted by another team member.
Fix: redirect rules to new Zapier flow → 0 failures next 24h.
Without the failures dashboard: these would have failed silently for weeks.
Best practices
✅ Use clear rule names. VIP_tag_from_LTV_threshold beats
Rule_47.
✅ Tag rules by purpose. marketing, ops, compliance —
makes the list searchable.
✅ Review failures dashboard weekly. A 5-minute hygiene ritual that prevents most automation drift.
✅ Enable dry-run on all new rules first. Even simple ones.
❌ Don't disable rules and forget. Disabled-but-not-archived rules are a maintenance smell. Decide: live or gone.
❌ Don't ignore failure-rate alerts. Alerts fire for a reason; a rule failing on 30% of trigger events is broken.
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Rule editor | — | ✓ | ✓ | ✓ | ✓ |
| Execution log | — | 7 days | 30 days | 90 days | 365 days |
| Failures dashboard | — | ✓ | ✓ | ✓ | ✓ |
| Rule simulator | — | ✓ | ✓ | ✓ | ✓ |
| Rule export/import | — | — | ✓ | ✓ | ✓ |
| Cross-shop rule library | — | — | — | ✓ | ✓ |
| Replay action chain | — | — | ✓ | ✓ | ✓ |