Performer policies are used when determining the users who are offered a certain task on their to-do lists. This set of users is then stored persistently with the task in order to reduce server startup times. When users reject the task from their to-do lists, the performer policy will be invoked again to update the lists.

The interface to implement is PerformersPolicy. When implementing a policy, it is advisable to start with the class AbstractPerformersPolicy, which takes care of managing the policy state, namely:

The policy state is maintained in four variables, which are defined in the method addInternalProperties(PropertyBuilder) in the interface PerformersPolicy. Such variables do not need to be declared in the XML definition file. The interface PropertyBuilder provides one method per variable type. In own implementations, you may create as many variables as needed.

This simplifies the encapsulation of the internal working of custom performers policies. Note that these variables reside in the same name space as variables defined in the XML process definition, so that you should choose names that are unlikely to occur as ordinary workflow variable names.

When using the class AbstractPerformersPolicy, you will have to implement only four methods and of those, the methods getName() and getDescription() are used for logging purposes, only.

The method calculatePerformers is the most important method of the policy. When called, the policy return a Performers object, which is essentially a collection of users together with a Boolean flag that determines whether the current task is being forced onto a user. Some clients, most notably the Site Manager may choose to accept a forced task automatically on behalf of the current user. In principle, you can use any algorithm to compute the collection of users, but you should normally respect at least exclusions and rejections in that computations.

When no users are found, the policy is free to take appropriate measures to resolve this situation, for example by clearing the set of rejections. When an empty set of users is returned from the method, the task will be escalated.

A collection of users is passed into the method calculatePerformers. This collection contains all users that are permitted to accept the task in question. By taking this collection into account when determining the performers, you avoid duplicating the rights rules in the performer policy.

The method mayDelegateTo is called when a user tries to delegate a task to another user. While the permission check for the executing user is done by a RightsPolicy, the PerformersPolicy checks whether a designated user may receive the task, typically taking the set of excluded users into account.