That is indeed an inconsistency which is not easy to solve in the current architecture. The idea is that in jbpm 4, the architecture will change in a way that makes it easier to fix this. Now modules are pluggable. The idea is that you can just plug in or rip out the task management module from a jbpm deployment. That is why the plain process instantiation code cannot have a direct reference to the task managment module to see if there needs a task to be created. If we want to fix this in the current architecture, we would have to expand the current event mechanism to span multiple modules. Now, events are generated in the graph and propagate to the process instance. To accomodate auto task instance creation, we would have to dispatch this event over the module instances once it arrives at the process instance level. Also we should dispatch it over the process definition and all module definitions. This cumborsome and difficult eventing mechanism is one of the reasons why we want to go forward with a different architecture. Modules will not be pluggable in the way they are now. A ProcessInstance will contain the plain graph execution runtime information (as now) but it will NOT contain any module instances. Instead, to add new module instances, inheritence should be used. That way, we will create a JpdlProcessInstance that contains the jPDL modules in the object model. This will remove the module instance indirection and reduce the navigation in the database, thereby significantly improve performance as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964907#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...