Compound Organization Hierarchy

The objective of this tutorial is to address a common problem related to rights faced by process designers.

When assigning manual tasks within a process, there are 3 options :

Task must be assigned to one person defined by a variable. In this case, you insert the variable name related to assignee's email address ${waiting_for} in "Assign to" field.
Task must be assigned to one person or a group of people previously defined. Among these people, the first responder will be the task updater. In that case, you must create a dedicated Entity or Role and insert these people into it. On process side, you shouldn't complete the "Assign to" field.
Task must be assigned to a group of people not previously defined: the group is defined directly in the process, depending on the attributes related to the process as well as the attributes related to users (i.e. User's metadata). In this case, this documentation proposes you a "Best Practise" based on two technologies - Dynamic Lanes and Scripted Lanes, nested to each other.

This solution allows us to use the possibilities of RunMyProcess to answer to the customer's exact need. Imagine the following scenario: we have one manual task and multiple assignees that depend on the process attributes, as well as User Metadata and belonging lanes (refer to the image below).

The two technologies we provide are the following :

Dynamic lanes that allow you to select a group of assignees, depending on the variables within the process. However, it will be needed to respect the lane determined by the dynamic lane.
Scripted lanes that enable you to auto populate lanes based on Users' Metadata and lane belongings. However, there is no possibility to link in process attributes.

Example :

In a cost validation process, we have a manual task that must be assigned to an Accounting department of a specified country/entity. Let's assume that the country is specified in the computed parameters of the Process Instance.

In your process design, insert the box related to the manual task into a "DYNAMIC ROLE".
Via a "SWITCH" script (inserted in "Assign to entity" field), you will define the dynamic role that decides which entity to address (directly country related entities).

Code:

<#switch COUNTRY>
    <#case "FRANCE">
        109371 <#-- Entity ID -->
        <#break>
    <#case "SWITZERLAND">
        109372
        <#break>
    ...
    <#case "BELGIUM">
        109374
        <#break>
    <#default>
        150832
<#switch>

These entities will all be "SCRIPTED LANES" where the associated script will look like :

Script:

${DIVI=="BELGIUM" && is_user_n_lane(1234)}

<#-- where DIVI is User metadata attribute and 1234 is "All Accounting - Accounting global" role associated to all accountants whatever the country -->

Finally, make sure you take into account the following :

"All Accounting" roles must be maintained by somebody into the organization
Users must be populated considering the metadata "DIVI" which is equal to a country name