Data Input
Data the process REQUIRES from the outside at its start — the formal input parameter of the process. Data-object shape with a hollow arrow marker.
The Data Input declares the process's contract with its environment: *to run me, hand me this* — the claim form, the customer record, the order payload. Formally it belongs to the process's InputOutputSpecification, making the required inputs explicit rather than implied.
When to use and avoid
When to use
To document the required inputs of a reusable/global process (especially ones invoked by Call Activities).
To design clean interfaces between caller and called processes.
In governance contexts where process contracts must be explicit.
When NOT to use
For data produced and consumed inside the flow — plain Data Objects.
For persistent repositories — Data Store.
In simple descriptive diagrams where the input contract adds noise.
Business example
The order as the process's declared input
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The highlighted artifact represents the information the process receives at its boundary — the arriving Order.
- The first task consumes it and the flow proceeds.
- In the formal notation, this artifact carries a small hollow-arrow marker identifying it as the process's Data Input (rendered here as the equivalent data artifact).
Differences
Data Input vs Data Object
The Data Input is part of the process's signature — supplied from outside at instantiation. A Data Object is created and used along the way. Parameter → input; working data → object.
FAQ
Where are Data Inputs defined formally?
In the process's ioSpecification (input sets); Call Activities map caller data onto them when invoking the process.
Can activities also declare Data Inputs?
Yes — activities have their own ioSpecification; the same concept applies at task level.