Automate your order workflow — from paid to shipped

Automate what happens after an order is paid — stock moves, queue items, notifications — with a visual flow builder, step by step, no code required.

By the end of this guide you will have one automation running in AxisIQ: the moment an order record is created, a flow reads its total, pushes the large ones to an outside service over HTTP, and sets a status field on the rest. No code involved, and the same skeleton — trigger, condition, two branches — covers most of the rules an operations team carries around in its head.

Flows is the workflow builder in AxisIQ: you place typed blocks on a canvas and join them with lines, and that picture is the automation. Because it sits in the same system as your orders, the trigger is the write itself — no export, no five-minute polling cycle.

Budget twenty minutes. If your workspace is new, run through getting started first — you want real orders to test against.

What you need

• An order object type with a total field and a status field. If the AI workspace builder created your order type it will usually have both; if you named things differently, use your own field keys.
• Permission to build flows — grant it deliberately, because a flow acts as the person who built it.
• A URL that will accept a POST from you: your courier's API, a chat webhook, your own endpoint. Anything reachable over https.

Step 1 — Write the rule as one sentence

Write the rule down before opening the canvas. Ours: when an order arrives above 50,000, tell the dispatch channel; otherwise mark it for standard handling.

One "when", one "if", two outcomes maps straight onto blocks. If yours needs three "and then"s, it is probably two flows.

Step 2 — Set the trigger

Create a flow and drop a record event trigger on the canvas. Choose your order type and the event created.

That is the entire trigger, and every block downstream can now read the order that fired it. The other two kinds suit other jobs: a five-field cron schedule, read in UTC, and a manual run you press yourself.

Step 3 — Put the constants in one place

Values that repeat, or that you will change later without hunting through blocks, belong in the flow's context panel — a short list of named constants. Add two:

• threshold = 50000
• notify_url = your webhook address

Everywhere below they read as {{context.threshold}} and {{context.notify_url}}. When the threshold changes at quarter end you edit one field instead of four blocks.

Step 4 — The condition, and its two exits

Add a condition block under the trigger, with a single clause: the order's total, greater than, {{context.threshold}}.

You do not type either side by hand. Every value field has an insert menu listing what exists at that point in the graph: the triggering record's fields, each earlier step's output, and your flow constants. Pick total and it lands as {{trigger.record.total}} with its type intact, so a number stays a number rather than text.

The block has two exits, true and false, and you draw a path from each. Several clauses can share one block, matching all or any of them, with equals, not equals, greater or less than, either of those with or-equal, and contains. There is no expression language past that.

Step 5 — True branch: call the outside world

On the true handle, add an HTTP request block. Method POST, URL {{context.notify_url}}, and a JSON body assembled from the same insert menu: the order number, the total, the customer.

A non-2xx reply is data, not a failure: the block passes on the status, an ok flag, the headers and the body — parsed when it is JSON — so a 429 is something you branch on rather than a run you lose. Calls to private or internal addresses are refused, only http and https are allowed, and a request gives up after ten seconds or a megabyte.

To message a person instead — email, SMS or WhatsApp — use a send message block, which goes out through the provider account your company connects in Phone & Messages.

There is no connector catalogue: you read the service's API documentation once and map the fields yourself. Integrations covers the inbound edge — store connections, public endpoints and API access for services calling in.

Step 6 — False branch: update the record

On the false handle, add an update record block aimed at the record that triggered the flow, and set status to standard. Record actions build their value editors from the target type's own field definitions — a dropdown for a choice or yes/no field, a picker for the field key — so you choose a valid value instead of remembering one. Save. The canvas is now a complete rule.

Step 7 — Run it, then read what happened

Test it by creating a real order above your threshold, then one below. The Run button fires a flow on demand, but a manual run carries no triggering record, so {{trigger.record.…}} comes back empty — it checks your wiring, not your rule.

Then open Runs. Every execution is kept block by block: what went in, what came out, how long it took, the error if it failed — the exact total the condition compared, the exact body the other service sent back.

Flows run in the background. The order is saved and confirmed before the flow starts, so a broken rule can never slow down or reject your team's work. The worst case is a failed run, not an order somebody could not enter.

Working through the order's lines

Three blocks handle lists, and an order's line items are a list. Say you want the total quantity across the bulk lines only.

1. Filter the order's line references down to lines where quantity is above 10. Inside a filter the item's own fields read as {{item.quantity}}, and the output is the kept items plus their count.
2. Reduce what survives to a single value — sum, average, minimum, maximum, count, or the values joined into a string.
3. For each when you need blocks to run per line rather than one number: the body runs once per item, with the item as {{loop.item}} and its position as {{loop.index}}, capped at 500 items and 2,000 steps.

Feed that sum into a condition and you have "hold any order carrying more than 200 units of bulk stock", still without code. All three take any list, including a JSON array an HTTP call returned, which is how you walk another system's response.

Whose permissions a flow uses

A flow acts as the person who owns it. Its author's permissions are read fresh on every run, so narrowing their access narrows the flow with it, and a flow whose author has left the workspace stops rather than carrying on. No block reads a field its author is masked out of, and a function the flow calls is judged against the same identity.

Automation tools commonly run instead on one shared key with full access, making the automation layer the most privileged user in the building. Build a flow as the person whose access matches the job — permissions has the detail.

When the blocks run out

Conditions compare; they do not compute. When a rule needs real logic — a tiered discount table, a checksum, a supplier's awkward date format — add a run function block and write JavaScript. It runs in a sandbox with nothing attached — no network, no filesystem — reaches your data only through the toolkit AxisIQ injects, and answers to the same permissions as every other block. Reach for it late: a canvas your colleague can read at a glance beats clever code nobody will open.

Start from a sentence, not a blank canvas

Describe the workflow in one line — "when an order over 50,000 is created, post it to our dispatch webhook, otherwise set status to standard" — and a proposed graph appears on the canvas. It passes the same structural checks as a hand-built flow, and it stays a draft: the model guesses at object types and field keys, which you correct with the pickers before saving.

A limit to design around

A wait pauses for up to 30 days. A wait block (a delay) or an approval block stops a run and continues it later, so "chase this order if it is still unpaid in three days" can be a wait inside the flow. Waits cannot sit inside a for-each loop.

Runs are guaranteed to happen, not to happen exactly once. A retry can replay an action, so write actions that are safe to repeat: set a status, write a value, update the same record again. Avoid anything that accumulates — incrementing a counter, appending to a list, charging a card — unless the receiving side ignores duplicates.

Where to go next

Read Automation for the full block palette, functions and schedules, and Operations for the records flows act on. Then build a scheduled flow: same canvas, a cron trigger instead of a record event.

FAQ

How do I automate order processing without writing code?

Build a flow: a record-event trigger on your order type, a condition block on the values you care about, then record or HTTP action blocks on its true and false branches. JavaScript is one optional block, never a requirement.

Can a flow run automatically when a new order is created?

Yes — that is the record event trigger, available on created, updated and deleted for any object type. It fires from the write itself, so there is no polling interval and no sync lag.

Can an AxisIQ flow call an external API?

Yes, through the HTTP request block: https, a method you choose, headers and a body assembled from record values. The reply's status and parsed body become values later blocks branch on, and private or internal addresses are refused.

My flow did not do anything — how do I find out why?

Open the Runs tab for that flow, where every block shows its inputs, its output and any error. The two common causes are a condition comparing against a field key that does not exist, and an author whose permissions no longer cover the action.