Workflows

Visual workflow automation across your systems, triggered by schedules, HTTP calls, webhooks or data changes, with every run logged.

Act on your data, not just move it

Synchronising data between systems is half the job. The other half is acting on what the data says. Workflows let STRAX respond to events: a new order arrives, so a provisioning task is created; an invoice becomes overdue, so an account manager is alerted; a support ticket closes, so the customer receives a follow-up. A workflow is built visually on a canvas, as steps connected into a flow, and reads well enough that a colleague can follow what it does.

Started by the events that matter

A workflow can be started in several ways.

On a schedule, from a simple recurrence or a precise cron expression, with the time zone stated explicitly.
By an incoming HTTP call, so an external system or a webhook from a product such as Shopify or HubSpot can start it directly.
By a data change, firing when a record in the hub is created or updated.
Manually, or from another workflow, which suits occasional processes and reusable sub-processes.

Demo ISP uses all four. A nightly schedule produces the operations summary, a Shopify webhook starts order handling the moment an order is placed, and a change to a customer's service status starts the notification flow.

Steps that reach everything

Workflow steps cover the actions an integration process needs. A workflow can call an external REST API with proper authentication, run a saved query, generate a branded PDF report mid-process, transform and reshape data, send e-mail, post chat messages and notify portal users. A step can also put a question to a language model, which suits tasks such as classifying an inbound request or drafting a customer message for review.

Flow control is part of the same canvas. Workflows branch on conditions, run branches in parallel, loop over collections, pause, and call other workflows as sub-processes. Values pass from step to step, so the output of an API call can drive the condition that follows it.

A workflow on the design canvas: a send-email process with a success path, an error path, and validation confirming the flow is sound.

Failures are handled, not hidden

Every step declares what happens when it fails: stop, retry, or continue down a dedicated error path. An error path can send an alert, record the failure or take a compensating action, so a broken process announces itself instead of stopping silently. Retries deal with transient problems such as a briefly unavailable API.

Every run is logged and repeatable

Each execution is recorded: which steps ran, in what order, what each produced and where the run ended. When someone asks why a customer was e-mailed twice, the answer is in the run history rather than in guesswork. A workflow can be run again with the same inputs, which makes testing and recovery straightforward. Monitoring shows failures and throughput across all workflows in one view.

Workflows move between staging and production with the rest of your configuration, and export to a portable definition, so a proven process can be promoted, shared or shipped as part of a marketplace package.

Where this fits

Workflows sit alongside the synchronisation described in Connecting systems, and they surface to end users through portals, where a button on a page can start one. The AI copilot can propose workflow changes for your review. For the broader picture, start with What is STRAX? or see Getting started.