Running Role-based Applications
In role-based applications, roles are assigned to individual users. Each of these roles is associated with special rights. These decide which actions the respective user can perform, which data he or she can display and edit.
Have a look at the ACME Idea Management process:
In this model, each Lane represents a company role. The process is spread over multiple lanes. Each role has access to the part of the process that resides in their lane.
The following users with different roles are involved in this process:
Name | Role |
|---|---|
David Stringer | ACME Employee |
Irene Adler | ACME CEO |
Jane Marple | ACME Manager |
In the first step of the idea management process, ACME employee David Stringer creates a new instance by reporting a new idea:
For more detailed information on how to create a process instance, refer to Creating a Process Instance.
As soon as ACME Employee David Stringer sends his idea, the second process step is triggered and he returns to the instance list:
In role-based applications, role labels are displayed above the Instances header - one for each role assigned to your user:
In this case only the role ACME Employee is assigned to David Stringer.
In addition, the role labels also have a filtering function. Click a role label to display only the instances associated with that role in the instance list.
After David has sent his idea, his instance list is empty. Sending the idea has triggered the second process step for which David's role ACME Employee has no access rights.
The second process step Check idea starts immediately after the employee has sent the idea. Only role ACME CEO is assigned to this process step:
Now, Irene Adler opens the process. She is not only ACME Employee but also ACME CEO. This is reflected by the labels displayed on top of her instance list:
Accordingly, in her instance list she can see the running process instances of the process steps that are assigned to her roles:
In her role as ACME CEO she needs to check all ideas. The idea that David created in the first process step is displayed in her instance list and she can now open and read it.
If Irene rejects the idea, a rejection mail is sent and then the process is finished. If she approves the idea, an approval mail is sent and the process step Enter instructions for realization is automatically initiated. Again, only Irene in her role as ACME CEO is involved in this process step:
Irene has approved David's idea which is now in process step Enter instructions for realization:
As soon as Irene has entered and sent the instructions for realization, the process step Show instructions for realization is triggered. This process step is only assigned to the role ACME Manager:
Accordingly, David's idea is no longer visible in Irene's instance list:
Instead, it is now listed in the instance list of manager Jane Marple. Jane is not only ACME Manager, but also ACME Employee which is reflected by the labels displayed on top of her instance list:
Jane can now open the instance to read Irene's instructions to realize David's idea:
