Participants are abstractions of human resources starting processes or performing the work represented by an interactive activity. Contrary to users, they are defined at modeling time and are part of the workflow model.
For details on participants and users in the Eclipse Modeler and the Modeling perspective, please refer to chapter Modeling the Organizational Structure in the Eclipse Modeling Guide and chapter Modeling the Organizational Structure in the Business Process Modeling Handbook respectively.
Participants are either organizations or roles, whereby:
As a model element, participants have the following properties:
Infinity provides a default administrator role, which provides full access to all administrative tasks in the Infinity Portal and via API.
Each model has at least one Administrator role by default. In case of models with provider and consumer relationship, once deployed, the administrator role of all the models is cumulated and presented as only one administrator in the Infinity Process Portal. This administrator has grants of all the deployed models. For example, the administrator can modify user of model A and model B, as well.
Infinity provides a default Auditor role, which gives read-only authorization to view all processing aspects of the workflow in the Infinity Portal.
A user who has the Auditor role has read-only access to all parts of the product. For example he is able to view perspectives, views, workflows, workflow artifacts and documents.
The Auditor role is similar to the Administrator role but it is used to provide participants with read-only access, whereas the Administrator role provides full access.
It is available in the Portal for user assignments in the Participant Management view and all other views where authorizations are managed. Please refer to chapters Associating Users with Roles or Organizations and Managing Authorization in the End User Handbook for details on the usage of the Auditor role in the Portal.
Infinity Process Platform allows defining hierarchical relationships between both roles and organizational units:
Figure: Relationships between roles and organization.
The Manager Of connection is a works-for relationship between a team leader role and an organization. An organization can only have one team leader role assigned. This connection is rendered as a dotted line.
Cyclic relationships are forbidden. Choosing a participant and traversing the relationships upwards will result in the set of super organizations of the chosen participant (note that roles are always leaf nodes in the relationship graph).
In the figure below, the role Role1 has the following super organizations:
The Organization1 has the following super organization:
Figure: Role with Super Organizations
A team is defined by the team lead role (see Manager-of connection), managed roles, the immediate organization and their users. Teams also include all elements down the tree from the immediate organization but exclude elements higher up the tree.
The following example demonstrates how a team structure is defined:
Figure: Example hierarchy demonstrating a team.
In this example, two teams are defined:
The team of TeamleadRole1 comprises the following users, roles and organizations:
The team of TeamleadRole2 comprises the following users, roles and organizations:
In case departments are implemented, each department defines the boundary of that team. All team concepts described above apply.
For the default department, the boundary is the default department. Participants outside of the default department are not considered to be part of the team.
An interactive activity in the workflow model has to be associated with a participant, the so called executing participant or default performer. This means that
Only one participant can be chosen as executing participant.
Whereas participants are part of the model they have no human identity. Individual (workflow) users are defined later in the runtime environment. The most basic feature of a user is that he/she can login to the Infinity Process Platform runtime environment.
A user is associated with a deployed workflow model by associating it with participants from this model. An association between a user and a participant is called a grant. Conceptually, this means that the user becomes part of this participant (role or organization).
Users and grants can be managed in two different ways:
Details of the user management are covered in the Administrative Concepts, or the User Management section of the Managing Multi Partition Infinity Process Platform Installations chapter.
When a new model is deployed there would initially be no grants for this new model. The process engine resolves this issue by replicating all grants, which still make sense in the new model from the previously active model to the new model. This process is called grant propagation and takes place during model deployment.
A user has the options to transfer authorizations and workflow tasks to another user who will be in charge of performing these tasks for a limited time. This user is called the Deputy of the other user.
Deputies can be defined in the Deputy Management view in the Control Center perspective or in the Configuration Panel of the Infinity Portal. For details refer to the following chapters in the Infinity Portal documentation:
In the worklist tree of a user, the user can also see the worklist of users he is deputy of. This is described in section My Assignments of chapter Using Launch Panels.
An interactive activity instance is intended to be executed by a human. In the Infinity Process Engine an interactive activity instance is always associated with a concrete participant or user. This associated participant or user is called the current performer. An associated user is sometimes also more specifically called the current user performer. The current performer relationship is used to build worklists (see below).
A current performer has to have the grant to execute the activity, which means:
When an activity instance is activated the activating user is set as the current performer. The activity instance is then locked for exclusive usage by that user. This lock can only be released by
Besides the usage of grants for current performers there is another use case in manual triggers: A process definition appears in the list of startable process definitions for a user if the process definition has a manual trigger with an associated participant the user has a grant for.
Roles and organizations in its plain form set up the association between an interactive activity and its executing participant at modeling time. This is not possible if the runtime behavior of a process instance dynamically determines the performer of an interactive activity. A conditional performer is used in such situations instead of a participant. Conditional performers are assigned to activities in the same manner as static participants.
As a model element a conditional performer has the following properties:
At runtime, the conditional performer (i.e. its workflow data accessor) is evaluated and determines the identity of the actual performer (user or participant - as specified in the model). This is done at activity instance creation time.
Note that it is not supported to assign a conditional performer to a manual trigger!
Participants have permissions assigned for specific model elements and operations. These permissions are assigned by default, but you can change them in the Eclipse modeler and the Modeling perspective as well as in the Authorization Manager of the Portal. For editing authorization in the Eclipse Modeler and the Modeling perspective, please refer to chapters Setting Authorization in Model Element Property Pages of the Modeling Guide and Setting Authorization in Model Element Property Pages of the Business Process Modeling Handbook accordingly.
In the Authorization Manager, you also have the option to deny authorizations by adding a participant to the Deny permission node. The Deny option denies a specific operation on a model element for the assigned participant. Please refer to chapter Managing Authorization in the End User Handbook for details on setting authorization for participants in the Authorization Manager.
The following default participants settings are used for authorization assignment in model elements in the Eclipse Modeler and the Modeling perspective:
The following rules apply for combining allowed and denied Authorization defined per model element and per tenant: