Workflows

Automate is where pricing policy becomes something you run, not something you remember. A workflow is a decision tree that prices part of your range: it selects a population of products, routes them through business conditions, and emits a price change for each one — consistently, at any scale, with every decision recorded.

Anatomy of a workflow

• Trigger — defines who is in scope: the population of product × location rows the workflow prices. "All live products", "products whose cost changed this week", "everything in Bakery below 20% margin" — any criteria over your products, attributes, sales, and current prices.
• Decisions — route products down different branches. Each decision asks a question ("Is a competitor price available?", "Is this an A-class product?") and sends each product down its true or false branch toward different treatment.
• Actions — the leaves of the tree, where prices are written: set a markup, a fixed price, or an adjustment, per price list. Actions can carry guardrails — "never below cost × 1.25" — applied as part of the action itself.

The example above — the demonstration dataset's Regain market share workflow — targets categories where year-to-date volumes are down more than 10%, asks whether customers are switching to private label and whether competitors have been cutting prices, then either matches the competitor (capped at a 15% minimum margin), runs a three-week 20% promotion on high-margin products, or concludes the issue isn't pricing and leaves prices alone.

Preview, then generate

• Preview computes the population flowing through every node — how many products take each branch, with samples — without writing a single price. Use it to sanity-check scope and branch logic while you build.
• Generate prices runs the workflow for real within your scenario: every product that reaches an action gets its price rule written. Nothing touches Live — the output lands in the scenario like any other draft change, ready for Assess Impact and the Review grid.

The workflow header always shows where you stand: Prices not generated, Generating prices…, Prices generated, or Workflow changed (the graph was edited after the last run, so results are stale). Re-running a workflow in the same scenario replaces its previous output — a workflow's result is always one coherent set.

What a run writes

Every price a workflow writes is attributed to it: the Review grid shows the workflow as Source of Change, the terminal action as Action Executed, and the full decision path per product.

Two precedence guarantees keep automation safe around hand pricing:

• Manual rules win. In a scenario, any hand-set rule owns its product × location × price list scope — workflow runs skip it entirely.
• Family alignment holds. Workflows price family heads; members are aligned to the head's price automatically.

Building and running

Workflows are created on the Automate page — from scratch on the canvas, by duplicating an existing workflow, or by describing one in plain language. The canvas handles layout automatically, autosaves as you edit, and each node's logic can be written for you from a description — see Generate from a prompt.

Workflows run when you run them — they are repeatable, not scheduled. The operating rhythm is: costs or market data land → run the workflow in a fresh scenario → assess impact → review → publish.

One policy per workflow

Keep each workflow answerable in one sentence — "maintain tier laddering", "match competitor on KVIs", "protect margin floor after cost increases". Small, named policies compose better than one monolith, and the Review grid's attribution stays meaningful.