At the moment, the process definition xml contains infomation about the process. The more different kinds of things you put into that file, the harder it becomes to understand that file and the more likely you are to put people off from ever using jBPM. So, at the moment you'd like to add some extra bits for a perticular kind of GUI. Maybe next week someone else comes along and wants to put some extra information in for something else (synchronising multiple process instances perhaps, as a non-GUI example) and the week after its adding something else... all the while the process definition becomes more complicated. Meanwhile, people who are using the workflow parts of jBPM and not all these other bits look on in horror as it all gets more and more complicated... Maybe I've got a slightly skewed perspective at the moment - the two projects I'm working on at the moment that have a significant jBPM component have fairly non-standard GUI requirements: 1) A microsoft ASP frontend that interacts with an EJB3 middle tier using web-services (the EJBs interact with jBPM) 2) An applet sitting in an intranet environment. I bring these up as examples of happily using jBPM without expecting jBPM to do the GUI work. Neither will benefit from further complicating the process definition file. If there are issues with building GUI stuff using a certain approach, the issues should be solved at the GUI end, not the jBPM end... ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979639#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...