Hi Koen: I'm a fan of the GPD because it makes the jBPM feel like a real product for designing workflows, rather than just a well-written, very flexible, but poorly documented core that one is tempted to hack one's own solution to. So we appreciate your efforts in continuing to improve the GPD and hope you take our suggestions as interest rather than just criticism. I'm realizing that perhaps even more important than supporting lists in the bean/field setter of the GPD would be supporting "enums" or something equivalent. A significant limitation of the bean/field setter is that we are encouraged to input "magic" constants into the fields whose meaning is only apparent by reading the code for the custom class that processes the fields. Boolean fields are not a problem as they can be named to make them self-documenting. But string fields don't give much clue to the range of inputs they can accept. It's not a problem for fields like "name" where anything is acceptable. But let's say we want to indicate the workflow "role" that our custom AssignmentHandler should use to select actors for the pooled actors of a task. What role names are we allowed to input? If the role field could be made an "enum" type, and the GPD bean/field setter expose the list of enum values to select from, it would be a very powerful feature that would help decouple the business process design from the code writing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106117#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...