CRISTAL (Collection of Resource-centrIc Supporting Tools And Languages), a system aimed at providing advanced support for resource management in business processes. Most of its functionalities are based on RAL (Resource Assignment Language), a language to select human resources from an organizational model.

Registered Tool


CRISTAL is a tool suite composed of three parts:

  1. RACI2BPMN Tool. With this tool, RASCI information is automatically introduced in a BPMN model, from responsibility management information contained in a RASCI matrix, and some binding information required to be able to generate accurate resource assignments in the output process model.
  2. RAL Solver Tool. This tool maps the RAL expressions of a BP model into an OWL-DL ontology in order to resolve them and analyse them automatically, both at design time and at run time:
    • DT RAL Solver: the current implementation is a plug-in for Oryx that allows the calculation of the potential performers of the activities of a BPMN model.
    • RT RAL Solver: it calculates the potential performers of a BP during execution, that is, taking into consideration the real performers of previous activities to resolve those RAL expressions with constraints with respect to them, e.g. a segregation of duties between two activities to indicate that they have to be performed by two different persons. The implementation is a library that works with Activiti. It is available on demand, contact Cristina Cabanillas for a copy. Once installed, RAL expressions can be assigned to the BP activities, and they will be automatically resolved along the execution of the process.

Code on Github!

RAL language

RAL (Resource Assignment Language) is a language for assigning (human) resources to the activities of a business process model.
RAL is based on the organizational meta model (shown below in gray), which corresponds to an excerpt of the organizational meta model described by Russell et al. in “Workflow Resource Patterns: Identification, Representation and Tool Support”. It basically consists of persons, positions, roles and organizational units. As depicted in the figure, a resource can be an individual resource, i.e., a Person, or a set of people involved in a specific group (Role, Position, Organizational Unit). Individual resources have a set of capabilities, such as their professional experience. The meta model is extensible to include new capabilities. Each person occupies one or more positions within an organization, which in turn can participate in several roles and belong to an organizational unit. Roles make sense only within a UnitType (e.g. project coordinator, head of a research group, etcetera).

Some elements related to business processes are also included in the meta model (in white). They represent the elements required to store information about the executions of the different process instances, so that we can resolve history-aware RAL expressions. Specifically, a BusinessProcess has a set of activities, which have associated a RALExpression indicating the resources allowed to perform the task at run time (i.e. potential performers of the Activity). For each process instance, zero, one or more instances of its activities can be executed. Each ActivityInstance (a.k.a. work item) can have a different actual performer, as long as that person meets the conditions stated by the resource assignment expression. The completion time of each activity instance is recorded, so that some RAL expressions can be resolved. The set of work items undertaken by a single person constitute his/her execution history. The meta model shown in above, thus, contains all the information required to use all the RAL expressions.

In the following subsections we define RAL and describe each type of RAL expression. This language has three main advantages:

(i) It is very expressive, since it allows expressing resource constraints regarding information obtained both at design time and at runtime.

(ii) It allows adding organizational information to business process models, since it is based on an organizational metamodel.

(iii) Its syntax is close to natural language and, hence, it is easy to learn and use.

RAL abstract specification

RAL has been created to define resource assignment expressions with a syntax close to natural language. In the following we show RAL’s metamodel.

RAL concrete syntax

In this section we present the EBNF notation of RAL and its detailed description.

Expression := IS PersonConstraint
| HAS GroupResourceType GroupResourceConstraint
| SHARES Amount GroupResourceType WITH PersonConstraint
| HAS CAPABILITY CapabilityConstraint
| RelationshipExpression
| CompoundExpression

RelationshipExpression := ReportExpression
| DelegateExpression

ReportExpression := REPORTS TO PositionConstraint Depth
| IS Depth REPORTED BY PositionConstraint

DelegateExpression := CAN DELEGATE WORK TO PositionConstraint

CompoundExpression := NOT (Expression)
| (Expression) OR (Expression)
| (Expression) AND (Expression)
| (Expression) AND IF POSSIBLE (Expression)

PersonConstraint := personName
| PERSON IN DATA FIELD dataObject.fieldName
| PERSON WHO DID ACTIVITY activityName HistoryExpression

