Participants and Users

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.

Roles and Organizations

Participants are either organizations or roles, whereby:

In Stardust , roles and organizations are visualized by icons showing a pictogram of one or two persons respectively.

As a model element, participants have the following properties:

Administrator Role

An administrator is a default role in Stardust . 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 Stardust 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.

Hierarchical Relationships

Stardust allows defining hierarchical relationships between both roles and organizational units:


Figure: Relationships between roles and organization.

Works-for / part-of connection

Manager-of connection

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.

Super Organization

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

Teams

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:

  1. a team for TeamleadRole1 as manager of Organization1.
  2. a team for TeamleadRole2 as manager of Organization2.

The team of TeamleadRole1 comprises the following users, roles and organizations:

The team of TeamleadRole2 comprises the following users, roles and organizations:

Teams and Departments

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.

Executing Participant / Default Performer

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.

Workflow Users

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 Stardust runtime environment.

Grant

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 Stardust Installations chapter.

Grant Propagation

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.

Deputies

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 Business Control Center perspective or in the Configuration Panel of the Stardust Portal. For details refer to the following chapters in the Stardust 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.

Current Performers

An interactive activity instance is intended to be executed by a human. In the Stardust 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

Manual Triggers

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.

Conditional Performers

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.

The icon to visualize a conditional performer is a person pictogram in brackets decorated with an equals sign.