Adhoc Sub Process Concepts
Adhoc Sub Process Concepts
This page explains the shared runtime concepts behind Adhoc Sub Processes.
Editions: Adhoc Sub Processes, including both manual and AI-driven operation, are available only in the Flows for APEX Enterprise Edition.
These concepts apply whether the Adhoc Sub Process is being controlled manually by a knowledge worker or, in Enterprise Edition, by an AI-driven controller operating in recommendation, hybrid, or autonomous mode.
Runtime Mental Model
An Adhoc Sub Process is a bounded work area inside a process instance.
At runtime, it maintains:
- a set of activities that are currently startable
- a history of activities that have already been completed
- a current situation built from process state and completed activity results
- a completion condition that decides when the Adhoc Sub Process can finish
The AHSP remains active until the completion condition becomes true.
Currently Startable Activities
The most important Adhoc Sub Process concept is the set of currently startable activities.
These are the activities that the runtime says may be started now.
The set is dynamic. It can change as the subprocess progresses because:
- process variables change
- previous activities produce outputs
- start conditions become true or false
- repeatability rules allow or prevent another execution
In a manual AHSP, the user chooses from the currently startable set.
In an AI-driven Adhoc Sub Process, the AI works from that same currently startable set. In recommendation mode it proposes activities for human approval; in hybrid or autonomous mode it may also select and dispatch activities directly, depending on the configured control mode and guardrails.
Starting Activities
When the AHSP first becomes active, it needs an initial set of available activities.
These starting activities define the initial work choices available inside the AHSP.
They are important because they establish how the subprocess begins without requiring a fixed internal sequence flow.
Conditional Activities
In many AHSPs, an activity is not always available.
Instead, it becomes startable only when its start condition is satisfied.
This allows the model to express rules such as:
- only start this activity when sufficient evidence exists
- only allow this activity after another result has been recorded
- only allow this activity while the case is still unresolved
Start conditions are part of what makes the AHSP controlled rather than arbitrary.
Repeatable and One-Time Activities
Some AHSP activities should be performed at most once.
Others may, optionally, need to be repeated several times as the case evolves.
Repeatability is therefore part of the runtime contract of an activity.
- one-time activities disappear from the currently startable set once completed
- repeatable activities may become startable again later, depending on their rules and current state
Completed Activity Summary
Each completed activity should leave behind a usable summary of what it achieved.
This is important for both human and AI-driven control because future activity choice depends on understanding what has already happened.
In practice, a completed activity summary should make it easy to answer:
- what activity was performed
- what result it produced
- what the key outputs were
- whether the situation improved, worsened, or remains unresolved
For AHSP task design, concise activity outputs such as result and mainOutputs are especially useful because they help the runtime construct a readable current situation.
Current Situation
The current situation is the synthesized picture of where the AHSP stands now.
It is not just a list of completed activities. It is the runtime’s current understanding of the case or work item based on:
- process variables
- completed activity summaries
- key outputs returned by activities
- any unresolved questions or remaining work
The current situation is useful because it gives the user or AI controller the context needed to choose the next best activity.
Completion Condition
The completion condition answers the question:
“When is the AHSP done?”
An AHSP does not normally finish because every possible activity has been executed.
Instead, it finishes when enough has been done to satisfy the subprocess goal.
Typical completion conditions might reflect:
- a case status reaching a resolved state
- a required fact being established
- a successful outcome being produced
- a decision or recovery path being completed
The completion condition should be explicit and testable. If it is vague, both manual and AI-driven AHSPs become hard to operate predictably.
Relationship to Subflows and Process State
An AHSP still exists inside the normal Flows for APEX process runtime.
It is not an isolated mini-application. It still interacts with:
- the parent process instance
- process variables
- subflow state
- normal task execution and logging
That means AHSP activities should be designed with the same discipline as other process activities, especially around inputs, outputs, and error handling.
See Understanding the Subflow Architecture for background on the runtime model used by Flows for APEX.
Why These Concepts Matter
If these concepts are designed well, an AHSP feels controlled and understandable.
If they are designed poorly, an AHSP feels like a bag of disconnected tasks.
Good AHSP design therefore depends on:
- a clear initial activity set
- well-defined start conditions
- explicit repeatability rules
- high-quality activity summaries
- a precise completion condition