first, jBPM (the jpdl part) is not bpel. So the analysis is not a (complete) match 1: is covered afaik by jbpm since you get an exception then. You can configure an exceptionhandler and do whatever you want.... Additionally if you want you can even set the token in another node/state. Normally you only get an exception on events like leave-node and 'transition-taken' so jbpm already has some (enough?) support for this. RollBack methods could be implemented but imo the current support should be sufficient 2: Roling back multiple states etc... hmm... in that if you want the user to be protected, give hime a warning.... 'Are you sure..?" Besides that, jBPM has the option to put the token in any node so a 'goto state' is easy to program, IF the node is in a state (see a Jira issue JBPM-728) Rolling back everything is a different thing. What if letters are already printed and sent out. Those have to be nulled or packages transported or..... These are additional tasks and should therefore be modeled in (my not so humble opinion) Additionally, things can be cascading, rolling back one database update could be possible, but what if that new data is already used in other systems.... hmm..... The implications of these things are major in the systems we work with. I therefore see these things as such exceptions that manual intervention is needed. It would take to much effort to design a system that can handle these very rare happenings just my ?0,01 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964470#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...