Automation
Workflows: on save or scheduler?
In short
- On-save flows run in the saving request — relationships are often not ready yet.
- Scheduler flows decouple UI and work but need cron, observation and idempotency.
- Wrong modelling shows up as empty emails, hanging requests or duplicate actions.
Workflow failures are often timing assumptions, not “the engine is broken”. Use the tools below to choose a trigger type and validate before production.
Interactive check
Which workflow type fits your case?
Recommendation: on-save workflow
Suitable for calculations or status changes on the same record without dependent relationships.
Card A · Synchronous
On-save lifecycle
- 1 User clicks Save
- 2 HTTP request runs — browser waits
- 3 Validation & before-save hooks
- 4 Database write
- 5 On-save workflow (mail, webhooks, more writes)
- 6 Response to browser
Risk: External latency and heavy chains lengthen the request; related records may still be incomplete.
Card B · Asynchronous
Scheduler lifecycle
- 1 User saves — response stays snappy
- 2 UI usable again
- 3 Later: cron/worker
- 4 Job reads current DB state
- 5 Batch actions without UI blocking
- 6 Idempotency / status flag
Requires: reliable cron, observed jobs, flows that tolerate re-runs.
Trap 1
Subpanel illusion
Main record ID may exist while related rows are not readable yet. On-save mail to “contact on quote” often fails for that reason.
Trap 2
Save loop
Workflow changes a field → save again → workflow again until timeout. Use explicit processed flags.
Trap 3
Unbounded “all records”
Scheduler flows without tight filters eventually scan huge historic sets every run.
Staging checklist
0–2 checked: risky blind flight — do not deploy yet.
The Workflow Engine in SuiteUltimate emphasises visual modelling, simulation and versioned release. Trigger choice remains an architecture decision.
Workflow Engine ↗