Workflow Builder (Automation)

Paid pluginsize Lplanned, not built

Indicative price, not an offer: €39/mo; 50 workflows included, condition builder, webhook support

Generated from docs/plan/paid/workflow-builder/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants need to automate business processes without coding: when order > €500, alert warehouse and finance; when product is low-stock, reorder. This feature provides a visual workflow builder with conditions, actions, and webhooks.

The problem

I have manual processes: when a large order comes in, I email the warehouse and finance team manually. There’s no way to automate this without writing code.

What it does

• Workflow entity: name, trigger (e.g., ‘order created’, ‘inventory low’), condition (e.g., ‘amount > 50000 cents’), actions (email, webhook, update entity)
• Triggers: order.created, order.updated, product.stock_changed, customer.created, custom webhook (for external integrations)
• Conditions: value comparison (amount > X, stock < Y), string match, date range, entity property
• Actions: send email, call webhook (POST JSON to URL), update field (set product status, order tag), create task, send notification
• Workflow builder UI: drag-and-drop or form-based condition/action builder, preview of what will execute, enable/disable toggle
• Execution log: track each run of the workflow, show which actions succeeded/failed, timestamp, input/output data
• Rate limiting: limit action execution per workflow per minute (prevent email spam from runaway workflow)
• Testing: dry-run workflow against sample event to verify logic before enabling
• API endpoints: CRUD workflows, trigger workflow manually, execution history

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Multi-step approval workflows — workflow cannot pause and wait for human approval; all steps are automatic
• Custom JavaScript actions — workflow actions are predefined (email, webhook, field update); no arbitrary code execution
• Workflow scheduling (e.g., ‘run every Monday’) — that is scheduled-tasks; workflow is event-triggered only
• Workflow branching with complex logic (if/else trees) — conditions are AND/OR only, not nested branches
• External system bidirectional sync — workflow can CALL external APIs but does not subscribe to their events; polling is scheduled-tasks

Data model

New entity: Workflow {id, name, trigger_type, enabled, condition (JSON), actions (JSON array), created_at, updated_at}. New entity: WorkflowExecution {id, workflow_id, triggered_by_event_type, event_data (JSON), execution_status (success/partial/failed), executed_at}. New entity: WorkflowAction Result {id, execution_id, action_index, action_type, status, result_data (JSON), error_message (nullable)}. Schema migration across all three drivers.

API

• POST /api/workflows — create workflow (admin only)
• GET /api/workflows — list workflows
• GET /api/workflows/:id — fetch workflow detail
• PATCH /api/workflows/:id — update workflow (admin only)
• DELETE /api/workflows/:id — delete workflow (admin only)
• POST /api/workflows/:id/test — dry-run workflow with sample event
• PATCH /api/workflows/:id/enable — enable/disable workflow
• GET /api/workflows/:id/executions — execution history (paginated)
• GET /api/workflows/:id/executions/:execution_id — detailed execution log

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Workflow builder: list of workflows with enable/disable toggle. Create/edit workflow form: name, select trigger type (dropdown), condition builder (visual or form-based: property, operator, value), action builder (add/remove actions, each with type-specific params). Preview panel shows sample event and resulting actions. Test tab: dry-run with sample event, show which actions would execute. Execution log: table of runs with status, timestamp, expand to see action details and errors.

The seam — why this is paid

Core owns the workflow model, condition evaluation, action dispatch, and REST API. Paid layer owns external integrations (Zapier/Make-like hosted platform for non-technical users), advanced conditions (regex, date math), multi-step approval workflows, and SLA guarantees (99.5% execution reliability, audit trail for compliance).

Support commitment: workflow logic verification, reliability SLA (99.5%)

Dependencies

• Webhook system (already shipping in core; workflows are a different way to trigger webhooks)
• Email system (already shipping in core) for action execution
• Event system (core must emit events when orders/products change, for workflow subscription)
• Scheduler or event listener (core must detect when a workflow trigger fires)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A workflow can be created with a trigger (‘order.created’), condition (‘amount > 50000’), and action (‘send email to warehouse@…’)
• When an order > €500 is created, the workflow is triggered and the email action executes
• An action that fails (e.g., email service down) is logged with error; the workflow is marked ‘partial’ and can be retried manually
• A workflow can be disabled; disabling prevents it from triggering on new events
• A workflow can be tested with sample event data; test mode shows which actions would execute without side effects
• An execution log for a workflow shows all runs, status, and any errors (e.g., ‘email failed: recipient not found’)
• If a workflow action runs more than 10 times in 1 minute, subsequent runs are queued (rate limit prevents spam)

Risks

Runaway workflows can spam customers (wrong recipient, looping email rules) or make repeated API calls (webhook hammer). Rate limiting is mandatory. Condition evaluation must be fast; slow queries (full table scan in condition check) will block event processing. Webhook failures are silent unless logged; execution log must always record success/failure. If external webhook is down, workflow may queue indefinitely; timeout + fallback behavior (e.g., send email to admin instead) is needed. Workflow logic can conflict (two workflows both trying to update the same field) — document that last-write-wins.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.