What starts a workflow
Every workflow has exactly one Trigger step, and it works one of two ways. The “Trigger type” toggle picks between “Event” and “Schedule”; choosing one clears the other. Events. An event is a specific change to a specific record:
Business moments. Below the per-record events, the picker has one group headed “Business moments”: the nine points in Alforse’s own flows where something meaningful finished: a job released or put on hold, a job operation completed, a quote sent or accepted, a receipt or shipment posted, a sales or purchase invoice posted. A hands your workflow the identity of each record, not a copy of its fields; add a Find step when you need to read something the moment didn’t name.
Schedules. In “Schedule” mode you pick a “Frequency” of Daily, Weekly, or Monthly, the days it applies to, a “Time of day”, and a “Timezone”; the builder shows a live “Next fires at:” line as you change it.
“Triggered by”. Event triggers also choose who caused the change: “People”, “Workflows”, or “Both”. A new trigger starts at “People”, which is the safe answer: it stops a workflow from reacting to edits made by workflows, including its own. Switch it to “Both” deliberately, when you want one automation to feed another.
The steps you can add
Six kinds, in palette order:
Actions come in three families. Four create records (a job, an issue, a purchase order, or a sales order), each through the same service Alforse’s own screens use, so sequences, defaults, and required fields behave identically. Ten update an existing record, one per watched record type. The last two are “Notify someone” and “Call an outside URL”.
Filling in a step
Most fields take either a value you type or a value from an earlier step. Type{ in a text field and a menu opens listing the steps above this one, their outputs, and up to two levels of properties. Only steps guaranteed to have run before this one are offered — a value from the other side of a condition is not on the menu, and referring to one is rejected at publish.
Repeating steps. Connecting a list to a single-value field runs the step once per item, up to 100 items. The form displays this behavior. Connecting two lists to one step causes a publish-time error because the loop source is ambiguous.
Calling an outside URL
The “Call an outside URL” action sends an HTTP request, a , so another system can react to something in Alforse.Saving, publishing, and versions
There is no Save button: the builder saves as you work and reports “Saving…”, “Saved”, or “Could not save” next to the title. A half-finished draft saves happily; nothing is checked until you publish. “Publish” is all-or-nothing. Alforse validates the whole workflow — a trigger exists, no step loops back, every required field is filled, every variable resolves and comes from upstream — and if anything is wrong, nothing is written; the problems appear in a panel and clicking one pans the canvas to the offending step. Publishing is also the only on/off switch: whichever version you publish is the one that runs, and “Unpublish” stops the workflow entirely. Nothing is deleted, so publishing again starts it back up. A workflow with nothing published reads as Draft. Publishing freezes that version. To keep working, use the version menu to create a new version, which copies the published one and numbers it one higher. A run already in flight keeps using the version it started with even if you publish another mid-run. The trigger card also has a “Test run” button (owner only): it executes for real, but the result is never written to run history.Who can do what
Workflows have their own permission module: View opens the list, builder, and run history; Create adds workflows and versions; Update edits, publishes, and test-runs; Delete removes a workflow with its versions and history. Every route also requires an employee account.Runs and history
Every firing is recorded as a : one row for the run and one per step, with the values in, the values out, and why it ended the way it did. Open Automate → Runs for the list: status, workflow, trigger, the record it started from (shown by its name or number, and linked so you can open it), duration, owner, and a Chain cell reading “Hop 2” when the run was caused by another run. Rows update live while anything is queued or running.[REDACTED] and every webhook header value is masked, while ordinary fields that merely sound sensitive (an item key, who authorised something) are left alone: a debugging tool that hides too much is as broken as one that hides too little.