Workflow Process


The Workflow Design section of RPM allows users to create Workflow containers and define workflows. These containers include WorkflowGroup, WorkflowCategory, and WorkflowProcess. The configuration of a WorkflowProcess defines the steps the workflow undergoes once it is running. Workflow Design is not available in this version of the API.

The Workflow Process section of RPM allows users to manipulate WorkflowProcess containers created in Workflow Design. The API allows the user to load previously defined workflow containers and manipulate them. This includes associating workflow processes to projects as well as scheduling, starting, suspending, resuming, and cancelling workflow processes.

As shown in the UML diagram labelled Diagram 1, the API defines three concrete workflow containers:

A WorkflowGroup is predefined. In order to map a workflow process to a particular type of container, it must be defined in the appropriate workflow group. For example, to map a workflow process to a Defect container, it must be defined in WorkflowGroup ‘Defects’. A WorkflowGroup has no valid parents and can have children of type WorkflowCategory.

A WorkflowCategory container categorizes workflow processes within workflow groups. A WorkflowCategory must have a parent of type WorkflowGroup and can have children of type WorkflowProcess.

A WorkflowProcess container defines a workflow process that can be mapped to one or more containers and manipulated. In order to manipulate a workflow process, it must first be activated.


Once a WorkflowProcess is loaded by the API, it can be manipulated using the following application methods. These methods are described in detail in the API_interfaces document: Interfaces and Methods

A running workflow process executes the steps defined when the process was created. Once all of the workflow steps have been completed, the workflow process is closed.

Once a workflow has been associated to a GenericProject, the WorkflowProcess specified will appear in an AvailableWorkflowProcess object in the workflowProcessesAvailable array in the GenericDocument, WorkElement, or AbstractScope objects contained within the GenericProject specified (depending on the group in which it was defined).

Once a workflow has been started, it will appear in a RunningWorkflowProcess object in the workflowProcessesRunning array in the GenericDocument, WorkElement, or AbstractScope on which it was started. All started, suspended, resumed, and hanged processes are considered to be running.

Workflow Roles

The author of the Workflow Process in design mode need not immediately assign a participant to a workflow step; instead he can define a role which allows the participant to be assigned to the workflow process later on. A Resource, a GenericSecurityRole, and a ContactGroup can be mapped to an existing workflow role once the workflow process is associated to a GenericProject. This allows for different participants to be assigned to the same step of a process in different GenericProjects.

Once a WorkflowProcess has been associated to a project and if the process contains one or more roles, a list of WorkflowRoleMapping containers can be loaded through the list of available workflow processes for a WorkElement, a GenericDocument, or an AbstractScope container. The WorkflowRoleMapping can then be populated with a Resource, a GenericSecurityRole, and/or a ContactGroup.