Ronald, I'm not sure how useful an EL would be for setting restriction. I'd need some kind of UI identification switch or the user's roles in scope to compare with. (Would SEAM make these things more readily available to the process execution?) (Or have I missed some funtionality that allows container roles to be pulled into the execution context?) Some things to consider: * This is a big organization. We have an LDAP infrasfructure for managing users and groups--jBPM's identity component is not an option. I think this would be a typical scenario in most enterprises. * Our UI is already built and extends far beyond what can be generated by the GPD (and probably will for a very long time). Not to mention, that when regularly using all of jpdl's capabilities the current GPD becomes more of a hinderance than a help. (Ok, I confess it's been a while since I've looked at it :-) * Bernd, we have scores of tasks that are managed by our system but that are not yet performed in our system, if they ever will be. That means no custom screens (and no additional configurations) are created for over 100 tasks--users just claim a task and take an available transition. This scenario is typical for a large company that is implementing a workflow system to manage process flows across several existing IT systems. Requiring the UI to have proper configuration for every item is a significant barrier to entry when it comes to getting lots of processes and tasks on the system in a relatively short amount of time. I'm really not trying to push a particular solution, but I am trying to point out an area of pain--an area in which a few small compromises (or as yet unseen solutions) could go a LONG way toward helping the largest corporations see a rapid deployment and return on investment. Once the existing processes have been defined, it comes down to this: I can set a few flags and deploy processes acoss the entire company under a generic UI, or the company can wait until I've mapped over and built up a UI for 200 tasks. In our case, we've had to hack the first solution, because there is no way the company would have let us do the latter one. Thanks, Britt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053284#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...