I mentioned 4 additional pieces of data that I thought should be recorded--three on the ProcessDefinition and one on the Task. Lets just consider one of them: the ui attribute on the Task. Lets say we have a long running process (1+ month) called "order". On day 10 after deployment we have 200 new processes started, and the business realizes that they would like something done differently on the "shipIt" Task. The change will require a change to the Definition as well as a change in the Task's UI functionality. We determine that the UI functionality for the old and new versions of the "shipIt" Task will NOT be compatible. Assuming we have a "ui" attribute on the Task object, in the two versions of our ProcessDefinition we would see something like this: The first version of the "order" ProcessDefintion was originally deployed with all Task ui attributes set to 'ui=1'. Knowing the UI requirements are changing for the "shipIt" Task, the new version of the "order" ProcessDefintion is deployed with the "shipIt" Task's ui attribute set to '2' <task name="shipIt" ui="2"> On the UI side, the developer could utilize this information many ways; here is just one implementation example: The developer stores screens in a folder structure similar to ".../tasks/{ProcessDefinitionName}/{TaskName}/{TaskUi}.xhtml". The UI is responsible to provide a screen for each Task/ui requirement, so before deploying the new version of "order" the developer would create a new screen .../tasks/order/shipIt/2.xhtml Now from the UI application, the user selects a task from their work queue. The UI fetches the TaskInstance, examines the associated Task.getUi() value and loads the appropriate screen. In this example, the developer creates a new JSF/Facelets/whatever page and backing beans for each unique ProcessDefiniton_name/Task_name/Task_ui combination; however, the same Task.ui data could be used just as well by screen configuration files or even a content management system. I'm sure that each person here could come up with a totally different and equally viable way to utilize the Task.ui data in their own UI. As for the three other pieces of data I mentioned... * The "ui" attribute on the ProcessDefinition itself can be used in exactly the same ways as mentioned above for identifying appropriate versions of Process summary screens. * The deployment timestamp on the ProcessDefintion is just a very simple change that can make at-a-glance trouble shooting or answering some questions VERY easy. * The release number on the ProcessDefinition makes so much sense I don't even know where to start--Every major software product records and displays a developer-provided release number--and remember that long running jBPM processes and their definitions exist outside the scope of any running application (or database for that matter)--they need to carry developer-provided versioning info just like any other solution. All four of these items are simple attribute adds, with no impact to existing functionality. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4125308#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...