Control gateways, loops, and cascading workflows
26R1 reference · Documentation-based tutorial draft · Not executed in IFS
Make each branch explicit
Section titled “Make each branch explicit”An exclusive gateway selects one outgoing path. Give each conditional path a clear condition and add an intentional default where appropriate. Test that default with unexpected or missing input.
An inclusive gateway can choose multiple qualifying paths. A parallel gateway represents multiple branches, but it is not a promise of parallel CPU execution: without asynchronous boundaries the documented execution remains synchronous within one thread and transaction.
Do not add async boundaries merely to improve speed. Workflow configuration and command validations restrict supported asynchronous BPMN behavior.
Loop over a small collection
Section titled “Loop over a small collection”The documented sequential multi-instance pattern uses a subprocess.
- Read a filtered, bounded collection into a named variable.
- Add a subprocess and configure sequential multi-instance behavior.
- Set the collection and per-item variable using the actual designer fields.
- Inside the subprocess, map the current item’s identity explicitly.
- Keep per-item results and errors distinguishable.
- Inspect zero, one, and several items before testing realistic volume.
For a fictional collection relatedRows, an item alias such as currentRow helps distinguish one record from the entire result. These are design names, not a complete importable configuration.
Decide whether one failed item should fail the whole transaction or produce an explicitly handled result. Turning on Log Errors without checking it silently changes that policy.
Avoid accidental recursion
Section titled “Avoid accidental recursion”An API task can call a projection that has another workflow reaction. That workflow can invoke further APIs and events.
Workflow A -> update target -> reaction B -> update original -> reaction A againBefore enabling a reaction, map every write and its configured downstream triggers. Reduce the trigger scope, use meaningful change conditions, and make repeated processing safe. A script flag alone does not necessarily survive a new asynchronous transaction.
Trace the actual request: one click may legitimately cause multiple workflow runs. Distinguish expected cascades from duplicate registrations.
Establish a performance budget
Section titled “Establish a performance budget”Record expected items per run, calls per item, concurrent initiating requests, and maximum acceptable response time.
For example, 40 records with three calls per record already require 120 task calls before cascades. A test using one record cannot establish production performance.
Use narrow reads, minimal selected fields, and small response payloads. Move high-volume or long-running work to an architecture designed for it. Increasing a timeout does not remove excessive iteration or memory usage.
Acceptance evidence: all branches terminate, empty collections finish, each item maps to the right record, repeated triggers remain safe, and realistic volume completes within the agreed budget.