Interesting to know that signal names have such flexibility. And I can imagine situations where that might be useful. However, the way I've used jBPM 3.2.3, if I send a process instance a signal, I expect the signal to cause a transition (even if the transition is to the same state). So I add validation code between the client and the executing business process that notifies the client if they pass in a signal which is not a valid transition (and thus will not cause a transition). I think I just figured out a way of doing such a validation using 4.x: Cast the Execution (interface) to an ExecutionImpl, call getActivity() to get the ActivityImpl, then call findOutgoingTransition(String name). If findOutgoingTransition returns a null, the transition is not valid. The below code shows this approach, as well as a way to list all valid transitions. public class FirstEnterHandler implements ExternalActivityBehaviour { | public void execute(ActivityExecution execution) throws Exception { | String transitionName = "byListener?"; | ExecutionImpl executionImpl = (ExecutionImpl) execution; | ActivityImpl activity = executionImpl.getActivity(); | TransitionImpl transition = activity.findOutgoingTransition(transitionName); | if (transition == null) { | String validTrans = activity.getOutgoingTransitions().toString(); | throw new RuntimeException("invalid transition " + transitionName | + ", valid transitions are : " + validTrans); | } | execution.take(transitionName); | } | } Even if this code works, it seems like a lot of use of internal implementation classes. Is this approach an ok way to validate signal names? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261101#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...