Workflows: on save or scheduler?
- On Save flows run within the saving request; relationships and subsequent objects often have not yet been established.
- Scheduler flows decouple UI and work but need cron, observation and idempotency.
- Incorrect modelling shows up as empty emails, hanging requests or duplicate actions, rather than as an abstract theoretical error.
Workflows in SuiteCRM (historically Advanced Open Workflow) allow conditional actions at module level. In practice, failures are less often caused by the engine than by incorrect assumptions about timing, specifically when data is complete and relationships have been established. This article makes the architecture decision concrete through decision guidance, a lifecycle comparison and a test checklist.
Which workflow type fits your case?
Two questions, one recommendation. It does not replace staging tests, but helps avoid the most common wrong decision.
Suitable for calculations or status changes on the same record, without dependent relationships or noticeable waiting time.
1. Two lifecycles — synchronous versus asynchronous
Rather than abstract definitions, consider the sequence users and the system actually experience:
On-save lifecycle
- 1 User clicks Save
- 2 HTTP request runs — browser waits
- 3 Validation & before-save hooks
- 4 Database write (INSERT/UPDATE)
- 5 On-save workflow (mail, webhooks, more writes)
- 6 Response to browser
Scheduler lifecycle
- 1 User saves — response stays snappy
- 2 UI usable again
- 3 Later: cron/worker
- 4 Job reads the current database state (relationships usually exist by then)
- 5 Batch actions without UI blocking
- 6 Idempotency / status flag
2. Decision guidance at a glance
| Design question | Favour On Save | Favour Scheduler |
|---|---|---|
| Is the related record created only after saving? | unfavourable | suitable |
| Does the user need an immediately visible field or feedback? | suitable | delayed |
| External API with noticeable latency? | risky within the request | better |
| Large volumes / overnight runs? | unsuitable | schedule with filters |
3. Three architectural traps
Subpanel illusion
The main record's ID may already exist during saving while linked records (subpanel relationships) are written later in the transaction or afterwards. An On Save flow expecting a contact on the quote then finds nothing, even though the user has just set the relationship in the UI. Countermeasure: Use the scheduler or a deliberate second step once the relationship is guaranteed to be readable.
The recursive infinite loop
A workflow changes a field → triggers another save → the workflow runs again → until timeout or the memory limit. This is particularly insidious when the condition and write target concern the same field. Countermeasure: Use an explicit processing flag, formulate conditions so a second run does nothing, and avoid unnecessary saves in the chain.
The uncontrolled scheduler run
After years of operation, a scheduler flow without narrow date/status filters can touch enormous historical volumes on every cron run. The system appears “suddenly slow” even though the flow has “always worked this way”. Countermeasure: Use narrow selection criteria and an “already processed” status; observe runtime and load.
4. Deployment readiness: a test record to tick off
Deploying to production without these five checks means operating blindly, regardless of the chosen trigger type.
Staging checklist
The Workflow Engine in AgenticUltimate uses visual modelling, simulation and versioned approval so flows do not enter production unseen. Choosing On Save or Scheduler remains an architectural decision; simulation replaces none of the five checks above.
Workflow Engine ↗5. Limits of this article
No guarantee applies to every SuiteCRM patch level or custom-hook landscape. These recommendations are architectural heuristics drawn from common failure patterns; staging tests on your instance remain decisive.