GroupResourceConstraint := groupResourceName
| IN DATA FIELD dataObject.fieldName

CapabilityConstraint := capabilityName
| CapabilityRestriction

PositionConstraint := POSITION name_position
| POSITION OF PersonConstraint

HistoryExpression := IN CURRENT INSTANCE
| FROM startDate TO endDate


Amount := SOME

GroupResourceType := POSITION

| λ

RAL allows expressing the following assignments:

  • Individual resource assignments. RAL allows expressing that an activity must be performed by someone indicated in a PersonConstraint: (i) a specific person; (ii) the person who did another activity; or (iii) the person indicated in a data field. For the last option, information about the process instance in which the activity has been executed must be provided, specifically:
    • The same process instance currently running.
    • Any instance of the process (including the ongoing one). 
    • Any previous process instance (excluding the ongoing one). 
    • Those process instances in which the activity has been completed between two given dates (regardless of whether the process instance itself is over or not).
  • Process-oriented history-aware assignments. The same history-aware assignments previously defined can be specified at process level, that is, without detailing a concrete activity.
  • Assignments based on group resource constraints. It allows assigning an activity to a given position, role or organizational unit, or to one read from a field of a data object.
  • Assignments based on commonalties. Expression SHARES Amount GroupResourceType WITH PersonConstraint is used to assign persons that share some or all position(s), role(s) or organizational unit(s) with the person indicated in a PersonConstraint.
  • Assignments based on personal capabilities. Constraints based on the capabilities of individual resources, such as years of experience or reputation can be expressed with RAL. These constraints may consist of the existence of certain capability or of the holding of certain condition on the value of a capability.
  • Equivalent assignments. RAL uses expression IS ASSIGNMENT IN ACTIVITY activityName to indicate that an activity has the same RAL expression as another activity. This avoids having to re-write several times the same assignment, as the same time as it helps saving time and effort and prevents making writing mistakes.
  • Assignments based on hierarchical relationships. According to the relationships between positions of an organizational model described by Russell et al., a position can report work to one position and can delegate work to one or more positions. Using these relationships we can construct contraints such as “activity Fill Travel Authorization must be performed by someone that reports to the Project Coordinator”.
  • Compound assignments. Combination and negation of the aforementioned expressions are allowed. Furthermore, the conditional expression AND IF POSSIBLE has been included to let the modeller express preferences/priorities. For instance, by stating that, if possible, an activity has to be carried out by certain role, we are meaning that that is the first assignment we have to try when actually allocating the activity to an individual resource (at runtime). In case preferences are not fulfilled, they are just ignored.

Testing RAL expressiveness

In this section we show how RAL can be used in business process models and we test its expressiveness on the basis of some Workflow Resource Patterns (WRPs) introduced by Russell et al. Specifically, we use the creation patterns because they are focused on information that can/must be added at design time, so they constitute the group of patterns in which RAL fits best.

The reference business process model we are using and the structure of the organization where it is used are shown above. More detailed descriptions of this scenario are given in RAL_ontologies.

Direct Allocation: The ability to specify at design time the identity of the resource that will carry out a task. For instance, the Sign Travel Authorization task must only be undertaken by Antonio:

Sign Travel Authorization: IS Antonio

Role-Based Allocation: The ability to specify that a task can only be executed by resources with a given role. For instance, instances of the Fill Travel Authorization task must be executed by a Research Assistant:

Fill Travel Authorization: HAS ROLE ResearchAssistant

Deferred Allocation: The ability to defer specifying the identity of the performer of a task until run time. For instance, during execution of the process, instances of the Send Travel Authorization task will be executed by the person named in the resource field Applicant of data object Authorization:

Send Travel Authorization: IS PERSON IN DATA FIELD Authorization.Applicant

Authorization: The ability to specify the range of resources that are authorized to execute a task. For instance, only a Researcher and a Research Assistant are authorized to carry out instances of the Submit Paper task:

Submit Paper: (HAS ROLE Researcher) OR (HAS ROLE ResearchAssistant)

Separation of Duties: The ability to specify that two tasks must be allocated to different resources in a given workflow case. For instance, instances of the Sign Travel Authorization task must be allocated to a different person to that who executed the Fill Travel Authorization task:

Sign Travel Authorization:


