re: "confirm='true'" anonymous wrote : that is UI. the task form ui only can do so much. we can keep adding features till it is as rich as JSF+Facelets+RichFaces... if it would be added, it should be done in the Facelets form document. The problem here is that it is not up to the UI designer to determine what should require a confirmation. This is the domain of business analyst/process designer. We have nearly 200 tasks over more than 20 processes (and we're not done). We work in a rapidly evolving environment and need a way to tell the UI developer which transitions need a confirmation based on their impact on the process--some way other than handing him a spreadsheet of 100+ process/node/transition combinations to keep track of. To keep things sane we'll either have to break with schema valid jpdl, or use a naming convention--something like if the transition name starts with a "+", don't display the "+" and require a confirmation. The same thing is true with restricted access. We're already blocking visibility of transitions like 'administrative cancel' and 'retry integration' by prefixing them with an "_". Its a way to say "admin only" without having to know how the UIs define that role. But parsing transition names to figure out which type they are is a poor solution. Sure, we can build our own configuration files/tables to sit along side of jBPM, but then we're just repeating 'process/node/transition' mappings over and over, and are operating outside the scope of versioning. Both of these items are configuration flags that specify how a transition should behave, not how that behavior should be implemented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053167#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...