Migrate from Flowable to Priostack
Last updated: 2026-04-06 · 11 min read
Concept Mapping
| Flowable | Priostack | Compatibility |
|---|---|---|
| Flowable Engine (BPMN) | Priostack BPMN Engine | Native |
| Flowable DMN Engine | Built-in DMN 1.3 | Native |
| Flowable CMMN Engine | Built-in CMMN 1.1 | Native |
| JavaDelegate (Service Task) | Job Worker (REST polling) | Rewrite required |
| flowable:serviceTask (HTTP task) | Job Worker calling external HTTP | Rewrite required |
| FlowableMail (mail task) | Worker that calls your mailer | Rewrite required |
Flowable REST API (/process-api) | Priostack REST API (/api/v1) | Path changes |
| Flowable IDM (users/groups) | Priostack accounts + admin console | Different model |
| Flowable Modeler | Camunda Modeler (Zeebe profile) | Use Camunda Modeler |
BPMN: Extension Namespace Changes
Flowable uses the flowable: namespace. Replace with zeebe: task definitions. The snippets below are fragments: paste them inside a <definitions> element that declares xmlns:zeebe="http://camunda.org/schema/zeebe/1.0".
Before (Flowable):
<serviceTask id="validate-order" name="Validate Order"
flowable:class="com.example.ValidateOrderDelegate">
<extensionElements>
<flowable:field name="threshold" stringValue="500" />
</extensionElements>
</serviceTask>
After (Priostack):
<serviceTask id="validate-order" name="Validate Order">
<extensionElements>
<zeebe:taskDefinition type="validate-order" />
</extensionElements>
</serviceTask>
flowable:class, flowable:expression, flowable:async, flowable:exclusive attributes. Priostack does not parse them, so they do nothing, and a service task without zeebe:taskDefinition gets its job type from its name, then from its id. Field injection (flowable:field) has no equivalent and zeebe:ioMapping is not read either: keep a constant such as threshold in the worker, or pass it as a process variable when you start the instance.
DMN: Direct Compatibility
Flowable DMN 1.3 tables use the same XML format. Deploy them through POST /api/v1/models (1 credit, refunded if the deploy fails); input entries must be unary tests the engine reads (see DMN Elements), otherwise the deploy answers 422. Evaluate with a flat JSON object of inputs (1 credit):
# Deploy DMN (201 {"key","modelKind":"dmn","resourceName","tenantId"})
curl -X POST "https://priostack.com/api/v1/models?resourceName=risk-score.dmn" \
-H "X-API-Key: ps_your_key" \
-H "Content-Type: application/xml" \
--data-binary @risk-score.dmn
# Evaluate (200 {"result":{...}})
curl -X POST https://priostack.com/api/v1/decisions/riskScore/evaluate \
-H "X-API-Key: ps_your_key" \
-H "Content-Type: application/json" \
-d '{"age":35,"income":60000}'
CMMN: Direct Compatibility
Flowable CMMN 1.1 case models use the same XML format. Priostack supports:
- Human tasks and decision tasks. A process task does not start a BPMN process: it is offered as a job of type
processthat you complete - Sentries (
onPart+ifPartwith FEEL conditions); several on-parts in one sentry must all occur - Entry/exit criteria on the plan items that reference stages, tasks and milestones (every stage must be referenced by a
planItem) - Milestone elements
# Deploy CMMN (1 credit)
curl -X POST "https://priostack.com/api/v1/models?resourceName=investigation.cmmn" \
-H "X-API-Key: ps_your_key" \
-H "Content-Type: application/xml" \
--data-binary @investigation.cmmn
# Start a case instance (201, 1 credit)
curl -X POST https://priostack.com/api/v1/cases \
-H "X-API-Key: ps_your_key" \
-H "Content-Type: application/json" \
-d '{"caseDefinitionId":"investigation","variables":{"subject":"ABC Corp"}}'
# Complete a plan item (200 {"instanceKey"})
curl -X POST https://priostack.com/api/v1/cases/jobs/{jobKey}/complete \
-H "X-API-Key: ps_your_key" \
-H "Content-Type: application/json" \
-d '{"variables":{}}'
REST API Endpoint Mapping
| Flowable REST | Priostack equivalent |
|---|---|
POST /process-api/repository/deployments | POST /api/v1/process-definitions (BPMN, free) or POST /api/v1/models (BPMN, DMN, CMMN; 1 credit) |
POST /process-api/runtime/process-instances | POST /api/v1/process-instances |
GET /process-api/runtime/process-instances | GET /api/v1/process-instances |
GET /process-api/runtime/tasks | GET /api/v1/tasks |
POST /process-api/runtime/tasks/{id} (action: complete) | POST /api/v1/tasks/{id}/complete (1 credit) |
POST /dmn-api/dmn-rule/execute | POST /api/v1/decisions/{decisionId}/evaluate |
POST /cmmn-api/cmmn-runtime/case-instances | POST /api/v1/cases with caseDefinitionId |
POST /process-api/runtime/signals | No hosted equivalent: there is no signal or message API. A signal catch event waits as a worker job of type event:signal:<elementId> |
Migration Steps
Step 1 - Export definitions
From Flowable Modeler or repository, export all .bpmn, .dmn, and .cmmn files.
Step 2 - Strip Flowable extensions from BPMN
# Patterns to find and replace in .bpmn files: flowable:class="..." → remove flowable:expression="..." → remove flowable:async="true" → remove flowable:exclusive="..." → remove flowable:formKey="..." → remove flowable:candidateGroups="..." → remove
For each replaced service task, add a zeebe:taskDefinition type="your-type".
Step 3 - Deploy all definitions
POST /api/v1/models detects the kind of each file and costs 1 credit per model. Deploy decisions and called processes before the models that use them:
for f in *.dmn *.bpmn *.cmmn; do
curl -sf -X POST "https://priostack.com/api/v1/models?resourceName=$f" \
-H "X-API-Key: ps_your_key" \
-H "Content-Type: application/xml" \
--data-binary @"$f" || { echo "Deploy failed: $f"; break; }
echo "Deployed $f"
done
Step 4 - Port JavaDelegates to REST workers
Each JavaDelegate class becomes a polling worker. See the Activiti migration guide for a Node.js worker example - the same pattern applies.
Step 5 - Remove Flowable Spring configuration
Remove flowable-spring-boot-starter from your dependencies. Workers only need an HTTP client to communicate with Priostack.
Step 6 - Test with representative instances
Start one instance of each process type and validate the happy path before migrating production traffic.
Flowable-specific Features: Status
| Flowable feature | Status in Priostack |
|---|---|
| Async service tasks (flowable:async) | All service tasks are async by default |
| Mail task (flowable:mail) | Implement as a worker that calls your SMTP/SES |
| HTTP task (flowable:http) | Implement as a worker that calls the target URL |
| Script task (flowable:script) | Not run inline: it becomes a worker job of type script:<name or id> |
| Shell task | Not supported - use a worker |
| Camel task | Not supported - use a worker that delegates to Camel |
| Event registry | Not supported: the hosted API has no message or event publishing route |
| Content API (attachments) | Not supported - store in your own object store |