Well, the reason we modeled the process like this, and I guess I wasn't clear about that in the original post, is that the observer and item "states" are a actually processes with multiple steps that need to be synchronized. The item side represents sub-processes about postal mailing to certain parties, with states (mostly tasks to be performed by a human) like generating mail, mail sent, mail not received (loop back if threshold not exceeded, fail otherwise), mail received (notify observer side), etc, and the observer side can only continue from certain states when *all* involved parties have been notified. I'm not sure how much I can tell you about our actual business process, but if it is useful to the community I can cook up some example test case to showcase how we implemented the fork, as the fork is really a generic node with an action handler to control the token propagation, setting branch-local variables (such as info about the mailed party) on the child tokens, etc... So in light of all this would you still recommend against such approach? I'll have a look at making the observer wait states decision nodes, but I guess since the decision is basically stay there or continue, it is better to use State nodes somehow... BTW we had a look at drools (for authentication), but since our domain objects are rather complex drools turned out to be rather cumbersome (it's really good at deciding on direct properties of an object (like foo.bar), but when we needed to make decisions on foo.bar[].baz.xul, it started to look a lot like java code, so we finally implemented the rules in java, but closely modeled after drools, i.e. through Identity.hasPermission(name, action, data). Thanks, Greg View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176317#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...