For the exhaustive, field-level reference — every action’s config, all strategies,
credentials, interpolation, and the run/step model — see
Workflows (reference).
Triggers
A workflow is triggered by an entity type — product, product variant, brand, or inventory item — optionally filtered by tags (include/exclude).Actions
| Action | What it does |
|---|---|
| Create or get plan | Create (or reuse) a plan — restock, rebalance, markdown, supplier return, or supplier exchange — with its scope and deadline. |
| Add items to plan | Add items to a plan using entity filters, shop/size scope, and a quantity strategy. |
| Call webhook | Send an HTTP request (GET/POST/PUT/PATCH/DELETE) with optional auth, headers, and body. |
| Send email | Send an email (text / HTML / markdown) to recipients. |
Strategies for “add items”
- Quantity: fixed, fill to target, or score-driven (uses decision-vector recommendations).
- Matching (rebalance): fixed or score-driven (matches surplus shops to deficit shops).
- Discount (markdown): fixed, score-driven, or recommended (decision-layer discount with margin floor and caps).
Runs & steps
Each execution is a workflow run (pending → running → completed / failed / cancelled), and each node produces a step record (pending, running, succeeded, failed, skipped, cancelled) with its resolved inputs, output, logs, and retries — so you can see exactly what happened. A workflow itself has a status: draft, active, paused, or archived. Only active workflows execute.Working with workflows
Webhook credentials are stored securely and referenced by the Call-webhook action, so
secrets never live in the workflow definition itself.