Automation — visual flows, functions and scheduled triggers

Visual workflow automation: record triggers, schedules, conditions, messages and HTTP calls on a canvas, plus JavaScript when logic outgrows boxes.

Part of AxisIQ's single business model — The automation layer (Run the business). How the layers fit.

Most operations run on rules nobody ever wrote down: check stock before promising a date, flag an invoice unpaid a week after it goes out, open a warehouse task when a large order lands. AxisIQ Flows is where those rules live — a visual workflow builder inside the same system that holds your orders, stock and invoices, so a rule reacts to the change itself instead of polling for it.

A flow is a canvas. You drag typed blocks onto a page and join them with lines, and that picture is the automation — no hidden script underneath, no settings screen holding the real behaviour.

One trigger, then whatever you draw

Every flow begins with exactly one trigger:

• Record event — an object type you choose is created, updated or deleted: a new order, an edited customer, a removed shipment.
• Schedule — a cron expression, read in UTC: every ten minutes, at 6am daily, on the first of the month.
• Manual — a run button, for the process a person starts deliberately.

Branching without writing an if

Decisions are condition blocks. Pick a value, an operator — equals, does not equal, greater than, less than, contains — and what to compare against; several clauses can sit in one block, matching all or any. Each condition has two outputs, true and false, and you draw a different path from each.

The logic layer stops there, deliberately. Anything a comparison cannot express belongs in a function — the one block on the canvas that runs code.

Blocks that do something

• Update a record — set fields on the record that fired the flow, or on one it points at.
• Create a record — draft the purchase order, open the follow-up job, log the adjustment.
• Run a function — hand off to your own JavaScript when the rule is intricate.
• HTTP request — call an external service over https: a courier's tracking API, a supplier's price feed, a webhook another tool listens on.
• Send a message — email, SMS or WhatsApp from a saved template, through the provider account your company connects in Phone & Messages.
• Create a calendar event — book the site visit or delivery slot the record describes.

What the HTTP block gets back is data, not an emergency: the status code and parsed JSON body are there for later blocks, so a 404 from someone else's server is something you branch on. Calls to private or internal addresses are refused, and a call gives up after ten seconds or a megabyte.

Three more blocks work on lists. Filter keeps the items matching your conditions; reduce folds a list into one value (sum, average, minimum, maximum, count, or the values joined); for each runs part of the canvas once per item, up to 500 items. The list can be a reference field of related records or a JSON array an HTTP call returned.

Values travel by reference

Nothing is copied between steps. A block reads {{trigger.record.amount}}, the output of an earlier step, or a constant defined once for the whole flow — change it in one place and it changes everywhere. You never hand-type a reference: every value field has an insert menu of what is available at that point.

A flow can only do what its author can

A flow runs with the permissions of the person who owns it. If they cannot see supplier cost, no block in their flow reads it either — field-level masking applies to the automation exactly as to the person, and any function the flow calls is checked against the same identity.

That identity is read fresh on each run, not frozen at save time: narrow the owner's permissions and the flow narrows with them. The usual alternative — one all-access key behind every integration — is how automation ends up more privileged than any employee. Permissions covers how the rules are written.

Test it before it goes live

Press Test on the canvas and the flow runs on a real record — or values you type in — without doing anything. Conditions and loops run for real; every action shows exactly what it would do: the number a WhatsApp would go to, the words it would say, the fields an update would change. Nothing is sent, nothing changes, and an inserted value that came out empty is flagged before a customer ever sees a blank message.

Every change is kept

Each save that changes what a flow does is stored as a version, with who saved it and when. Open History to see any earlier version on the canvas and restore it in two clicks — and every run records which version it ran, so "it broke after Tuesday's edit" is something you can check, not guess.

Runs stay out of the way

Flows run asynchronously. The save that triggered one is confirmed before the flow starts, so a broken automation cannot slow or reject your team's work — the worst case is a failed flow, not an order somebody could not enter. Every execution is kept, and the Runs view opens one block at a time: what reached it, what it produced, how long it took, the error if it failed.

Scheduled flows survive restarts. The next run time is stored data, not something a running process remembers, and a due run is claimed in one atomic step, so two servers cannot both take it; occurrences missed while nothing was running are backfilled.

Draft one by describing it

Type a sentence — "every Monday at 6am, open a follow-up task for each order unpaid after 30 days" — and get a proposed graph on the canvas. The proposal passes the same structural checks as a hand-built flow, and stays a proposal until you fix the object types and fields the model guessed at.

Functions: the layer underneath

One block runs code you wrote. Functions are JavaScript, and their sandbox starts with nothing attached: no file system, no open network, no environment variables. The one reachable thing is an injected axis toolkit — records, files, PDF rendering, connected stores, work-queue moves, read-only analytics queries — each call judged against the permissions of whoever invoked the function. A throw or a timeout comes back as a result carrying the message, so the surrounding flow branches on the failure instead of dying with it.

Saving a function does not put it live. Changes wait as a draft you can test from the editor, go live only when someone publishes, and every published version is kept — so a bad change is one rollback away, for the public URL and every flow that calls it alike.

Running code on a timetable needs no separate scheduler: a function's own page adds a schedule — hourly, daily, weekdays — and each one is an ordinary flow underneath, with the same run history, versions and run-as rules as any other.

A function can also be given a rate-limited public URL. Nobody is signed in there, so requests are judged against a permission set for unauthenticated callers that you write: leave it empty and the endpoint can compute and nothing more, open one narrow thing and it does that one job — enough for another tool's callback to file into your workspace. See integrations.

Why not a general-purpose automation tool

Automation connectors are better than AxisIQ at one thing: breadth of pre-built connectors. They keep large catalogues of third-party apps and are commonly priced by task volume, and if your work is mostly shuttling data between other people's SaaS products, that catalogue is the product.

Flows is the opposite shape: one generic HTTP block instead of a connector library, so an unusual service means reading its API docs and mapping the fields yourself. In exchange the automation sits inside your data — no polling, no sync lag, no second copy to administer. The longer comparison covers that trade.

One honest limit: runs are guaranteed to happen, not to happen exactly once, so write actions that are safe to repeat.

Where it fits

Flows act on the records you already keep, and pair with Work Queues when physical work moves through stages. Start with one process you repeat weekly — automating an order workflow builds one end to end.

FAQ

Can I build automations in AxisIQ without writing code?

Yes — triggers, conditions, record updates, list handling and external API calls are blocks you drag onto a canvas. JavaScript is there for intricate logic, as one block, never a requirement.

What can a flow connect to outside AxisIQ?

Any service with an https API, through the HTTP request block. The reply's status and JSON body become values later blocks branch on; private and internal addresses are refused.

How is this different from workflow automation bolted on to an ERP?

The trigger is the record itself, so nothing exports data, polls for changes or keeps a second copy. And a flow runs under the permissions of whoever built it, not a standing integration account.

Can a flow send emails or WhatsApp messages?

Yes. The send-message block sends email, SMS or WhatsApp through the provider account your company connects — SES, SendGrid, Twilio, MSG91, Meta's WhatsApp Cloud API and others. WhatsApp messages to customers use templates Meta has approved.

Can someone build a flow that reads data they are not allowed to see?

No. A flow carries its author's permissions, field-level masking included, so it cannot read or change anything they could not by hand — nor can a function it calls.