Typed inputs and outputs
Declare the contract of a process or case so reuse is explicit and far less error-prone.
What it is
Process and case models can now declare a typed contract: the inputs they expect and the outputs they produce. Each input and output is named and typed, and an input can be marked as required. The declaration lives on the model itself, so the shape of the data flowing in and out is part of the design rather than an unwritten convention that only the original author understands.
These declared mappings are surfaced wherever the model is reused. When a Process Task or a Call Activity calls into the model, Flowable Design shows the expected inputs and outputs and flags the required ones, turning reuse into a guided, explicit step instead of guesswork about which variables to pass.
What’s included:
- Typed input and output declarations on both BPMN process and CMMN case models.
- The ability to mark an input as required, so callers know what must be supplied.
- Declared inputs and outputs surfaced automatically when the model is reused via a Process Task or a Call Activity.
Why it matters
Reuse is only safe when the boundary is clear. By making the input and output contract explicit and typed, a model becomes a dependable building block that another team can call with confidence, without reading its internals to learn what it needs. Mismatches surface at design time rather than as runtime failures, which keeps large model libraries maintainable as they grow.
How it works
You declare inputs and outputs directly on the process or case model, naming each one, giving it a type, and marking inputs as required where appropriate. When that model is referenced from a Process Task or a Call Activity, Flowable Design reads the declaration and presents the expected mappings to the caller, highlighting any required input that has not yet been supplied. Existing processes that have a free-form input/output configuration still continue working.
