Skip to main content


An event model defines the structure of the data that is exchanged between systems. This structure defines which data fields (and their data type) are available by users of this event.

For example, a Customer onboarded event might consist of

  • a name (type string)
  • a legal address (type string)
  • an expected deal size (type double)

Process and case models will only work with the data from such an event model. For example, the customer name might be stored as a case variable or the deal size might trigger a few sentries.

Similar to all Flowable models, an event model will be deployed as an event definition. Instances of this definition, for example when an event is received, are passed to a process or case instance as an event instance. This is consistent with for example a process model that gets deployed as a process definition and from which process instances are started.


The point is that these process/case models don't (need to) know that there is a Kafka, JMS, RabbitMQ, etc. listener nor that the data is serialized from XML or how the data actually looks like (or something else). This is all abstracted away for the modeler of those models which can focus on the important part of the model: how to handle the business change that is expressed by the event.