With the introduction of support for pattern History-Based Allocation, RAL covers all the creation patterns defined by Russell et al. Furthermore, the coverage regarding creation pattern Separation of Duties (SoD) has also been improved. This pattern is related to the so-called access-control constraints. Access-control constraints consist of restrictions that can be set between two activities to delimit their sets of potential performers in order to avoid conflicts of interests or undue separation of duties. Their name emerged with the Role-Based Access Control (RBAC) perspective for resource management, which established an organizational meta model based on a hierarchy of roles and, on that basis, defined two access-control constraints to represent well-known policies present in organizations: SoD and BoD (Binding of Duties). The former indicates the need of assigning two activities to two different persons (or roles, as desired) in order to avoid conflicts of interest in the performance of both activities. The latter, on the contrary, forces the same person to perform two given activities. Most current proposals for resource management in workflows and business process environments are concerned about dealing with this kind of constraints, for example:

Bertino, E.; Ferrari, E. & Atluri, V. (1999), 'The specification and enforcement of authorization constraints in workflow management systems', ACM Trans. Inf. Syst. Secur. 2, 65-104.

Strembeck, M. & Mendling, J. (2011), 'Modeling process-related RBAC models with extended UML activity models', Inf. Softw. Technol. 53, 456-483.

Both SoD and BoD can be configured at one single instance level (i.e. dynamically), or at global level, that is, taking into account the past execution of the process (i.e. statically). In the first version of RAL, we focused on a single business process instance and disregarded previous process executions, so only DSoD and DBoD were addressed so far. With the history-aware expressions and their semantics, SSoD and SBoD are also supported. 

Regarding the rest of WRPs, it is important to note that most of the patterns belonging to the other groups (Push, Pull, Detour, Auto-Start, Visibility and Multiple Resource Patterns) are related to features supported by the BPMS where the process is launched rather than functionalities that a resource assignment language can provide. Thus, they are not a priority for RAL. Nevertheless, notice that RAL expressions could be used in some of them to define restrictions when performing actions such as task delegation (pattern 27-Delegation), or task re-allocation (patterns 30-Stateful Reallocation and 31-Stateless Reallocation), provided that the BPMS allows the specification of restrictions for such actions.