Adhoc Sub Processes

Adhoc Sub Processes

An Adhoc Sub Process is a BPMN subprocess used when the work inside the subprocess cannot be fully sequenced in advance.

Editions: Adhoc Sub Processes are available only in the Flows for APEX Enterprise Edition.

Instead of defining one fixed path through the subprocess, you define a controlled workspace containing a set of possible activities. During runtime, available activities can be started in an order chosen either by a human knowledge worker or, in the Enterprise Edition, by an AI-driven controller. Not all activities have to be started to complete the subprocess, and some activities may happen more than once.

This makes an Adhoc Sub Process suitable for investigative, case-management, and knowledge-work scenarios where the process needs structure and auditability, but not a rigid predefined sequence.

Adhoc Sub Processes are often abbreviated to AHSP in Flows for APEX documentation.

What Problem Does an AHSP Solve?

Use an Adhoc Sub Process when you know:

• which activities may be needed
• what data those activities need and return
• what conditions make an activity startable
• what condition means the subprocess is finished

but you do not know the exact order in which those activities will need to be performed.

Typical examples include:

• case investigation
• exception handling
• triage and recovery workflows
• dynamic service orchestration
• AI-guided exploration of possible next actions

AHSPs and Normal Sub Processes

An Adhoc Sub Process is not just a normal subprocess with more optional paths.

An Adhoc Sub Process is designated with the adhoc marker .

Normal Sub Process

A normal subprocess defines its control flow explicitly in BPMN sequence flow.

• the next step is determined by the model
• gateways choose between paths
• the runtime follows the designed route

See Sub Processes for the standard subprocess model.

Adhoc Sub Process

An Adhoc Sub Process defines a set of possible activities and the rules for when the subprocess is complete.

• the runtime maintains a set of currently startable activities
• activities can be performed in different orders in different cases
• the subprocess remains active until its completion condition is met

The AHSP therefore behaves more like a controlled work area inside the process than a fixed mini-process.

Note that the activities in an AHSP no not have start events befre them or end events after them inside the AHSP.

Two Operating Modes Built on One Base

The BPMN object is always an Adhoc Sub Process. Flows for APEX then supports different operating styles on top of that same base model.

Manual AHSP

In a manual AHSP, a human user or knowledge worker decides which currently startable activity to perform next.

This manual operating style is also an Enterprise Edition feature because it depends on the Adhoc Sub Process runtime.

• the system shows what can be started now
• the user chooses the next activity
• the subprocess continues until the completion condition is met

See Using Manual Adhoc Sub Processes.

AI-Driven AHSP (EE Only)

In the Enterprise Edition, the same AHSP can be run in an AI-assisted or autonomous control mode.

• the AI evaluates the current situation
• it recommends or selects currently startable activities
• it continues until the completion condition is met or control is returned to a human

This is not a different BPMN object. It is an Enterprise Edition operating mode for the same AHSP model.

See AI-Driven Adhoc Sub Processes.

Modeling an Adhoc Sub Process

When you model an AHSP, you are defining four things:

1. the Adhoc Sub Process container
2. the activities that may run inside it
3. the rules that determine which activities are currently startable
4. the completion condition that determines when the AHSP is finished

1. Define the AHSP Container

The Adhoc Sub Process is modeled as a subprocess object in BPMN, but it is configured to use adhoc behavior rather than normal sequence-flow-driven behavior.

As with normal subprocesses, it can be used to encapsulate a bounded area of work inside a larger process.

2. Define the Activities Inside the AHSP

Inside the AHSP, you define the activities that may be started while the subprocess is active.

For each activity, you should think in terms of a task contract:

• what the activity does
• when it can be started
• whether it can be repeated
• what inputs it needs
• what outputs and summary information it produces

3. Define the Starting Activities

An AHSP can have an initial set of activities that are be started when the subprocess first becomes active.

These starting activities establish the initial work choices available to the knowledge worker or AI controller.

After each activity completes, the set of currently startable activities may change.

4. Define the Completion Condition

An AHSP finishes when its completion condition evaluates to true.

The completion condition is fundamental to the design of an AHSP because it answers the question:

“How do we know that enough work has been done?”

The condition is typically based on process state, activity results, or accumulated outputs rather than on every possible activity being completed.

Task Parameters and AHSP Activities

Task Parameters are a core part of AHSP design.

In practice, an AHSP works best when each activity has a clear input and output contract.

• input parameters define what the activity needs
• output parameters define what the activity returns
• summary output such as result and mainOutputs helps the runtime present the current situation clearly

For task-parameter details, see Task Parameters.

For PL/SQL task behavior in an AHSP, see Configure a PL/SQL Script Task.

What Else Needs to Be Designed?

To build a good AHSP, you usually need to design more than the container itself.

You should also define:

• activity start conditions
• repeatability rules
• activity descriptions and grouping
• display order for user-facing selection lists
• completed activity summary output
• the current situation view presented to users or AI control

These runtime ideas are documented in Adhoc Sub Process Concepts.

When to Use AHSPs

AHSPs are a good fit when:

• multiple different actions may be valid at a given point in time
• the next step depends on expert judgment or evolving evidence
• the process needs auditability and control, but not rigid sequencing
• you want the same work area to support both manual and AI-driven execution styles

AHSPs are usually not the right choice when the process can already be expressed clearly using normal BPMN sequence flow, gateways, and events.

Related Topics

• Sub Processes
• Adhoc Sub Process Concepts
• Using Manual Adhoc Sub Processes
• AI-Driven Adhoc Sub Processes
• Task Parameters