i just finished generalization of the conditions (SEAM request). previously, it was only possible to specify conditions on transitions leaving a decision node. now, (from 3.2.Alpha3 and onwards) it will be possible to specify conditions on any transition. these will be checked at runtime. also i added the functionality to the token of getting all the transitions for which there is no condition or a condition that resolves to true. this method is called getAvailableTransitions() by implementing this in a backwards compatible way, i realized that the current behaviour is still very awkward. a decision will scan and evaluate all transitions that have a condition first. the first transition for which its condition resolves to true will be taken. if no transition with a condition resolves to true, the default (=the first one) will be taken. with pain in my heart :-( i saw that the docs actually explained different behaviour then what is implemented. so i had to update the docs explain the less intuitive behaviour... snif. A decision will take the first transition that has no condition or that has a condition which resolves to true. i have kept this strange behaviour for backwards compatibility reasons. As far as i can see now, old processes with decision conditions will still work in the new version. Also if you redeploy processes with decision conditions, they will still work (i have marked the expression attribute on the condition as deprecated). The new versions will never use the JBPM_DECISIONCONDITION table any more. But i left it in the hibernate mappings so that there is no need for a conversion script. If people don't have old deployments with decision conditions, they can just remove that table. DO YOU THINK THAT IS A WISE 'DECISION' ? Or should i just change the decision behaviour to the more intuitive and backwards incompatible mode ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996402#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...