Operate asynchronous workflows
26R1 reference · Documentation-based tutorial draft · Not executed in IFS
Workflow learning center · Explore this pattern interactively
What asynchronous timing means
Section titled “What asynchronous timing means”Asynchronous timing is for Process Enrichment. The originating transaction records the intent to run work; execution happens later in a separate transaction. Completion order is not guaranteed.
Use it when the business operation can finish before the follow-up work completes. Do not use it for validation that must reject the originating transaction, or for a workflow that reaches a User Task through any cascade.
Design for delayed and repeated execution
Section titled “Design for delayed and repeated execution”Inputs can be older than the current business record by the time the job runs. Decide which captured values remain authoritative and which data must be re-read.
If execution is retried, repeating the same write or external request must not create duplicate business effects. Store or use a meaningful business correlation identifier where the target supports it. A workflow job ID and a business duplicate-prevention key solve different problems.
Find the job
Section titled “Find the job”Navigate to Solution Manager → Workflow Manager → Asynchronous Workflow Executions with the required administrator or workflow-author access.
| State or field | Interpretation |
|---|---|
| Created | Posted and waiting for execution |
| IP | In progress or waiting within the retry lifecycle |
| Done | Execution completed successfully |
| Failed | Execution exhausted its unsuccessful attempt lifecycle |
| Recent Error Log | Most recent recorded error |
| Workflow Error History | Details of failed attempts |
| Version Check Review Status | Whether a version mismatch needs review |
Do not treat a request trace marked POSTED as proof of completion. Check the execution record and business result.
The reference describes three attempt counts and 15-minute retry spacing. Treat the installed execution history as authoritative for an individual job; avoid adding blind retries on top of the platform’s retry lifecycle.
Review version changes
Section titled “Review version changes”When ALLOW_EXECUTE_ASYNC_JOBS_FROM_PREVIOUS_VERSION is false, jobs posted against a different version can be stopped for review. Inspect the new workflow’s input contract and behavior before approving them for execution.
A deployment plan must account for queued work. Changing the active version while a backlog exists is a behavior change, not just replacing a diagram.
Rerun after diagnosis
Section titled “Rerun after diagnosis”The 26R1 execution page documents a single manual rerun of a failed job, selected individually. Before using it:
- Capture the error history and business record identity.
- Fix the cause and review any version difference.
- Check for earlier external or autonomous side effects.
- Confirm repeating the operation is safe.
- Use the supported Rerun Failed Workflow action and inspect the result.
Do not reset workflow tables manually to bypass the rerun lifecycle.
Tune with measurements
Section titled “Tune with measurements”Thread count, read batch size, delay, timeouts, and pod heartbeat parameters affect throughput and resources. Measure queue age, failure rate, execution duration, and system load before changing them.
More threads can increase contention. A bigger batch or longer timeout can increase pressure without fixing an inefficient model. Capture the current settings and a rollback plan for any tuning change.