Walter Egger wrote: Feel free to raise those concerns. A process instance is indeed stored as one row (in its most simple form) in the database, consisting of id, some metadata (like processId and state) and a binary object representing its current state in Drools Flow. Part of merging both jBPM and Drools Flow, is that Drools Flow will be modularized more. They will be using the same core sometimes. Note however that, when you're only using processes and not rules, the session state will basically be empty, as the process instance state is stored separately from the rest of the session state. I like this. Could you explain how you see this happening? While it would be trivial to not persist data (for example by annotating it), does that mean the value will always be null afterwards? Or how will this data be repopulated when reloading the state? Might be possible to support this use case using pluggable variable persistence, where you don't actually store the variable value but customize how the variable values should be stored (or in this case not be stored). There's nothing that would prevent you from dynamically adding new process definitions. You can also migrate a process instance from one process definition to another (assuming the states can be mapped). You'd obviously need some tooling to support the case you are describing. What we're also doing however, to allow you add dynamically add new tasks in the context of an executing process instance, without actually requiring the need to change the definition it is linked to. This could also be useful to create more dynamic processes. Kris