Automations
The 5 building blocks
How triggers, conditions, and actions compose. The primitives.
Manage your rule catalog; inspect every execution with full audit.
Preview 7 days of fires before any action runs. Mandatory on paid actions.
Human approval gate before high-stakes actions execute.
What this typically unlocks
| Outcome | Typical result |
|---|---|
| Hours/week on routine ops | 20–40 hours saved depending on volume |
| Time-to-action on fired triggers | < 30 seconds vs. minutes-to-days manual |
| Dropped-followup rate | near 0 (vs. 10–20% manual) |
| Audit-grade trail of who did what | complete vs. memory + Slack search |
| Preview before paid actions | dry-run mode prevents costly accidents |
| Multi-step workflows (X→Y→Z) | possible without code |
What you actually get
| Block | What it does |
|---|---|
| Triggers | Events the system listens for — order placed, customer tagged, segment joined, stock low, etc. |
| Conditions | Rules that filter the trigger ("only if AOV > $100", "only if region = EU") |
| Actions | What happens — tag a customer, send a Slack alert, update a price, push to Meta audience, etc. |
| Dry-run mode | Preview the actions a rule would take without actually doing them |
| Approval queues | Human approval gate before high-stakes actions execute |
| Audit log | Every fire, every action, every outcome — searchable + exportable |
How it powers every part of your store
| Routine task | Automation that handles it |
|---|---|
| Tag VIP customers automatically | Trigger: customer hits LTV threshold → Action: add vip tag |
| Notify on big orders | Trigger: order > $500 → Action: Slack alert + email founder |
| Restock notification | Trigger: inventory back-in-stock → Action: notify customers who viewed |
| Tag risky customers | Trigger: refund rate > 30% → Action: tag manual_review |
| Sync to Meta audience | Trigger: customer joins segment → Action: push to Meta Custom Audience |
| Update price dynamically | Trigger: competitor price drops > 10% → Action: lower price match |
| Cross-engine flows | Trigger: customer completes order → Action: enroll in journey + sync to CRM |
| Cleanup tasks | Trigger: cart abandoned > 30d → Action: delete from list |
How it works
Trigger categories
- Customer events — created, updated, tagged, lifecycle change, opt-in change
- Order events — created, paid, refunded, fulfilled, cancelled
- Product events — created, updated, sold-out, restocked, price-changed
- Marketing events — campaign launched, journey enrolled, message opened/clicked
- Inventory events — low-stock, back-in-stock, reservation created
- External events — webhook from Zapier, custom HTTP trigger
- Time-based — daily/weekly/cron schedules
- Anomaly events — anomaly detector fired
Each trigger is typed with a known payload — no guessing what data is available.
Action categories
| Category | Examples |
|---|---|
| Customer actions | Tag, untag, update field, enroll in journey, exit journey |
| Marketing actions | Send transactional email, send Slack alert, push to ad audience |
| Catalog actions | Update price, update inventory, hide product, change SKU |
| External actions | Fire webhook, post to Zapier, create row in Airtable |
| AI actions (Pro+) | Generate copy, suggest segment, predict churn |
| Multi-step | Run another rule after this one (chained actions) |
Paid-spend, AI-cost, and price-changing actions get extra protection — see dry-run mode and approval queues.
Real merchant scenarios
Scenario A — VIP tagging at scale
Trigger: customer's predicted LTV updated. Condition: predicted_ltv_12mo > 500 AND vip NOT applied. Action: add vip tag.
Result: ~40 customers/month tagged in real time. Manager's 2 hours/month freed. Tags arrive the moment the customer qualifies.
Scenario B — Big-order Slack alerts
Trigger: order_created. Condition: order_value > 1000. Action: post to #orders + email founder.
Result: Real-time notifications, 0 missed orders. Founder no longer scans Shopify inbox for big orders.
Scenario C — Restock notification
Trigger: inventory back_in_stock. Condition: viewed-but-not-purchased customers in last 30d ≥ 20. Action: send "back-in-stock" email.
Result: Restock emails out within 2 minutes of inventory arriving. Conversion rate 18% (was ~9% on delayed emails). For one SKU over 60 days: +$8,400 incremental revenue.
Scenario D — Cross-engine enrollment chain
Trigger: order_created with first_time = true. Action 1: enroll in welcome journey. Action 2: add to "lookalike seed - first buyers" segment (auto-syncs to Meta daily).
Result: Meta lookalike performance +18% within 3 months as the seed audience grew.
Best practices
✅ Use dry-run for first 7 days of any new high-stakes rule.
✅ Name rules clearly. "VIP tag from LTV" beats "rule_47".
✅ Watch the audit log weekly. Catches misfires.
✅ Use approval queues for paid-spend actions.
❌ Don't pile too many actions on one trigger (> 5 — split).
❌ Don't disable rules silently — delete or archive.
❌ Don't bypass dry-run on price-changing rules. A 50% drop misfire is unrecoverable.
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Built-in trigger catalog | ✓ | ✓ | ✓ | ✓ | ✓ |
| Custom rules | — | 5 | 50 | unlimited | unlimited |
| Dry-run mode | — | ✓ | ✓ | ✓ | ✓ |
| Approval queues | — | — | — | ✓ | ✓ |
| AI-cost actions | — | — | ✓ | ✓ | ✓ |
| Paid-spend actions (ads) | — | — | ✓ | ✓ | ✓ |
| Multi-step chained rules | — | — | ✓ | ✓ | ✓ |
| External webhook triggers | — | ✓ | ✓ | ✓ | ✓ |
| Custom action SDK | — | — | — | — | ✓ |
See also
- Trigger-action model — how the primitives compose
- Sales engine — many automations read sales-engine state
- Orchestration — for ad-spend automation specifically
Why this exists — the long version
Every successful e-commerce operation has hundreds of small, repeated decisions: tag this customer, send that notification, update stock, refresh a price, post a Slack alert. Doing them manually doesn't scale. Doing them via spreadsheets and "we should automate this" todos that never happen is worse — the work piles up, gets dropped, customers slip through, and the team's energy goes to firefighting instead of strategy.
Automations on this platform are the typed, governable answer to that problem. You define rules that read "when X event happens, do Y action" — using a catalog of pre-built triggers and actions, no code required. The system runs them deterministically, idempotently, and auditably. Dry-run mode lets you preview consequences before anything happens; approval queues add a human gate when stakes are high; the audit trail shows you every fire, every action, every outcome.
The strategic shift this enables: your team stops being the queue. Customers don't wait for someone to tag their order manually; the trigger fires the moment the order arrives. The "we'll get to it" backlog goes to zero, because there's nothing to get to.