The work pool for a user is the set of all the work objects (open and resolved) of all the Work- classes that a user can enter (in one application).
The system determines which work types (which classes derived from the Work- base class) a user can enter from a list of class groups. These class groups are specified in an access group associated with that user.
A single user can create work objects that belong to different class groups. For example, suppose three applications are defined by RuleSets Alpha, Beta, and Gamma. Assume that each application has one class of work objects, with the class names Work-Alpha, Work-Beta, and Work-Gamma, and that one class group is defined for each application.
Tom's access group can let Tom be a user of only the Alpha application. Tom can create, review, and update only Alpha work objects.
User Mary is a user of both Beta and Gamma applications and so can create, review, and update both Alpha and Beta work objects. User Fred can access all three applications.
The selected work pools also affect the operations of the Application Explorer and the scope of reports in the Monitor Activity workspace.
On the Requestor page of the clipboard, the property pxRequestor.pxCurrentWorkPool holds the value of a user's current work pool.
When one Process Commander system hosts two or more organizations using a common application, make sure that each organization have dedicated work pools. Work object numbering is per work pool; each organization can then have a work object numbered W-1234.
access group, class group, worklist, work pool name, work type | |
About Access Group data instances More about Class rules |
|
Atlas
— Initial Class Groups
Atlas — Standard Properties on the Requestor Page |