Understand IFS Cloud workflows

26R1 reference · Documentation-based tutorial draft · Not executed in IFS

What you will learn

Decide whether a requirement fits IFS Business Process Automation, choose a workflow type, and explain which changes a failure can actually undo.

Here, workflow means IFS Cloud Business Process Automation (BPA), authored in Workflow Designer and executed through the workflow engine. An approval process elsewhere in IFS or an IFS Connect routing flow is not automatically the same feature.

Choose a suitable requirement

Good starting cases are a small validation, a short form asking for missing information, and a bounded update using supported APIs. Bulk migrations and long-running processing are poor starting points. Estimate both records per run and concurrent triggers.

Use this fictional requirement throughout the guide: an order handover must contain an external reference. Names such as ExternalReference are teaching aliases, not promised fields in your installation.

Need	Workflow type	Example
Stop an invalid operation	Validation	Reject a missing reference
Ask the current user for input	User Interaction	Capture a handover note
Read, create, or update supporting information	Process Enrichment	Supply a permitted default or update a related record

A User Task is not a general approval inbox for assigning work to another user or role. Do not promise manager approval routing from this feature alone.

Timing is part of the design

Trigger	Validation	Process Enrichment	User Interaction
Projection action	Before or After	Before, After, or Asynchronous	After
Event action	After	After or Asynchronous	Unsupported
Workflow command	Validate command eligibility separately	Validate command eligibility separately	Supported subject to command validations

After does not generally mean after commit. Synchronous validation and enrichment normally share the initiating transaction. An explicit commit in the initiating API changes what a later failure can undo.

Asynchronous processing records work for later execution in a separate transaction. It cannot reject the already completed original operation.

Draw the transaction boundaries

Synchronous: request -> workflow + business operation -> commit or rollback
Asynchronous: request + queue intent -> commit | later workflow transaction
User form: work before form -> commit | form | subsequent work
REST call: workflow transaction | separate HTTP operation in target system

The boundaries explain why a later failure does not necessarily erase every earlier effect. See user forms, REST calls, and asynchronous operations before relying on rollback.

Design checkpoint

Write down the trigger, type, timing, expected volume, acting user, side effects, and failure outcome in the design worksheet.

Exercise: a workflow sends an external notification and then fails validation. Should the recipient expect the notification to disappear?

Answer: no. The external call is outside the workflow database transaction. Prefer validating before sending and define duplicate handling or compensation for external effects.