These are all good challenges and great ideas. Let me comment on what we have and what I would consider to add to jBPM. "bazoo" wrote : Here are a few requirements which have come up on a recent BPM project I've been the BA for, using a different BPM suite but the concepts are the same: | | The ability to step back in a process if a mistake has been made. So rather than an "administrator" editing process variables, a process actor could reject a task and send it back to the previous actor. | | currently we can do this with tasks, but that is not usable in all scenarios. tasks can have task-local variables. you could think of using the task reassign function for the review. and then the reviewer could decide not to submit the task-local variable values to the token. there are new features that we can work out: 1) assingment-routing-slip: in the task in a process, we could specify a list of assignments. then the task would go through all these people in a sequence. if the first clicks done, the task is sent to the second assignee and so on... 2) a superstate can already group multiple task nodes. but we don't have scoped variables for nodes (only on concurrent executions). So the feature we could work out is variables scoped per node which are separate maintained from the underlying process variables. That way you could also cancel the pending process variable updates made in that part of the process. 3) rollback. we had this once in jbpm 2, but didn't yet reimplement it in jbpm 3. with this technique, you log all the process variables updates and then later you're able to rollback the complete process runtime state to a given date in the past. "bazoo" wrote : | In a similar vein, it would be great if you (an administrator) could click on the process map in the web app to restart at the location you clicked. | That is a tricky one. That comes down to the rollback functionality. But the only way that i had been able to work it out in a logical manner was by specifying a time. Rollback the process to where it was at this given time in the past. The problem is determining what has to be rolled back in the presence of forks and joins... "bazoo" wrote : | The ability to define task overrun points, which would trigger remedial procedures. For example, if a process actor hasn't completed a task within 24 hours then assign to someone else. | That is already supported with timers. Hmmm... reassignment is not yet supported. You can have the timer take a transition or execute some random piece of code... Ah that random piece of code could do the reassignment. So yes, i think we cover this feature :-) "bazoo" wrote : | To differentiate between primary users of the system, who "live and breathe" in their task list, and secondary users, who would perhaps get an email with a link which they can click to go in and complete a task every so often. | Doesn't this boil down to usability of the web console. The web console should support power users and occasional users. We're still beefing up the web console's functionality... "bazoo" wrote : | The ability to embed task-specific "help" information in the process map which gets pulled through to the web app and displayed in context on the task page. | I think i recently added a description. Would that qualify as help ? Or would you consider that different ? "bazoo" wrote : | The ability to easily get an overview of all the data associated to a particular process job, and to make changes to that data where it won't affect the integrity of the process. If you mean process variable updates, that is somehting that is going to be supported soon in the web console. Of course, not all types and navigations might be supported. Cause we can persist all kinds of pojos. Event whole object graphs. Making all of these types editable in a web form will be the challenge here. Also a challenge is when a user stores references to persist objects in his own domain model. E.g. When there is an Order process and an Order java class that is persisted with hibernate. THen you can easily drop that Order object variable into the jbpm process variables... but making the properties of that user defined object editable in the web form will not be trivial. Basic types that are just in the process variables should be no problem, though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3992297#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...