for some reason or another i never did take the time to properly analyse and implement initial nodes. just did some tests and this is now supported: <process-definition name="door" initial="Closed"> | | <state name="Locked"> | <transition name="unlock" to="Closed" /> | </state> | <state name="Closed"> | <transition name="lock" to="Locked" /> | <transition name="open" to="Open" /> | </state> | <state name="Open"> | <transition name="close" to="Closed" /> | <transition name="lock" to="Open Locked" /> | </state> | <state name="Open Locked"> | <transition name="unlock" to="Open" /> | </state> | | </process-definition> this prevents users from having to do a signal right after creation of the process. also, when creating a new process instance, the initial node (or the start state) IS EXECUTED as the last step in the creation of the process instance. This means that you can have processes that start automatically. You can e.g. specify an initial node with an action handler. To remain backwards compatible, start-state still ends up in the process definition startState. so you do not HAVE to specify an initial node name. in theory, this should also work in the context of super states. in that case you can specify the slash separated hierarchical name of the initial node. (not tested yet) the complete test suite now runs with this additions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4012411#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...