Appbase declares business process model in a very unrestrictive manner. Definition of workflow pools, their purpose in business process, and access to pools is not restrained by Appbase in any way, and is solely responsibility of solution designer and is based on business requirements. Normally existence and purpose of any pool in solution is justified by business processing needs. For example, it may be required by business process to separate work items according to urgency. Some work items must be processed during one day, others must be processed during one week, and those work items must be stored in separate pools.

Next, workflow pool has much similarity with system user. Work item may be assigned either to user, or to pool. In that sense pool may be considered a virtual user, unlike the real user in the system. Because pool is virtual work item cannot be processed manually until it is reassigned from virtual to real user.

In this respect it becomes important to look how this reassignment occurs. Eccentex recommendation for work item reassignment is to give users access to pools and then build user interface based on that access. Because Appbase implements access control to any solution element based of solution role (security) model it is natural to provide access to pools based on the same role model.

So the answer to the question is the following. It is possible to create role for each pool and give access for each role to a single pool. In this case you will need to create additional roles one per pool and then assign this role to all authorized users (or groups). But if you already have multiple roles in your solution, and they are assigned to users, it may be more efficient to reuse already existing roles wherever possible.

In this case business process designer provides access of existing roles to pools. There may be situations when more than one role is assigned to one pool, or one role is assigned to multiple pools. The choice is completely dictated by business requirements. With this approach new role is created only when reuse of already existing roles contradicts business requirements.

If you need to filter work items in a single pool based on particular user, you may implement this logic in the “Get From Pool” operation via respective business rule. The content of the pool does not depend on particular user, it includes all work items where the owner is pool, but filtering may be implemented when user tries to reassign work item to himself. The rule must be written by solution developer as part of design model.

Field “Owner” in the work item holds access subject code of the user (or pool) who currently owns this work item. Access subject is another concept that Appbase introduces. Access subject is established for all users, pools and roles in the system. Access subject concept provides unified mechanism for all Appbase entities that may have access and do some actions with other solution elements (business objects, pages, etc.) that are called access objects.