Interactive Activities are assigned to participants - roles or organizations. Users assigned to these roles or organizations perform the work represented by an activity instance. Being assigned one or more activity instances, a user can perform these activities by completing the work items in his worklist.
Hence, there is a distinction between
Consequently, in your modeling environment you use roles and organizations. Individual human performers are created and assigned to these roles in the Infinity Process Platform Portal or console administration tools or via embedding application.
Please refer to chapter Participants and Users in the Concepts section for general details on participants and users.
The following sections describe the usage of participants in the Process Workbench:
The following participant types are provided in the Process Workbench:
Participants are represented in the Outline view as in the following figure:
Figure: Representations of Participants in the Outline View
In the diagram canvas, participants and their organizational structure are represented as displayed in the following screenshot:
Figure: Participants represented in a Diagram.
To create a participant you can either:
Figure: Create a participant from the diagram toolbar
Figure: Create a participant from the outline tree
Figure: Create a participant from the model outline
If you delete a participant, you must make a distinction between deleting a participant from the model information or only deleting its symbol from a diagram. To do the first - delete an organization from the model - you proceed as follows:
Figure: Delete participant from diagram
To only remove a symbol of a participant from a diagram canvas, right-click the participant symbol and select Delete Symbol.
Figure: Deleting a participant symbol
To edit the property page of a participant right-click its symbol and select Properties or simply double-click the symbol. The following properties are available for participants:
The General properties section for participants contains:
IDs for participants have to be unique within all model participants like roles, organizations or conditional performer. When trying to add a duplicate ID, this is indicated in the participant properties page:
Figure: Duplicate ID indicated in Properties Page
The Problems View also shows the following error entry:
Figure: Duplicate ID indicated in Problems View.
For further restrictions and general details on model element identifiers, please refer to chapter Model Element Identifiers of the Key Concepts.
You can define the cardinality of roles in the properties dialog. Type in the maximum users that can be assigned to this role in the Cardinality entry field.
Figure: Setting the Cardinality
Binding properties are available for organizations and conditional performers:
Controlling parameters are different for roles and organizations.
The following controlling parameters are provided for roles:
Figure: Controlling parameters for roles
You can set a Cost Center controlling parameters for organizations.
Figure: Controlling Parameter for organizations
In the properties dialog of organizations and roles you can choose how the task assignment is performed:
Figure: Task Assignment of an organization
In this section you can specify simulation configurations, as described detailed in chapter Simulation Configurations of the Infinity Process Platform Simulation Guide.)
In this section you can set the role, organization or conditional performer complexity for project effort calculation:
Figure: Effort Planning Property of an organization
Please refer to chapter Project Effort Calculation for detailed information on this functionality.
It is possible for organizations to add a department scope which is evaluated at runtime. This department scope is described as a data path to process data which returns a scope key to identify a department representing this scope.
In the Department Binding section you can determine that the organization is allowed to support departments by enabling the checkbox Organization supports departments.
Figure: Department Binding
Once the checkbox is enabled, a new field opens, where you can enter data for the department OID. It is possible to select one of the following two data types:
the data path should be an element (type String) of the structured data and not be using methods as dereferentiation path.
Settings for runtime binding determine how to evaluate the conditional performer at runtime to identify the actual performer.
As described in section Conditional Performers of chapter Participants and Users, the OID or respectively ID of the performer assigned dynamically at runtime is passed to the Infinity Process Platform resource.
Among the conditional performer's properties, there is also the distinction between an individual user of the runtime environment and a performer defined in the modeling environment (corresponding to a role or organization) used as a conditional performer. This distinction has to be made in the same properties dialog. Click Runtime Binding to define the performer as a user, organization/role or user group and choose the data and optional data path to provide the performer's identity.
In the Kind drop-down list, define the performer as one of the following:
Figure: Specifying a Conditional Performer
In the OID/Id section, choose the data and data path providing the performer identity.
Figure: Conditional Performer
In case the data is of type Long, the value is used to identify the OID of the performer, as thus it refers to a user. If the data is of type String, the value is used to identify the Id of the performer, as this has to be a role in that case.
If the conditional performer is defined as a user, an additional field appears to
fill in the users realm
Figure: Specifying a Conditional Performer as User
The Last Activity Performer data usage determines that the performer is used as a computed value. The algorithm for a specific process instance is as follows:
Please note that in case the activity is the first activity in the work flow, there would be no Last Activity Performer. If an activity other than the first one is unable to retrieve the last activity performer due to the transaction isolation level COMMITMENT, set in the database, enable the Fork on traversal flag in the transition between the current and the last activities. Please refer to section Activity Thread of the chapter Runtime Behavior for detailed information on the Fork on Traversal functionality.
Note that it is not possible to assign a conditional performer to a manual trigger!
Organizations are groups of human resources. Consequently, they may contain individual roles or subordinate organizations. Like process definitions, organizational hierarchies can be modeled in the Infinity Process Workbench with the help of diagrams.
To model your organizations, use either diagrams bound to a process definition or model diagrams. A prerequisite for establishing relationships between an organization and its members is the existence of these elements: an organization and all its members (roles or smaller organizational units). Proceed as follows:
Figure: Making an organization part of another
To add further members to the organization, repeat these operations for each member. An example of an organizational hierarchy diagram is shown below.
Figure: A sample organizational diagram
The following sections describe the restrictions on associations between organizational elements.
Please note that a model participant can only have one relationship like Work For or Manager of to other participants. Otherwise the model validation fails and the following error message appears in the Problems view:
Figure: Error indicated in Problems View
An organization should not be part of more than one other organization. Otherwise the model validation fails and the following error message appears in the Problems view:
Figure: Error indicated in Problems View
A role can be assigned as team leader to an organization. Please refer to the section Teams of chapter Participants and Users for a detailed description on the definition of a team.
There can only be one team leader per organization. In case no team leader is associated to an organization yet, you are offered the following two types of connection:
The Works For connection is a simple assignment of a role to an organization, whereas the Manager Of connection defines the role to be the organizations team leader.
Figure: Connecting a role as team leader
The connect transition between a team leader and an organization is displayed as a dashed line.
Figure: Connect transition between team leader and organization
In the Control Center Perspective of the Infinity Process Platform Portal, the team leader has an overview over the activities of all users belonging to the same organization the team leader belongs to.
In case an organization has an invalid team leader connection, e.g. it has a team leader connection, but the team leader is not set in the model file, an error indicates this in the Problems View.
Figure: Connection Error displayed in the Problems View.
You have the option to use the provided Quick Fix functionality for quickly fixing this error. Right-click the error entry and choose the Quick Fix option in the drop-down menu.
Figure: Select Quick Fix to fix the Error.
The Quick Fix dialog opens, where you can fix the team leader connection for the organization.
Figure: Quick Fix Dialog
If you assign an organization to an activity or manual trigger all users assigned to this organization or one of the Works For/Manager Of roles are allowed to perform this task.
The following example demonstrates how to assign processes implicitly to roles in an organization. In the example we have two processes named P1 and P2. P1 reads data while P2 also updates data. We create two participants, e.g. Manager and Teller. We like participant Manager to be able to perform both processes (reading and writing data), while participant Teller should be restricted to perform P1 only (reading data only).
To achieve this, we define an organization Org A and connect the roles Manager and Teller.
Figure: Example organizational structure
Then we assign organization Org A to the activity to read data in P1.
Figure: Workflow diagram of P1
And finally we assign role Manager to the activity to read and edit data in P2.
Figure: Workflow diagram of P2
After deploying the model and assigning users to the roles Manager and Teller, we see that the user assigned to role Teller can only start process P1, whereas the user assigned to role Manager has both processes, P1 and P2 in his worklist. Roles Teller and Manager get the permission to perform P1 via their assignments to organization Org A. As P2 is connected to role Manager, only this role is allowed to perform it.
Infinity Process Platform supports scoping of roles, organizations and departments. The following sections describe what happens when the organizations are scoped.
Roles are implicitly scoped via the next scoped organization above.
When a User is assigned to an (implicitly) scoped role, the role and the departments for all organizations, the role has a "Works For" or "Is Manager Of" relationship, have to be specified.
All organizations and roles underneath a scoped organization inherit the target departments of this organization, as long as the sub-organization does not define a new target department. Hence, for every participant the relevant target department is the scope of the next scoped organization upwards the organizational hierarchy.
Infinity Process Platform only allows pure tree structures for organizational hierarchies. Neither roles nor organizations may be assigned to more than one organization. Matrix structures can be mapped by disjoint organizational structures with possibly different scopes (e.g. branch vs. project), whereby users might be assigned to roles in both structures.
Infinity Process Platform supports the matrix organization structure at runtime. While modeling, you cannot model the matrix structure completely. The matrix organization structure can be achieved at runtime using the process portals. You need to create departments in the Administration perspective to make a complete matrix structure.
The following diagram displays the sample structure created at modeler level. In the organization structure diagram, we have four organizations - M1 Project Orga, M2 Project Leader Orga, M1 Test Orga and M1 Development Orga. Each of these organizations has roles defined. The M1 Project Manager is the manager of M1 Project Organization.
The M3 Project Member works for M2 Project Leaders Organization. These two organizations - the M1 Project Organization and M2 Project Leaders organizations are connected. The M2 Test Engineer Organization works for M1 Test organization and M1 Test Manager is the manager of the M1 Test Organization.
We cannot connect one role to multiple organizations directly. That's why we need to create departments and assign users to roles. To achieve the same scenario, three red arrows are used to indicate that you need to create department Project A in the M1 Test organization and department Project A and Project B in the M2 Leaders Organization.
Figure: Sample model for matrix organization
Note that restrictions exist for deploying a model with changes in the department association for existing roles or organizations, to a succeeding model version. Please refer to section Changes in the organizational structure of the Consistency Checks part in chapter Deploying a Workflow Model for detailed information on which changes are supported and which will lead to a consistency error.
When a provider-consumer relationship is established between two models, the participants of the provider model can be referenced in the consumer model. To reference the participants, perform the following steps:
Figure: Participant Available for Reference
When you drag-and-drop the referenced participant the reference is created and the referenced model participant appears in the locally defined model participant.
Figure: Participant Available for Reference
For more information, please refer to section Referencing Model Elements of the External Model Resources chapter.
Note that if a participant with an identical ID already exists in the consumer or referencing model then you cannot refer the participant of the provider or referenced model. Similarly, you cannot create a participant in the consumer model, if a participant with an identical ID is in use as a reference from a provider model. In such a case, a model validation error is displayed.
For more information, please refer to section Consistency Checks of the Deploying a Workflow Model chapter.
Also, the following dialog is displayed in case the referenced participant ID is identical with the consumer participant and you try to drag and drop the referenced participant. If you click OK, only the selected element is imported by reference. If the organization has sub-organizations, then those sub-organizations do not get imported by reference.
Figure: Conflict - Replace