What causes "Flowable 5 process definitions are not supported" in flowable/flowable-engine?

Redeploy the process definition with the Flowable 6 BPMN converter (flowable.process-definition-location / v5 conversion) so new instances run on V6 internals.

flowable/flowable-engine · error · FlowableException

Flowable 5 process definitions are not supported

Error message

Flowable 5 process definitions are not supported

What it means

FlowableException thrown in AddMultiInstanceExecutionCmd.execute when the process definition the MI execution belongs to is a Flowable 5 process definition. The dynamic add-multi-instance-execution feature is implemented only for the Flowable 6 engine internals; V5 compatibility processes are routed to the Flowable5CompatibilityHandler for identity links but not supported for this command, so it fails fast.

Source

Thrown at modules/flowable-engine/src/main/java/org/flowable/engine/impl/cmd/AddMultiInstanceExecutionCmd.java:62

    public AddMultiInstanceExecutionCmd(String activityId, String parentExecutionId, Map<String, Object> executionVariables) {
        this.activityId = activityId;
        this.parentExecutionId = parentExecutionId;
        this.executionVariables = executionVariables;
    }

    @Override
    public Execution execute(CommandContext commandContext) {
        ExecutionEntityManager executionEntityManager = CommandContextUtil.getExecutionEntityManager();
        
        ExecutionEntity miExecution = searchForMultiInstanceActivity(activityId, parentExecutionId, executionEntityManager);
        
        if (miExecution == null) {
            throw new FlowableException("No multi instance execution found for activity id " + activityId);
        }
        
        if (Flowable5Util.isFlowable5ProcessDefinitionId(commandContext, miExecution.getProcessDefinitionId())) {
            throw new FlowableException("Flowable 5 process definitions are not supported");
        }
        
        ExecutionEntity childExecution = executionEntityManager.createChildExecution(miExecution);
        childExecution.setCurrentFlowElement(miExecution.getCurrentFlowElement());
        
        BpmnModel bpmnModel = ProcessDefinitionUtil.getBpmnModel(miExecution.getProcessDefinitionId());
        Activity miActivityElement = (Activity) bpmnModel.getFlowElement(miExecution.getActivityId());
        MultiInstanceLoopCharacteristics multiInstanceLoopCharacteristics = miActivityElement.getLoopCharacteristics();
        
        Integer currentNumberOfInstances = (Integer) miExecution.getVariable(NUMBER_OF_INSTANCES);
        miExecution.setVariableLocal(NUMBER_OF_INSTANCES, currentNumberOfInstances + 1);
        
        if (executionVariables != null) {
            childExecution.setVariablesLocal(executionVariables);
        }
        
        if (!multiInstanceLoopCharacteristics.isSequential()) {
            miExecution.setActive(true);

View on GitHub (pinned to d6d39ce1c6)

Solutions

Redeploy the process definition with the Flowable 6 BPMN converter (flowable.process-definition-location / v5 conversion) so new instances run on V6 internals.
Do not use dynamic MI execution manipulation on V5 definitions — instead redesign the process or implement the dynamic behavior inside the V5 model itself.
Guard the call: check Flowable5Util.isFlowable5ProcessDefinitionId (or the definition's deployment metadata) before invoking addMultiInstanceExecution.

Example fix

// before
runtimeService.addMultiInstanceExecution(activityId, processInstanceId, vars); // may hit V5 definition
// after
ProcessDefinition def = repositoryService.createProcessDefinitionQuery()
    .processDefinitionId(runtimeService.createProcessInstanceQuery()
        .processInstanceId(processInstanceId).singleResult().getProcessDefinitionId()).singleResult();
if (def.getEngineVersion() == null || "v6".equals(def.getEngineVersion())) {
    runtimeService.addMultiInstanceExecution(activityId, processInstanceId, vars);
}

Defensive patterns

Strategy: try-catch

Validate before calling

ProcessDefinition def = repositoryService.createProcessDefinitionQuery()
    .processDefinitionId(definitionId).singleResult();
boolean isV5 = def != null && "activiti".equalsIgnoreCase(def.getEngineVersion());
if (isV5) {
    // skip dynamic MI manipulation for V5 definitions
}

Try / catch

try {
    runtimeService.addMultiInstanceExecution(activityId, piId, vars);
} catch (FlowableException e) {
    if (e.getMessage().contains("Flowable 5 process definitions are not supported")) {
        // migrate/redeploy the definition on V6 or use an alternative mechanism
    }
    throw e;
}

Prevention

Convert all legacy V5/Activiti definitions to Flowable 6 format at deployment time.
Document that dynamic process manipulation APIs are V6-only and gate their use in shared engines.
Track engineVersion on deployed definitions and expose it to feature-toggle logic.

When it happens

Trigger: Calling runtimeService.addMultiInstanceExecution(activityId, processInstanceId, variables) where the running instance was started from a Flowable 5 (Activiti 5-compatible) process definition, detected via Flowable5Util.isFlowable5ProcessDefinitionId.

Common situations: Migrated projects running mixed V5/V6 process definitions (V5 definitions loaded from the old ACT_ tables); dynamically adding executions in a shared engine where some deployments predate Flowable 6; assumption that all runtime features work on legacy definitions.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of flowable/flowable-engine@d6d39ce1c6 (2026-09-11). Data as JSON: /api/errors/4e1cb9b4c6401e09. Report an issue: GitHub.