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.

What Problem Does an Adhoc Sub Process 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

Adhoc Sub Processes 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 adhoc sub process therefore behaves more like a controlled work area inside the process than a fixed mini-process.

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

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 Adhoc Sub Process

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

  • the system shows what can be started now
  • the user chooses the next activity - so the order of activities is determined by the user
  • not all activities need to be completed - the subprocess continues until the completion condition is met
  • sometimes an activity can be followed by a short sequence of activities connected by sequence flow
  • an activity can be defined to be executed only once or can be repeatable

See Using Manual Adhoc Sub Processes.

AI-Driven Adhoc Sub Process

The same Adhoc Sub Process 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 Adhoc Sub Process model.

See AI-Driven Adhoc Sub Processes.

Modeling an Adhoc Sub Process

When you model an Adhoc Sub Process, 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 Adhoc Sub Process is finished

1. Define the Adhoc Sub Process 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 Adhoc Sub Process

Inside the Adhoc Sub Process, 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 Adhoc Sub Process 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. The starting activities can be set as a static list (i.e., the sub process will always start those activities), or this can be dynamic - based on a query, expression, or a process variable set in an earlier process step.

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

4. Define the Completion Condition

An Adhoc Sub Process finishes when its completion condition evaluates to true.

The completion condition is fundamental to the design of an Adhoc Sub Process 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 Adhoc Sub Process Activities

Task Parameters are a core part of Adhoc Sub Process design.

In practice, an Adhoc Sub Process 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 Adhoc Sub Process, see Configure a PL/SQL Script Task.

What Else Needs to Be Designed?

To build a good Adhoc Sub Process, 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 Adhoc Sub Processs

Adhoc Sub Processs 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

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

Updated: