The available roles are listed under the list item “Roles” in the Administration Client. The default system roles include the administrator, deployer, guest, member, processdesigner, processmanager, rulesadministrator and starter. The administrator can create additional system and business roles (see Administration). Business roles can be assigned to users within a group and are used solely for administrative purposes.
Right/Role | Description |
---|---|
Administrator | The role “administrator” grants access to the Administrations Client, where the general properties can be managed (e.g. user and group administration). |
Deployer | The role “deployer” enables the user to deploy process definitions to TIM. |
Guest | The role “guest” grants the user no rights |
Member | The role “member” grants the user general access to TIM as well as the ToDo Client. The role “member” is obligatory for every user. |
Processdesigner | The role “processdesigner” grants the user access to the Process Repository. The Process Repository enables the user to deploy and administer process definitions without a modeling software. |
Processmanager | The role “processmanager” grants the user access to the Process Manager Client. The Process Manager Client enables the process manager to control and monitor processes. |
Rulesadministrator | The role “rulesadministrator” enables administrators to create rules matrices in the Administration Client. Rules matrices can be used to map/illustrate rules within a process (i.e. approval of monetary upper-limits) |
Starter | The role “Starter” enables the user to start process instances of assigned process definitions. |
Smartform-designer | The role “Smartform-designer” enables the user to access the TIM Smartform Suite with the lowest complexity level “designer”. |
Smartform-architect | The role “Smartform-architect” enables the user to access the TIM Smartform Suite with the medium complexity level “architect”. |
Smartform-expert | The role “Smartform-expert” enables the user to access the TIM Smartform Suite with the highest complexity level “expert”. |
dashboard-user | Can log into the dashboard and change widget variables. |
dashboard-manager | Can log into the dashboard, see the list of widgets, add widgets in the dashboard, delete widgets in the dashborad, change widget variables, change locked widget variables, create new dahsboards, release dashboards and change dahsboard layouts. |
dashboard-admin | Has the same rights as the dahsboard-manager and additionally can create console widgets, change widget varibales and change widgets. |
The role member grants access to the ToDo-client. In the ToDo Client, the user can work on assigned tasks.
The role processmanager grants access to the Process Manager Client.
Therefore the role processmanager grants the following additional rights:
In the administration client it is possible to create Business Administration roles. For this, the role of “Team Manager” takes on a special meaning. With this role, the user may define one or more users as “Team Leader” for a given group. A Team Manager has the ability to assign. In contrast to the assignment-function of the Owner, the Team Manager may not pass a task to any group; rather, tasks may only be assigned to a user within the current group. If the role “Team Manager” is generated in the system by default, Step 1 may be skipped.
1. (Only need to be completed if the roles have not yet been created. In the standard system the roles are already created.) In the first step, the roll “team manager” has to be created. For this, it is important that the exact notation must be held. (to create new roles: see administration) 2. In the second step, this role must be assigned to one or more users. For this, the desired user is selected from the list of group members. A window then appears, in which newly created role must be selected.
3. Now, the team manager can complete the assignment of a task to a member within his/her group.
—–
The context roles are similar to the system roles; however, they are completely dissociated from one another. Context roles are always related to a single process or an instance and allow the user to influence a process with expanded rights. Currently, the following roles exist:
deployer | The group/user who is designated as deployer in the process model is given the ability to deploy a new process version. |
---|---|
participant | All users within a group are given the rights of a “participant if the group has an active task, has been assigned a task within a process, or is assigned to a Swimlane. If the swim lane or the task is assigned to a specific user rather than the group, than the participant rights are also given. |
starter | The group/user, who is assigned as the starter in the process model, receives the ability to start the process. |
owner | The holder of a process is designated as the owner. The owner may, for example, assign tasks to arbitrary groups or users, archive instances and view all instances of a given process. |
—-
In order to show the difference, here are two examples showing the differences between the system- and context roles. All examples pertain to a process by the name of “Wikiprozess”
User Wiki has the following rights | |
---|---|
System Role | Context Role |
Starter, Member | Participant |
<note> With the system role, the user “Wiki” can start processes; however, because he does not have the rights of a “starter” in the “Wikiprozess” process, the process does not appear in his list of to-be-started processes.</note>
User Wiki has the following rights | |
---|---|
System Role | Context Role |
Member | Owner, Participant |
<note>Because the right as “process manager” is not given, the user can only log himself into the ToDo-Clients. However, there he can manually assign tasks to a new group/user or archive entire instances.</note>