History-based Allocation:The ability to offer or allocate work items to resources on the basis of their previous execution history, e.g. the end of the previous and the next RAL expressions.

Case Handling: The ability to allocate the activities within a given workflow case to the same resource. For instance, all tasks assigned to position PhD Student are allocated to the same person.

Assigned to some activities: (HAS POSITION PhDStudent) AND

The second part of the composition is not necessary for the first task that has been assigned the position Phd Student

Retain Familiar: When several resources are available to undertake an activity, the ability to allocate an activity within a given workflow case to the same resource that undertook a preceding activity. For instance, any PhD Student available can undertake the Register at Conference task, but it should be allocated to the same person that undertook the Submit Paper task.

Register at Conference: (HAS POSITION PhDStudent)

Capability-based Allocation: The ability to offer or allocate instances of a task to resources based on their specific capabilities. For instance, instances of the Submit Paper task must be allocated to someone with a degree:

Submit Paper: HAS CAPABILITY Degree

Organizational Allocation: The ability to offer or allocate instances of a task to resources based their position within the organization and their relationship with other resources. For instance, the Sign Travel Authorization task must be allocated to someone that is reported by (the position of) the person that undertook the Fill Travel Authorization task:


RAL covers all the creation patterns. Pattern Automatic execution was not explicitly used because it does not involve resource assignments and, thus, it is directly supported by all business process management tools with execution capabilities.

The current version of the standard notation for business process modelling (BPMN 2.0) allows using different languages for resource management. The table below presents a comparison of the coverage of BPMN regarding resource management from the study performed by Russell et al. when they introduced the workflow resource patterns to the current version (BPMN 2.0) “enriched” with RAL.

RAL, Access-Control Constraints, and the WRPs

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.

Team-Aware Organisational Metamodel

We propose team-related extensions to the organisational metamodel described by Russell et al. for the definition of the WRPs, based on observations from several domains, e.g. healthcare, software development and military missions. The figure below depicts the team-aware organisational metamodel, where former entities are coloured in grey and team-related concepts in white. A Team is a set of people collaborating in the completion of a specific activity with a common objective. A person is member of a team due to playing a role in the team (class TeamRole), e.g. coordinator of Perm_RE_1. Each team role has a specific TeamRoleType according to types explicitly defined in the company, such as investigator, coordinator, implementer or specialist. It has to be emphasized that team roles are fundamentally different from organisational roles. In an example we described in the paper submitted to CAiSE 2014, Nick occupies the position DoG_Doctor and participates in organisational roles Doctor and Assistant, but within team Perm_RE_1 he has the team role of Coordinator for Perm_RE_1 (of type Coordinator) and the team role of Implementer for Perm_RE_1 (of type Implementer).

A team can have a type (class TeamType) that is associated with a specific configuration of the organisational roles. For example, in the motivating scenario there are teams Perm_RE_1 and Perm_RE_2 of type Routine Examination, composed of a doctor and an assistant. Team type Advanced Tests is made up of a doctor, an assistant and a nurse. More teams of these types could be created with the same role configuration. There could also be a team type Heart Surgery made up of two doctors, two assistants and one nurse, for instance. In this way, team types provide templates for the composition of teams. 
Teams can also be structured hierarchically. For example, in SW development, there are often teams of SW Analysts (composed of persons with role Analyst),  teams of SW Developers and teams of SW Testers. The team of analysts delegate work to the teams of developers, which report issues and results to the former and, in turn, delegate work to the team of testers. These report the results to the developers. In this context, modes of communication between teams have to be established, which we do not directly address here.
Finally, teams are also classified according to their temporality. A PermanentTeam is defined without a expiry date. Permanent teams can be referenced by their identifier at any moment. However, in certain occasions new teams are composed for specific purposes. For instance, in emergency surgeries teams are created, modified and broken up constantly depending on the requirements of the operations. Such teams are called TemporaryTeams because they have a expiry date defined as a specific scope. The scope can be (i) a specific period of time, e.g, a team active from August 1st to August 31st to provide support during the summer holiday break; (ii) it can be associated to a single activity instance, e.g. the execution of a single surgery; or (iii) it can be related to a process instance, so that the team can be treated as a single entity during the execution of the process instance because their participation could be required at any moment. Further team classifications are proposed in literature that mostly focus on how teams organise themselves (e.g. their coordination mechanism). However, they are not included in the metamodel because our focus is on those aspects that are relevant for team selection in the context of resource assignment.
A person is a team creator if she is in charge of its configuration and of recruiting its members. She is not necessarily a member of the team, though. Besides, the figure of team creator is not mandatory, as teams may be automatically composed by a system according to some properties defined for them. 
It is important to remark the difference between an OrganisationalUnit and a PermanentTeam. Although both are groups of people with an indefinite duration, the former is not an entity of collaborative work with a single goal by nature, but is composed of members that participate in different activities, each of which has a specific objective. In case of assigning concrete work to an organisational unit, it is because the unit is working as a team in the context of an activity or process, i.e., there is a new team made of the members of the organisational unit. For instance, if a hospital is organising an event, each department (i.e., organisational unit) could form a team working on the preparation of a specific issue (i.e., in that moment all their members have a common goal). Such a distinction has been described before in literature.

RALTeam language description

(NOTE: due to space limitations, in the paper submitted to ICSOC 2014 we present an excerpt of RALTeam)
RALTeam is divided into five modules, depicted in white in the figure below, to allow different levels of expressiveness depending on the availability of data (e.g. process log history or data used in a process). Each RALTeam module is composed of expressions and constraints, which will be described next using their EBNF syntax.

RALTeam semantics

[The full mapping of RALTeam can be downloaded from here:]
Following the same approach as in RAL, RALTeam semantics is defined by means of a mapping to DLs. Knowledge representation systems based on DLs involve two components: TBox and ABox. The TBox describes terminology, i.e., the ontology in the form of concepts and roles (relations between the concepts) and their relationships, while the ABox contains assertions about individuals (instances of concepts) using the terms from the ontology. The mapping has three elements: the team-aware organisational metamodel, its instantiation for a specific organisation and the RALTeam expressions themselves.
The mapping of the team-aware organisational metamodel is straightforward: metamodel classes and associations are mapped as concepts and roles in the KB, respectively, and cardinality restrictions are mapped as axioms. There is only one consideration to this mapping. In the metamodel, the relationship between Person, Team and TeamRoleType is modelled with class TeamRole. However, DLs allows a more convenient way of expressing such a relationship by using hierarchies of roles. Therefore, in this case the mapping involves adding a role hasMember from Team to Person and defining each TeamRoleType as a new subrole of hasMember. In addition, a new role roleType is added from Team to TeamRoleType. 
The mapping of the instantiation of the metamodel is done as follows. In this case, class instances and their relations are mapped as individuals and relations between them except for TeamRole instances, which are mapped by means of hasMember subroles as described above. In addition, the mapping should include assertions that explicitly state that each individual has exactly the roles specified and no more (e.g. Team Perm_RE_1 has exactly two hasMember relationships). This is a technical detail that is necessary to deal with the open world assumption of \dls. The open world assumption means that \dls assume that the knowledge may be incomplete and, hence, the absence of a role assertion stating that hasMember(Perm_RE_1, Jane) does not mean that Jane does not belong to team Perm_RE_1. 
Finally, RALTeam expressions are mapped into DL concept descriptions. These concept descriptions are all subconcepts of Team and are defined in a way such that the following condition holds: 

Teams defined by RALT eamExpr ≡ individuals(map(RALT eamExpr))  where individuals is a well-known DL operation that returns all the individuals that are instances of a DL concept and map is a function that maps RALTeam expressions to DL concept descriptions. This means that all RALTeam expressions can be formulated in terms of DLs and automatically resolved by means of a DL reasoner. The tables below detail the mapping for most RALTeam expressions. Expressions that involve RALTeam Member require an additional mapping (see the table on PeopleSelection) to obtain DL concepts from people selection expressions. All of these mappings have been tested using the HermiT OWL reasoner. Furthermore, a proof-of-concept application to automate them has also been implemented using Java and the OWL API. 

Testing RALTeam

RALTeam semantics has been tested by constructing the KB and resolving all the types of expressions the language allows defining. An application to test the resolution of the RALTeam expressions in an easier way can be downloaded from here: