Participants are in most cases human resources which perform the work represented by an activity instance. Being assigned one or more activities, a participant can perform work items representing these activities by working off his worklist. A convenient way of modeling the resource assignments is to assign a role or an organization to each activity and let individual humans fill this role or belong to this organization. Also, both individual humans and roles can be assigned to one or more organizations.
Among participants, individual humans have a special status. You cannot change your business model each time an employee leaves your company or a new one enters. So humans must be created later in the runtime environment. Consequently, in your modeling environment you only use roles and organizations. Individual human performers are created and assigned to these roles and organizations in the Administration Perspective.
We will create a role of a call center agent to model the performer for the activity of case creation. Additionally, we will create a role of an engineer to model the performer for the activity Analyze To Solve. Then, we will create and associate an engineering organization with the remaining Deliver Patch activity we have modeled.
Roles capture the workflow relevant properties for a performer of an activity or a collection of activities and provide a mechanism for associating participants with these activities. Each role must be both assigned to an activity and filled with human resources (users) to finally take part in the process. To create a role:

Figure: Setting the properties of the new Role.
Repeat this step to create the Engineer Role. Place the second created role near the Analyze To Solve activity.
A role establishes a connection between an activity and its performer, so it has to be connected to an activity on one side. On the other side it has to be resolved as explicit human-role assignment in the user managing facilities of the Stardust Workflow Execution Perspective.
To assign the role of the Callcenter Agent to the Create Case:
Figure: Assigning a Role to an Activity
We will later assign a user to the role in the Stardust Administration Perspective.
Also assign the role Engineer to the activity Analyze To Solve.
Since the definitions of organizational units in an enterprise, like hierarchies of participants, refer to the entire model, we can use a model-bound diagram to define such structures. Any diagram at the model level could be used, and some modelers create a specifically named diagram for their organization (by choosing New Diagram on the context menu of the Model). However, another popular convention with Stardust is to simply use the default model diagram as shown below.
In the Outline view click the Default Diagram of the ACME Workflow Model.
Figure: Choosing Model Default Diagram
A blank diagram is opened in the diagram display area. Create a new organization in this diagram.
Figure: Creating an Organization
Since we want the organization to represent the general organization of ACME Headquarters, the name and ID of the representation has to be changed. Change the properties of the organization you have just created:
ACMEHeadquarters.Your process model now contains the role Callcenter Agent and Engineer as well as the organization ACME Headquarters. There are no relationships between any of these model components. We want to assign both roles to the headquarters organization.
Figure: Assigning a Member to an Organization
A list opens where you have to choose between Works For and Manager Of. Select Manager Of to make the Callcenter Agent role the team leader of the organization ACME Headquarters. Please refer to the section The Team Leader Role of the chapter Modeling the Organizational Structure for detailed information on the team leader role.
Now a connection between the organization and the role appears in the diagram as a visualization of the relationship between the two elements. Assign also the Engineer to the ACME Headquarters.
Figure: Organizational Structure
Now switch to the Support Case Management Process default diagram and assign the remaining activity Deliver Patch to the newly created organization:
Your diagram of the ACME support case management process should look like the following now:
Figure: The Support Case Management Process modeled in Stardust
! Tip: Stardust diagrams adhere to the
BPMN (Business Process Modeling Notation) standard. The standard specifies how
various model elements should appear on a diagram. In this tutorial, all the elements are
shown on the diagram. Stardust also permits the designer to construct a process
definition with fewer modeling elements visible. For example, you can define participant
roles, data, triggers and applications in the Outline view and use them in the
properties dialogs of activities and transitions without showing them on the diagram.
This approach does not document the process as thoroughly on the diagram, but may be
desirable for some solutions. Stardust diagrams with fewer model elements visible
are still BPMN compliant, but convey less process detail in the diagram itself. In
all cases, every model element must be defined in the Outline view or it does not exist.
Activities, transitions and split-join gateways, at a minimum, are expected to
appear on the visible diagram.