Configure Processes

HID_admin_configure_processesProcesses automate repetitive steps that you perform manually through the user interface. To reproduce real behavior, a process impersonates a user when performing the steps. Each process defines its objects, steps, actions, groups of steps, and joins. 
ccppmop144
HID_admin_configure_processes
Processes automate repetitive steps that you perform manually through the user interface. To reproduce real behavior, a process impersonates a user when performing the steps. Each process defines its objects, steps, actions, groups of steps, and joins. 
A process includes a series of steps that end with a specific result. All processes have a start and a finish step. Each step can perform one or more actions. Processes use preconditions and postconditions to connect their steps. You can create processes to act on any object type.
2
Process Example: Conditional Automatic Approval
Clarity Project and Portfolio Management (PPM)
 includes one sample process, named
Conditional Automatic Approval
. This process sends a notification to the project manager when a resource submits a timesheet. The project manager must have the 
Resource - Approve Time
 instance access right for the resource. This process automatically starts when a resource submits their timesheet.
This sample process is not active by default. You must manually activate it. You can also customize this sample with more business rules and approvals.
Processes and Object Types
A process can work with the following types of objects:
  • Primary. 
    You can add only one primary object to a process, but you can add multiple linked objects to a process. A project is an example of a primary object.
  • Linked. 
    Linked objects, which create links in the product, are objects which the specific attributes of a primary object reference. Use linked objects to access data between two objects when building rules, or action item messages for step conditions and actions. Some examples of linked objects are object lookups, parent objects, or grandparent objects. Before you can add a linked object to a process, associate a primary object with the linked object in Studio. Then, while defining a process, you can access a list of available linked objects for a primary object. After you add a linked object to the objects list, the manual and system actions and conditions can use the linked object attributes in steps.
When adding linked objects to a primary object, you cannot select Multi-Valued Lookup (MVL) attributes. In addition, you can only link a linked object to the primary object or a top-level linked object. When deleting the primary object, all linked objects that are associated with the primary object are also deleted.
  • Implied. 
    An implied object is a type of linked object that is added to the process list automatically due to a direct relationship with the primary object. Other parts of the process definition reference an implied object, such as when using the Object Mapping or the Object Conversion APIs. You cannot add or delete an implied object.
Process Flow Diagrams
Process flow diagrams show each step in a process and its relationship to prior and subsequent steps. If subprocesses are included, the initiated process appears hierarchical and the subprocesses display with their completion modes. You can expand the hierarchy to view information about a specific subprocess. Click a subprocess in the flow diagram to navigate to its properties page. If an error or warning appears, it is propagated to the top-level (master) process so you can investigate and troubleshoot the subprocess.
The following image shows a sample process flow diagram for the Project Manager Approval process:
Image showing a sample process flow diagram for the Project Manager Approval process.
All process flow diagrams have the following characteristics:
  • An element description appears when you hover over an element.
  • A square-bordered plus sign identifies a sub process.
  • All action items are included with angle braces ( < > ).
  • All sub processes are included within square braces ( [ ] ).
  • All steps appear in tan color and the actions within those steps appear in red, yellow, or green color depending on their status.
    • When a step is running, the action item boxes are red, yellow, or green and the space around the action item boxes is tan.
    • When a step is completed successfully, the action item boxes are tan and the space around the action item boxes is green.
    • When you click in a step, you see the step properties.
When you drill down from a run-time process flow diagram, the run-time instance of the process appears. If the process flow diagram settings are configured to show actions, a drill-down on the action takes you to the action page. When a process is active, the following colors indicate the status of each step:
  • Green
    : Complete
  • Yellow
    : In process
  • Red
    : A problem exists
  • Blue
    : Ready to start, but waiting for a preceding action
  • White
    : Not yet started
Configure Process Flow Diagram Settings
When you configure the process flow diagram settings, the new settings apply to all the available processes. At any time, you can click Restore Defaults to overwrite your changes and restore the default settings.
Follow these steps:
  1. Open a process and click Process Flow Diagram.
  2. In the upper right corner, click Settings.
  3. Specify the process flow diagram settings. 
  4. Click Save and Continue.
Processes Object Roles
When you create a manual step action, you can select object roles, system roles, groups, resources, or resource fields. This step action helps to send notifications about action items to which the object role is assigned. A step action has zero, one, or many object roles that are associated with the process. The list of roles depends on the associated object. If a process has more than one associated object, you can select object roles for each of the objects.
Project Object Roles
The following roles are available for the Project object:
  • All Child Managers
  • All Parent Managers
  • Immediate Child Managers
  • Immediate Parent Managers
  • Manager
  • Participants
  • Staff
Processes Objects and Partitions
You can assign an object to a partition model in Studio. If you use this object in a new process definition, you can configure a partition and a partition association mode on that object. The partitions determine what process definitions are available to which users from the user interface. Depending on whether you defined a partition model for an object in Studio, you can perform the following actions when creating a process:
  • Select no partitions, or select from different partitions, for a primary object. If you assigned a primary object to a partition model, select a partition and a partition association mode for that object.
  • Select no partitions, or select from different partitions, for a linked object.
  • Add a linked object to the process through parent or grandparent relationship to the primary object. The association with the process displays the partition of the linked object as the partition of the primary object.
    If an implied object automatically appends to the process, the product determines its partition. If an implied object appends through object conversion, the conversion API or the object mapping determines the partition of the implied object. You cannot configure partition association mode for a linked or implied object.
  • Use only the object attributes visible for the selected partition.
  • Use the partition association mode to configure process start conditions. For start conditions based on primary objects, the available attributes follow the partition and association mode that is defined on the primary object. Start conditions can be based on linked or implied objects. In this case, only those attributes exist in the linked and implied objects that match the partition of the primary object.
  • Restrict what process definitions are available to a particular user based on the partition and partition association mode on the process definition. For example, you create the California Project Approval Process with project and the following partition information. The process is accessible only to users in the California partition on these project instances:
    • Partition: California
    • Partition association mode: Partition only
    When users open a project in the California partition, they see only processes where project is a primary object in the partition. If the association mode is a Partition and Descendant, the process is available in both the California partition and the descendant partitions of California.
  • Change the partition and partition association mode of an object in an active process. You can validate and reactivate the process.
Processes Roles
You can assign access rights for processes through the resources or the object on which they are supporting. The following roles typically work with processes:
  • Process Administrators. 
    Create, copy, delete, modify, and monitor, or maintain processes that are started by other users. The Process Administrators require the
    Process - Manage - All
     access right.
  • Process Creators. 
    Create processes for objects to which they have access. Start, copy, modify, or delete processes that they have created.
  • Process Initiators. 
    Start processes on objects for which they have access. Modify or address errors on processes that they have started.
  • Process Editors. 
    Modify processes for objects to which they have access. However, cannot create, start, copy, or delete processes.
  • Process Participants. 
    Have no specific access rights to processes. Instead, they participate in an existing process by receiving and acting on action items.
Processes Groups
A group is a collection of steps with the following requirements:
  • A hard requirement completes before the process can advance to the next step.
  • A soft requirement does not prevent the process from advancing to the next step.
View Available Processes
On both available processes and
 
initiated processes lists, template processes that are copied from a project template are linked with the template process in a hierarchical structure. Processes that are copied from a template process are shown as indented children of the master template process.
Follow these steps:
  1. Open Administration, and from Data Administration, click Processes.
    The
     
    available processes list appears displaying processes that you created and are available globally.
  2. Click Initiated
     
    to view the list of process instances.
  3. (Optional) Filter the list of processes by clicking a field name. 
    You can use wildcard characters for filtering. Entries are not case-sensitive. For example, “Acme”, “acme”, and “ACME” return the same results. Complete the requested information. The following fields require explanation:
  • Primary Object
    Specifies the primary object type for the process.
  • Instances Initiated
    Indicates if you want to display the already running processes. 
    Values:
     All, Yes, or No
Monitor a Process Instance
To view process instance comments from the initiated processes page, click the Comments icon next to the process.
Follow these steps:
  1. Open Administration, and from Data Administration, click Processes.
  2. Click Initiated.
  3. Click the process ID to monitor.
  4. Click the step name to view the step details.
Cancel a Process Instance
Start a process instance before you can cancel it. When you cancel a process instance, all actions in the process instance are no longer active. They are removed from each process participant. When you restart the process, a new instance of the process is created. The process starts from the start step (not from the step that was active when the process instance was canceled).
Follow these steps:
  1. From the Initiated Processes page, select the process instance.
  2. Click Cancel Process.
Cancel a Subprocess Instance
At runtime, you can view the subprocess instances in the rows below the master process instance. Each subprocess instance is represented with an icon and shows its state. You can also view the process definition, flow, status, and current step in progress.
You can abort independent subprocess instances explicitly. When you abort a master process, the application also aborts any synchronous or asynchronous subprocess instances.
Activate a Process
Before you can initiate a process, the process must be activated.
Follow these steps:
  1. Open the process to activate.
  2. Click Save.
Run a Process
The processes that you can view, initiate, and filter are based on the partition of the object instance. For example, the object instance partition is within the range of the partitions of the primary object, which is defined by its partition and partition association mode. You can then view and initiate the processes that are based on that object instance. When you start a process, a process instance is created. All process instances to which you have access and processes are displayed.
You can start processes manually or automatically (event-driven). Before you start a process manually, verify this information:
  • You have Process - Manage or Process - Start access right to the specific process.
  • You have explicit access rights to the specific object.
  • Actions, post-conditions, and preconditions are correctly specified.
  • Steps are connected and the status is Validated and Active.
Start a Process
Follow these steps:
  1. Open Home, and from Personal, click Organizer.
  2. Open the Processes menu, and click Available.
  3. Select the process and click Start.
Modify a Process
Follow these steps:
  1. Open the process.
  2. Modify the process as follows:
    • Edit the process properties.
    • Add, edit, or delete primary or linked objects.
    • Edit the start options.
    • Edit steps by renaming, deleting, adding conditions, or altering actions.
    • Add, remove, reorganize, or rename groups.
  3. Save the changes.
  4. Validate the process.
  • You cannot edit a process if it is running or has a status of
    Active
    .
  • Before you can modify a process, the process status must be
    Draft
    or
    On Hold
    . To update a process with content from an add-in or Studio content package, set the process to
    On Hold
    . Running instances are not disturbed. The process definition is updated when the content add-in is applied on the target system. Then, set the updated process back to
    Active
    .
  • If a process is not currently running, you can delete it. If the process is running, cancel before you delete it.
Copy a Process
You can copy processes even if the process mode is 
Active
. If you have an existing process, open and save a copy to create another process.
Follow these steps:
  1. Open the process that you want to copy.
  2. Click Save As.
  3. Complete the following fields:
    • Process Name
      Defines the name for the new process.
    • Process ID
      Defines the unique ID for the process.
    • Content Source
      Specifies the content source for the process.
    • Description
      Defines a brief description of the process.
  4. Click Save and Continue.
Process Step Actions
To take a process from beginning to end, define a series of steps. A step action is a task which a process executes. These steps include:
  • A start step (required)
  • One or more intermediate steps
  • A finish step (required).
Each step can consist of multiple actions.
The following actors can perform an action:
  • An assignee (manual action)
  • The system (system action)
  • A job
  • A script
  • A subprocess
You can add actions when you create a process or you can add them to existing processes. Use the Actions section in the step details page to create step actions.
Step actions can be used in several ways.
  • Notifications and approvals. 
    You can use a step action to either send notifications or receive approvals. For example, you can use system actions to call API functions, set attributes, and lock attributes. When you build a process, you can supply parameters to a stock system action or API, and then add them to process steps. To use a system action in a process, add a step to the process and then supply parameters to the system action for that step.
  • Steps without actions. 
    A step can have no actions or multiple actions. An action in a step can depend on the results of previous actions in the same step. For example, in the following two steps, the actions are independent of each other:
    • Action A1 (manual action): Send action item Approve Cost Plan.
    • Action A2 (system action): Set status of the project to Open.
  • Chained-together actions. 
    Actions can also be chained together so that the execution of an action depends on the completion of others. The results of one action can be input parameters for the next action.
Example: Create a Project Using a Template Process
Create a project template process to create a new project that is based on a specific template. Add the following system actions to the template process to copy over WBS and staff from the template to the new project:
  • Copy WBS from Template. The system action copies WBS tasks and any staff that is assigned to those tasks.
  • Copy Staff from Template. Copies all staff from the template (regardless of whether the staff members are assigned to WBS tasks).
For dependent actions, maintain the dependencies after deleting or reordering actions.
Process Step Action Types
A process can have the following step action types:
  • Manual action. 
    Sends action items to resources, groups, roles, or profiles to which they must act upon for the process to continue. With manual actions, you can associate variables with the subject and body of action item messages. These actions provide users and process designers with relevant context information about the action items to review. They also provide flexibility in defining context within an action item. Manual actions use attribute information from multiple objects and incorporate it in the action item.
  • System action. 
    All these system actions are available for all objects in the process (including primary, linked, implied objects; action item objects):
    • Attribute setters. For example, you can set budgeted benefit, set the department manager, and so on.
    • Lock or unlock selected or all attributes edit them or make them display-only.
    • System Operations. For example, you can copy a financial plan from a template, copy staff from a template, and so on.
    • Object conversion that uses a mapping code to map the attributes from the source object to the target object.
  • Run job. 
    This type runs jobs in the background on a scheduled basis. Jobs can run in synchronous or asynchronous mode. If you call a SQL job from a process, pass the following required parameters in order:
      
    P_PROCESS_INSTANCE_ID, P_STEP_ACTION_ID, P_STEP_INSTANCE_ID
  • Custom script. 
    Executes to import or export data from an external system. Custom scripts can run in synchronous or asynchronous mode.
  • Subprocess. 
    Sub processes are invoked as embedded processes within the context of the current process. By embedding sub processes within a process, you can model complex workflows. When adding a sub process as an action item, you can only add active sub processes that are primary, linked, or implied to the master process. The sub processes require the same partition as the primary object. A sub process does not follow the partition association mode that is defined on the primary object of the process.
You can add system and manual actions to a process only if you define a primary object.
Process Flow Splits and Joins
A process flow pattern, which is composed of splits or joins, is a condition that is assigned to an action. These splits or joins determine the process flow. A 
split 
branches processing into multiple directions. A 
join 
consolidates the process flow.
Process Flow Splits
A post-condition split is where the outcome of a process is used to determine the process flow. Four types of splits are supported:
  • Serial split
    . A serial split is a step which activates only when another step in the same process completes. For example:
    • A step sends a bill only after the completion of the step that sends the order.
    • A step adds air miles only after the completion of a step that books a flight.
  • Parallel split
    . A parallel split is a workflow event where a thread splits into multiple steps. The steps can execute in parallel or simultaneously. For example, a payment step can execute three steps:
    • Ship an order.
    • Send the customer a notification that the order has shipped.
    • Adjust inventory.
The following image shows how a split is used in a process flow:
Image showing how a split is used in a process flow
Image showing how a split is used in a process flow
 
  • Decision Point split
    . An exclusive choice (XOR-split) is a point in a workflow where one of several branches executes based on either decision or control data. For example, a credit-card processing step can branch into one of the following two steps:
    • If a credit card transaction is approved, ship the order.
    • If a credit card transaction is denied, inform the customer.
    With exclusive choice splits, the system evaluates the post conditions in the order that is listed until a condition evaluates to true. The corresponding step activates and ignores all other remaining conditions and steps. Exclusive choice does not cause parallelism as only one branch activates.
  • Multi-choice split
    . A multi-choice split (OR-split) describes a point in the workflow at which the system can select from several branches, which are based on decision or control data. For example, after executing the Evaluate Damage activity, the Contact Fire Department and Contact Insurers activities can both execute. With this type of split, more than one condition can be true, leading to execution of more than one other actions. The system evaluates all post conditions in the order listed. A thread of execution can start for any condition that evaluates as true.
Process Flow Joins
A join describes the merging of two or more steps into a single process flow. The following table provides a summary of the matching patterns between splits and joins:
Split Type
Matching Join Type
Sequence
No join needed
Parallel
Rendezvous (AND)
Exclusive Choice Split
Merge (XOR)
Multiple Choice (OR)
Wait and Merge
First in Line
Multi-Thread (Multi-Merge)
Rendezvous (AND) Statement
A rendezvous (an AND statement) is a simple join type. At the point where the threads join, the flow stops until all parallel threads are complete. Then, a single thread of execution continues. Here are some examples of rendezvous activities:
  • Send Tickets and Receive Payment steps complete, and then the Archive step executes. 
  • Policy Verification and Damage Assessment steps complete, and then the Evaluates Insurance Claims step executes. 
The following image shows how a Rendezvous join type is used in a process flow.
Image showing how a Rendezvous join type is used in a process flow
Image showing how a Rendezvous join type is used in a process flow
 
Merge (XOR)
A merge is type of join in which multiple processes converge into a single thread. At the point where the threads join, all active threads synchronize. If only one path emerges, alternative branches converge again without synchronization. After synchronization, the next step activates and a single thread of execution continues. A primary consideration is when to synchronize and when to merge. The timing of thread activation is important. With a merge, once a branch activates, it cannot be reactivated while the merge awaits the completion of other branches. For example, after the steps that contact the fire department and insurance company are complete, run and save the report.
The following image shows how a Merge join type is used in a process flow.
Image showing how a Merge join type is used in a process flow
Image showing how a Merge join type is used in a process flow
Wait and Merge
Wait and merge describes a join where two or more alternate branches converge without synchronizing. Synonyms for simple merge include XOR-join, asynchronous join, and merge. The wait and merge pattern assumes that alternative branches do not execute in parallel. The wait and merge type of process consists of multiple branches (as opposed to multiple threads) that transition into a single step. Only one of the many branches activates. For example, the Pay Damage or Contact Customer steps execute, then the Archive Claim step. Alternatively, the car is delivered to the customer only after the customer pays or is granted credit.
The following image shows how and Wait and Merge join type is used in a process flow.
Image showing how a Wait and Merge join type is used in a process flow
Image showing how a Wait and Merge join type is used in a process flow
Multi-Thread
Multi-thread describes a join in which two or more branches reconverge without synchronization. If more than one branch activates, possibly concurrently with the other, the step following the merge starts for all activations of each incoming branch. The next step starts when an incoming branch completes. Then, all other branches that reach the merge point start a new copy of the next step. You can use a multi-thread join when two or more parallel branches share the same end-step (that is, no steps are replicated).
The following image shows how a Multi-Thread join type is used in a process flow.
Image showing how a Multi-Thread join type is used in a process flow
Image showing how a Multi-Thread join type is used in a process flow
First-in-Line
A First-in-line join waits for one of multiple branches to complete before starting a subsequent step. A discriminator waits for the remaining branches to complete but ignores them. Once execution of all incoming branches begins, the discriminator resets itself so that it can retrigger later. For example, to improve query response time, you can send a complex search to two databases. The first search which generates a result triggers the workflow to proceed. The second result is ignored.
Create a Process
Consider what you want to accomplish and how the process can do it. Monitor your business processes and apply iterative improvements to streamline your operations. The following steps provide an overview of the tasks that you perform to define and run processes:
  1. Define process properties.
  2. (Optional) Add objects to the process.
  3. Define step actions.
  4. Create step-level escalation.
  5. (Optional) Create process groups.
  6. Validate processes and steps.
  7. Activate processes.
  8. Run processes.
Video: How to Create a New Process Workflow
The following third-party video is provided by Rego Consulting. This video is provided by CA Technologies “AS IS” and without warranty.

To play this video in full screen, click the YouTube logo to the right of Settings at the bottom of the video. 
Video: How to Create a Process Deployment, Schedule, and Deletion
The following third-party video is provided by Rego Consulting. This video is provided by CA Technologies “AS IS” and without warranty.

To play this video in full screen, click the YouTube logo to the right of Settings at the bottom of the video. 
Define Process Properties
Follow these steps:
  1. Open Administration, and from Data Administration, click Processes.
  2. Click New.
  3. Complete the requested information. The following fields require explanation:
    • Mode
      Displays the current mode of the process.
      Values:
      • Active
      • Draft
      • On Hold
  4. Complete the following fields In the Organizational Breakdown Structure section:
    • Department
      Defines the financial department and entity that is associated with the process. The department requires belonging to the same entity as the location.
    • Location
      Defines the location of the financial department that is associated with the process. The location requires belonging to the same entity as the department.
  5. Save the changes.
Add Objects to a Process
In this step, you can add objects to a process. This step is optional. Add objects to your process only if you define manual actions, system actions, or sub processes within your process steps. If you add a schedule to your process, to run it as a job or a custom script, do not assign a process to an object. You can add the following types of objects to a process:
  • A primary object
  • One or more linked objects
If you add Project as the primary object to your process, you can also select a template to be associated with the project process. In addition, you can specify a key (Template Key) that provides a reference to the template used in the process.
You can manually add a linked object to a process. Sometimes, the system adds it automatically. Create the linked object in Studio as an attribute of the primary object using a data type. The object is then available for adding in processes. For example, to assign an application lookup to every instance of an object, create an attribute that is named Application on the original object. Use this information for reference:
  • Attribute Name: Application
    After you create the Application attribute, add the attribute to the Create and Edit views of the object.
  • Attribute ID: application
  • Data Type: Lookup
  • Lookup: Application Browse
Follow these steps:
  1. With the process open, click Objects.
  2. Click Add Primary Object.
  3. Complete the requested information. The following fields require explanation:
    • Object Type
      Defines the object type that is associated with the process. If the object is associated with a partition model, select a partition and a partition association mode for the object.
    • Associated Template
      Defines the template that is associated with the object. This field appears if the primary object is project.
    • Available for On-demand Start
      Specifies if you can start the process on demand from an object instance.
      Values:
      • Yes.
        Users can start the process on-demand from the Processes tab of an object instance. The process is included in the available sub processes list and can be invoked at runtime as a sub process. If the process is set to auto-start, the process starts automatically when the start condition (if any) is satisfied.
      • No.
        Users cannot start the process on-demand from the Processes tab of an object instance. The process is included in the available sub processes list and can be invoked at runtime as a sub process. If the process is set to auto-start, the process starts automatically when the start condition (if any) is satisfied.
  4. Click Save and Continue.
  5. Add any linked objects for the primary object:
    1. Select the primary object to add a linked object, and click Add Linked Object.
    2. From the Attribute drop-down, select the linked object.
      Based on the selected linked object, the Attribute Object Type field is automatically populated.
    3. Select an attribute partition code.
      This option appears only if a partition model was defined for the attribute in Studio.
    4. Enter the linked object key in the Object Key field.
    5. Click Save and Continue.
      The process definition objects page appears listing the newly added linked object under the primary object. From this page, you can add additional linked objects, remove objects, or exit the current process.
  6. Click Continue.
Partition and Partition Association Mode
If a partition model exists for an object in Studio, then the Partition and Partition Association Mode drop-down appears on the primary object properties page. The list of partitions varies according to the partition model assigned to the object. The following modes are available:
  • Partition only
    . All processes are available to users assigned to this specific partition. For example, you select the following values for partition and partition association mode for an object. This selection allows only users that are associated with the Corporate IT partition level to access the processes for the object:
    • Partition: Corporate IT
    • Partition association mode: Partition Only
    Users who are associated with the IT Organization partition, an ancestor level, or the Corporate IT-New York partition, a descendant level, cannot access these processes.
  • Partitions, ancestors, and descendants
    . All processes are available to users assigned to this specific partition, and to users assigned to the ancestor or descendant of this partition. For example, you select the following partition values for an object. This selection allows users who are assigned to the Corporate IT partition and its ancestor and descendant partitions to access the object processes:
    • Partition: Corporate IT
    • Partition association mode: Partition, ancestors, and descendants
  • Partitions and ancestors
    . All processes are available to users assigned to this partition, and to users assigned to the ancestor of this partition.
  • Partitions and descendants
    . All processes are available to users assigned to this partition, and to users assigned to the descendant of this partition.
You can change the partition values for an object at any time.
When you change partition values, the process is deactivated. Revalidate and reactivate the process.
Add Linked Objects to a Process
After adding a primary object to a process, you can add a linked object to the primary object. The option to select an attribute partition code appears only if a partition model is defined for the linked object in Studio.
Follow these steps:
  1. With the process open, click Objects.
  2. Select the primary object to add a linked object, and click Add Linked Object.
  3. Complete the requested information. The following fields require explanation:
    • Attribute
      Defines the link object.
  4. Click Save and Continue.
    The objects page appears listing the newly added linked object under the primary object. From the page, add additional linked objects, remove objects, or exit the current process.
  5. Click Continue to proceed to the process start options page to specify a start option for the process.
Define a Process Start Option
You can define a process start condition for all primary and linked objects and their parent or grandparent objects. On the Process Start Options page, you can select from the following start options:
  • On-demand. If you select this option, you can activate this process manually. Go to Processes for the primary object included in this process. From the available processes page, select this process and click Start.
  • Auto-start. You can auto start a process only if its primary object has been event-enabled in Studio (that is, when the object is defined in Studio, the Event Enabled check box is selected). If you select the option, the process activates automatically when the start conditions are met. Select a start event and set start conditions to define the conditions to auto start the process.
Follow these steps:
  1. With the process open, click Start Options.
  2. Click Auto-start.
  3. Complete the following fields:
    • Start Event
      Defines the start event to auto start the process. The list displays all the events that are registered in
      Clarity Project and Portfolio Management (PPM)
       for the selected process objects. Typically, for all
      Clarity Project and Portfolio Management (PPM)
       objects, the start event options are Create, Update, and Create and Update.
      If you select Update or Create and Update as the start event, a check box appears. If you select the check box, only one running process instance is allowed to auto start for each object instance at any given time.
    • Start Condition
      Defines the start condition to auto start the process. If you select Create and Update as the start event, you can set start conditions for both the Create event and the Update event in the same process.
      Check states between attributes to use object attributes that are defined in the selected partition to build start conditions.
      Example:
       You want to send a notification to your manager when your Project status changes. This status can change at two stages - when the Project Instance is created and when the Project instance is updated. In this case, process start conditions apply for Create and Update events.
Set a Start Condition
You can add a start condition to a process. Before you begin, set a start condition to auto-start a process. The auto-start option must be selected on the start options page. If you select the Create start event on this page, you can only select the current attribute value for an object when building the condition. You cannot select previous and current values for an object create event. The same applies if you select a linked object (including parent and grandparent objects).
Follow these steps:
  1. With the process open, click Start Options.
  2. Click the Set Condition link.
    If you selected Create and Update as the start event, you can set start conditions for both the create event and the update event in the same process.
  3. Select the object on which you want to configure a rule.
  4. Specify the left parameters of the condition by selecting an option button and then selecting an attribute value (current or previous) for the selected object.
  5. Specify the right parameters of the condition by specifying an operator and a constant or by selecting an object and an attribute value.
  6. Click Add to add and evaluate the expression in the Expression field.
  7. Define additional or alternative start conditions using the And or Or operations.
  8. Click Save and Continue.
Define Step Actions
When defining actions in steps, all action item attributes are available in the Condition Builder for building conditions. When the number of action items increase, you can verify the status of each action item. Manual and system actions begin once the step condition is met. Define context within a manual action item by using attribute tags (from multiple objects) within the Subject and Description fields of the action item. When you send an action item, the process engine replaces the attribute tags with the values in the object instance. The action item assignees are better able to respond to action items using the more relevant content.
The attribute tags allow process designers to incorporate data from multiple objects within the action item. You can assign manual action items to the following items:
  • Object Roles
    To assign the action item to a role based on object ownership.
  • System Roles
    To assign the action item to a resource based on a system role.
  • Groups
    To assign the action item to a resource based on group membership.
  • Resources
    To assign the action item to a resource based on resource name.
  • Resource Fields
    To assign the action item to a resource based on a resource field.
  • Template Object Roles
    To assign the action item to a resource based on the template object. This tab only appears if a project template exists in the process.
Define Steps and Conditions
Start and end steps are always required and are automatically created even if you do not explicitly define them. You can add and define intermediate steps. Each step can consist of multiple actions, with each step performed by an assignee or the product. You can create custom actions that include custom GEL scripts. The start and the end steps can be contained in a group.
Define Start and Finish Step General Properties
Follow these steps:
  1. With the process open, click one of the following options:
    • Start Step to create a starting step.
    • Finish Step to create an ending step.
  2. Complete the requested information, and save. The following fields require explanation:
    • Raise a Warning After
      If the step fails to run, specifies the time period post which to raise a warning. Select the time period and enter the number for the period.
      Example: 2 Days
Define Intermediate Step General Properties
Follow these steps:
  1. With the process open, click Steps.
  2. Click New Step.
  3. Complete the requested information, and save. The following fields require explanation: :
    • Group
      Defines the group name that is associated to this step.
    • Raise a Warning After
      If the step fails to run, specifies the time period post which to raise a warning. Select the time period and enter the number for the period.
      Example: 2 Days
Define Step Preconditions
When defining a precondition to a step, you can use attributes from multiple objects added to the process. For example, you can create preconditions that:
  • Verify the status of action items
  • Verify between object attribute values
  • Wait for a sub process to complete before joining the master process
You can apply the precondition joins to intermediate and end steps only and not to a start step. To set up a precondition using
Previous Value
of certain attributes, enable audit trail for these attributes in Studio.
For object attributes with a Multi-Valued Lookup (MVL) data type, you cannot create step conditions that check for previous and current attribute values.
Follow these steps:
  1. Open the process.
  2. Open the start, intermediate, or finish step that you want to edit.
  3. If this step is joining previous steps that were split, select a join type in the Preconditions section. You can define a join type without a precondition, and vice versa.
  4. Click New to specify a precondition to trigger the step to start.
  5. Define a precondition by building the left and right parameters using objects and their attribute values.
    For example, you can have the following precondition: After a day of the Start step, trigger Step 2. The precondition starts step 2.
  6. Evaluate the expression and use And/ Or operators to add additional or alternative preconditions.
  7. Save the changes.
Define Step Post-Conditions
After defining the preconditions to trigger a step, define post-conditions that will connect this step to the next step, or the end step. For example, you can create post conditions that do the following:
  • Verify the status of action items.
  • Verify between object attributes values (except for MVL attributes).
  • Wait for a sub process to complete before joining the master process.
When you set up a postcondition using "Previous Value" of certain attributes, enable audit trail for these attributes in Studio.
For object attributes with a Multi-Valued Lookup (MVL) data type, you cannot create step conditions that check for previous and current attribute values.
Follow these steps:
  1. Open the process.
  2. Open the start, intermediate, or finish step to edit.
  3. If the step is branching off the process into multiple directions in the Post-conditions section, select a split type.
  4. Under the If...column, click Build Conditions to define the If condition that leads to the next step.
  5. Complete the following fields:
    • Object
      Specifies the step to use for the right side of the If expression. If you select the Object field and select a value, a second field appears for you to select the value to use in the expression.
    • Field
      Specifies the left parameters of the If condition.
      Values:
      • Days elapsed since step began. The number of days that have passed since the step began. You can specify the value as a fraction. For example, for a day and a half, the value is 1.5.
      • Duration of completed step. The number of days elapsed since the step was completed. You can specify this value as a fraction. The value for the duration of the completed step is not defined until a step is complete. The duration of completed step for a step cannot be used as a postcondition for the same step.
      • Number of times repeated. The number of times the step will loop. For example, after completing steps 1, 2, 3, and 4, you can have a postcondition in step 5. Step 5 takes the process back to step 2. If the number of times repeated value is 3, then step 5 goes through the loop three times. After that, the process takes another path that is based on what is defined in the condition.
    • Operator
      Specifies the operation to perform to evaluate the If expression.
      Values: =, !=, >, >=, <, <=
    • Constant
      Specifies a constant value to include in the right part of the evaluated If expression.
      Example: If days elapsed since step began=2.
  6. Click Add to evaluate the expression and use the And/ Or operators to add additional or alternative preconditions.
  7. Click Save and Continue.
  8. In the Post-conditions section, under the Then Go To column, click Select Step to select the step that triggers next once the If condition in this step is satisfied.
  9. Click New to add and build additional post-conditions (if necessary).
  10. Save the changes.
Create a Manual Step Action
Follow these steps:
  1. Open the process and the step.
  2. In the Actions section, click New.
  3. Select Manual Action and click Next.
  4. Complete the requested information in the General section.
  5. In the Actions sections, select an available action.
  6. Complete the following fields in the Action Item Message section:
    • Subject
      Defines the name for this action item. You can enter a subject or can select attribute variables from the object that is attached to the process. The attribute is substituted with a value when the action item is processed.
    • Description
      Defines the description of the action item. You can enter a subject or can select attribute variables from the object that is attached to the process. The attribute is substituted with a value when the action item is processed.
    • Priority
      Specifies the priority level of the action item.
      Values:
      Low, Medium, or High
    • Enter Assignees
      Defines the assignees for the action. Enter one or more user IDs and click Quick Add Assignees to add them to the Assignees field.
    • Make Action Item Available to Other Steps
      Specifies if this action item is available for use by other steps.
    • Only Display Assignee Status for the Current User
      Specifies whether only the current name and status for the user can be seen when viewing an action item, or whether all assignee statuses can be seen.
      Default
      : Cleared
  7. Complete the following fields in the Notification section, and save:
    • Send Notification
      Specifies the event occurring before the notification is sent.
      • Values:
      • When Step is started.
      • When Step is completed.
      • When Step is in error.
    • Enter Recipients
      Defines the names of the recipients of the notification. Click Quick Add Recipients to add recipients to the Send Notification To field.
    • Send Notification To
      Defines the object roles to notify about the action.
    • Notify Owner
      Specifies if you want to be notified about the action.
      Default:
      Cleared
Create a System Step Action
You can set actions that are defined for an object to complete during a step.
Follow these steps:
  1. Open the process and the step.
  2. In the Actions section, click New.
  3. Select System Action, and click Next.
  4. Complete the following fields in the System Action section, and save:
    • Object
      Defines the object that is attached to the system action.
    • Action
      Defines the action for the system action. The choices that appear to define the action depend upon the action you select.
Create Run Jobs
Follow these steps:
  1. Open the process and the step.
  2. In the Actions section, click New.
  3. Select Run Job
    and click Next.
  4. Select a job type and click Next.
  5. Complete the requested information to configure properties. The following fields require explanation:
    • Job Name
      Defines the job that runs as part of this action. If the Parameters section displays, enter any parameters that are required for the job. The parameters that display, if any, depend upon the job you select.
    • Completion Mode
      Defines the job completion mode.
      Values:
      • Synchronous
      • Asynchronous
  6. In the Notifications section, enter notification details.
  7. In the Notify section, select the resource or group to receive notifications about the job.
  8. In the Sharing section, select the resource or group to share this job with.
  9. Save the changes.
Create a System Action to Run a Subprocess
Follow these steps:
  1. Open the process and the step.
  2. In the Actions section, click New.
  3. Select Subprocess
    and click Next.
  4. Complete the requested information. The following fields require explanation:
    • Subprocess
      Specifies the subprocess to use in the action. You can select from all valid and active processes whose primary objects and partitions match the objects and partitions of the master process.
    • Initiating Object
      Displays the object to us at runtime to initiate the sub process.
    • Subprocess Object Key
      Defines the sub process ID to use as a reference when building conditions.
    • Completion Mode
      Defines the sub process completion mode.
      Values:
      • Synchronous: After the sub process is invoked, the master process is paused until the sub process completes. You cannot terminate a synchronous sub process because terminating the sub process intervenes with the master process.
      • Asynchronous: The sub process runs asynchronously with the master process, but can join the master process at a future step or action. The sub process state is visible to the master process. The master process does not complete until the asynchronous sub process completes. You cannot terminate an asynchronous sub process because terminating the sub process intervenes with the master process.
      • Independent: The sub process runs independently from the master process. After a sub process is invoked from a step action, its state is not visible to the master process. If the execution of a sub process does not intervene with its master process, you can set the mode of the sub process to independent. The master process can complete even if the independent sub process is still running. You can terminate an independent sub process because terminating the sub process does not affect the master process. Similarly, terminating the master process does not affect the sub process.
  5. Click Save and Continue.
Create a Step-Level Escalation
Step-level escalations can only be invoked when you define an action item within a step. If a step is not complete, escalations can execute an action item and can notify a specific resource or group. At runtime, whenever an action item is open, it can be escalated using certain predefined escalation rules. You can use step escalation rules or process default escalation rules, regardless of the scope of the action item. Step escalation only works if the action is on that step.
You can define an escalation rule for each step in a process. When you have not defined an escalation rule at the step level, the text "There is no escalation rule setup to display" appears in the Escalation section of the
process definition step
page. Once you have defined a rule, a short summary of the rule appears in the Escalation section as a link. If you have not defined an escalation for the step, process-level escalation defaults are used, if there are any.
For step level escalations to work, first define a manual action for the step.
Follow these steps:
  1. With the process open, click Steps.
  2. Open the step.
  3. In the Escalation section, click New.
  4. Complete the attributes:
    • Escalation Type
      Defines the escalation rules for this process.
      Values:
      • None: No escalation rules exist for this process.
      • OBS Hierarchy: Escalate through the OBS hierarchy.
      • Resource Manager Hierarchy: Escalate through a hierarchy of resource managers.
      • Specific Resource: Escalate to a specific resource.
    • Levels
      Specifies the number of levels to escalate. Select No Limit to escalate indefinitely.
    • Initial Grace Period
      Specifies the amount of time to wait before escalating the action item (the number of minutes, days, weeks, or months).
    • Subsequent Grace Period
      If no action occurs, specifies the amount of wait before escalating again.
    • Active
      Select to activate this escalation.
  5. In the Additional Notification section, complete the requested information to set up additional escalation notifications.
  6. Save the changes.
Set Up Step-Level Process Notifications
You can set up a notification for a step and for each step action. You can send notifications when the step or action is performed, and can specify notification recipients for the specific step or action. To set up notifications for a step action, first create the step action.
The method by which a recipient receives notifications depends on the notification method you specify on the account settings: notifications page. Notifications can be an alert, email, or SMS.
Follow these steps:
  1. With the process open, click Steps, and open the step that you want to set a notification on.
  2. In the Notifications section, complete and save the following settings:
    • Send Notification
      Specifies the event occurring before the notification is sent.
      • Values:
      • When Step is started.
      • When Step is completed.
      • When Step is in error.
    • Enter Recipients
      Defines the names of the recipients of the notification. Click Quick Add Recipients to add recipients to the Send Notification To field.
    • Send Notification To
      Defines the type of resource you want to notify about this step.
      • Values:
      • Object Role. Notify a role that is based upon object ownership. The list of roles varies depending on the object.
      • System Role. Notify a resource that is based upon a system role.
      • Groups. Notify a resource that is based upon group membership that is defined under Organization and Access.
      • Resources. Notify a resource that is based upon resource name.
      • Resource Fields. Notify a resource that is based upon resource fields.
      • Template Object Roles. Notify a resource that is based upon the template object. The option is available only if a project template is attached to the process.
    • Notify Owner
      Specifies if you want to be notified about the action.
      Default:
      Cleared
Create a Process Group
Use process groups to categorize steps that represent larger segments of the process. To create process groups, first create a placeholder group and then associate process steps to that group. You can reorder the steps within the group and can update the group from time to time.
Follow these steps:
  1. With the process open, click Steps.
  2. Click New Group.
  3. Complete the requested information.
  4. Click Save and Continue.
Associate a Step with a Process Group
After creating a placeholder group, associate it with steps from the process.
Follow these steps:
  1. With the process open, click Steps.
    The steps page appears listing all the steps and groups included in the process.
  2. Open the step to associate with a group.
  3. In the General section, click the Group drop-down, and select the group to associate this step.
  4. Click Save and Continue.
    The steps
    page appears displaying the step as a part of the group.
  5. Repeat, as needed, to add more steps in the group.
  6. To move the steps or groups, click Reorder, and use the up and down arrows.
  7. To update a process group, click the group name, and edit any fields.
  8. Click Save and Continue.
Process-Level Escalations
You can create escalations to execute an action item and notify one or more resources when a process step is not completed.
Clarity Project and Portfolio Management (PPM)
 supports step-level escalation. You can define an escalation rule for each step in a process. The action item due date is used to start the escalation. As a
best practice
, if you plan to use escalations in processes, make Due Date a required field for the Action Item object.
The method in which a recipient receives notifications depends on the notification method that the resource specifies on the account settings: notifications page. For example, recipients can receive process notifications through an alert, email, or SMS.
View the Escalation Job Status
In the Escalation Job Status
section, view the following information for all active escalation jobs:
  • The name of the escalation job
  • The actual start date and time of the escalation job
  • The end date and time of the escalation job (only if the job has ended)
  • The scheduled date of the escalation job.
  • The status of the escalation job. For example, Pending" or Completed.
Filter Escalation Objects
Use the Escalation Object Filter section to filter on escalation jobs by object name and ID. You can use both parent and linked objects. To view the page from the processes list page, click Escalations.
Add Process-Level Escalation Defaults
Follow these steps:
  1. With the process open, click Escalation Defaults.
  2. In the General section, complete the following fields:
    • Escalation Type
      Defines the escalation rules for this process.
      • Values:
      • None: No escalation rules exist for this process.
      • OBS Hierarchy: Escalate through the OBS hierarchy.
      • Resource Manager Hierarchy: Escalate through a hierarchy of resource managers.
      • Specific Resource: Escalate to a specific resource.
    • Levels
      Specifies the number of levels to escalate. Select No Limit to escalate indefinitely.
    • Initial Grace Period
      Specifies the amount of time to wait before escalating the action item (the number of minutes, days, weeks, or months).
    • Subsequent Grace Period
      If no action occurs, specifies the amount of wait before escalating again.
    • Active
      Select to activate this escalation.
  3. In the Additional Notification section, complete the requested information, and save.
Monitor Process Escalations
Process escalations occur through jobs. Use the Escalation Job Status
 
section to view a list of escalation jobs and monitor their status. You can also view and edit the rules of escalation objects.
When an escalation occurs, you can determine the object, the process name, and the process instance ID. You can also determine when the escalation started, next escalation occurrence, and completion details. For example, a resource has finally acted on the step.
Follow these steps:
  1. From the available processes page, click Escalations.
  2. In the
     
    Escalation Job Status section, review the following fields:
    • Name
      Displays the escalation job name.
    • Start Date
      Displays when the job last started.
    • End Date
      Displays when the job last completed.
    • Schedule Date
      Displays when the job next runs.
    • Status
      Displays the escalation job status.
  3. Click an Object Type link to view and update escalation rule properties.
Process Validation and Runtime Errors
Use the process validations page to monitor the latest validation statuses and errors at the step and process level. To open the process validations page, open the process and click Validation.
Process Runtime Errors
On the initiated processes page, you can view a list of those process instances that you started. From this page, you can drill down to the initiated process messages page and can get detail information about an error. Any errors or warnings appear in the following order of precedence:
  • System Errors 
    occur in the process management infrastructure.
  • Application Errors
     occur in the product and affect process management.
  • Warnings
     occur for exceptions that require corrective action. 
Errors can often stop a process. Warnings do not prohibit a process from continuing.
Validation States
The Status field in the General section of the step details page reflects the validation status of the step. Here are the possible validation states:
  • Green diamond = Validated. 
    Indicates that the validation object (step or process) is valid.
  • White diamond = Not Validated. 
    Indicates that the validation object has not been validated or there are validation errors at the specific validation level.
  • Yellow diamond = Revalidation Required. 
    Indicates revalidate the validation object for changes that are made to the process after the last validation.
  • Red diamond = Errors Encountered. 
    Errors were detected in the validation object during validation.
Validate a Process
You can validate the process and all included steps from the process validation page. Clicking a step on the page takes you to the step details page to view the details of that step. Clicking the Process link takes you to the process properties. If an error displays during validation, correct it and run the validation process again. Activate a process after validating it.
Follow these steps:
  1. With the process open, click Validation.
  2. Select each step to validate, and click Validate.
  3. Select the process and click Validate.
    The entire process is validated by executing all incomplete validations at all levels.
  4. Select the process and click Activate Process.
  5. To validate all steps in the process and activate the process at once, click Validate All and Activate.
Revalidate a Process
Any changes to the process definition invalidate the process at certain levels, and requires validating the process partially again. For example, you change the split-type in step S2 of process P1 from Serial to Parallel Split (AND). Validate step S2 again, and execute the process-level validation for P1.
If you modify a validated process, the process becomes invalidated. It is not necessary to validate the entire process again. You can execute again certain validations only. For example, if you modify a post condition of a step, you revalidate only the specific step.
The following table shows the types of repeat validations for specific changes that are made to objects:
Object
Change
Revalidations
Step
Any changes that are made to a step, including:
Join Type
Precondition
Split Type
Split-condition
The step becomes invalidated. All step-level validation rules must be reapplied.
The process becomes invalidated. All process-level validation rules must be reapplied.
Process
Delete an object (primary, linked, or implied)
All steps referring the object become invalidated. Step-level validation rules, object references, and condition expressions must be reapplied to all affected steps.
You can either delete an object from the Objects sub page or delete it indirectly by deleting a step action that creates an implied object.
Object
Delete an object
All steps referring to the object become invalidated. Step-level validation rules, object references, and condition expressions must be reapplied to all affected steps.
If there are initiated process instances of the process definitions that contain steps referring the deleted object:
The process definitions become invalidated and deactivated.
The initiated process instances are marked to be aborted.
After the process engine aborts these initiated instances, you can edit the process definitions. You can modify and fix the problem, and then validate and activate the process again. You can also delete the aborted process instances using a batch job or delete the invalidated and deactivated process definitions.
Object Attribute
Delete an object attribute
All steps referring the object attribute become invalidated. Step-level validation rule and condition expressions to be reapplied to all affected steps.
If there are initiated process instances of the process definitions that contain steps referring the deleted object attribute:
The process definitions become invalidated and deactivated.
The initiated process instances are marked to be aborted.
After the process engine aborts these initiated instances, you can edit the process definitions. You can modify and fix the problem, and validate again and activate the process. You can also delete the aborted process instances using a batch job or delete the invalidated and deactivated process definitions.
Process Validation Rules
Validation rules are grouped as process-level or step-level.
Process-Level Validation Rules. 
Process-level validation rules are used to validate inter-step transitions. Usually, these validation rules are applied after all steps are validated. However, to validate the structure of a process, you can opt to execute these validation rules before all steps are validated. The following rules are enforced during the validation process:
  • Each postcondition matches a precondition (except when a decision point split type is used in a negotiation loop).
  • Serial split types contain only one condition with an evaluated expression and connect to only one step.
  • Parallel split types match with a rendezvous join type.
  • Decision point split types:
    • Contain two or more conditions with evaluated expressions, each of which connects to only one step.
    • Match with a merge join type.
  • Multi-choice split types:
    • Contain two or more conditions with evaluated expressions, each of which connects to only one step.
    • Match with a wait and merge, multi-thread, or first in line join type.
  • Processes can be nested.
  • Each condition contains an evaluated expression to complete the step.
  • No arbitrary loops exist. The process flow cannot be transferred inside a loop or outside a loop.
  • Start and End steps are defined.
  • Island nodes do not exist.
  • There exists a path from Start step to any other step. A path exists from any other step to End step.
  • The number of splits and the number of joins match.
  • No nested cycles exist. Only one entry point to the cycle exists.
  • A cycle and a split-join block cannot be nested.
  • No step exists with a “None” joining type but two joining steps. No step with a AND/OR joining type but none joining steps.
  • If you change the process mode from Active to Draft or On Hold, or if you delete the process, all processes that invoke this process as a sub process are invalidated.
  • If an active process with no running process instances becomes invalid, its mode changes to Draft (from Active).
  • If an active process with running process instances becomes invalid, its mode changes to On Hold (from Active).
Step-Level Validation Rules. 
Step-level validation rules are used to validate the inner properties of a step. If a subprocess is not validated and activated, its master process cannot be validated and activated. The invalid sub processes require separate validation. The following rules are enforced during the step validation process:
  • Objects that are referenced in the step exist. Object names are unique within a step context.
  • Precondition expressions are valid (that is, the syntax is correct and the objects and object attributes that are referenced in the expression exist).
  • Postcondition expressions are valid (that is, the syntax is correct and the objects and object attributes that are referenced in the expression exist).
  • Postcondition expressions are not empty when there are multiple conditions.
  • The number of post conditions and the number of go-to steps are consistent with the split type.
  • The sub process that is invoked from a step action is valid and active.
  • If the step has a manual action, a postcondition that is based on the elapsed time of the action item is preferred.
  • A non-empty expression has a corresponding go-to step.
  • The object that is referenced in a system action exists (that is, if an object is deleted from a process, or from Studio, the steps containing the system action are invalidated).
  • The object operation in a system action is valid (that is, if an object attribute is deleted from Studio, the steps containing system actions that reference the object attribute are invalidated).
View and Correct Runtime Errors
Follow these steps:
  1. Open the Processes menu, and click Initiated.
  2. In the Messages column, mouseover the icon to view a description of the error for each process instance.
  3. Select the error icon.
  4. Read the error message and resolve the problem as follows:
    • To rerun a step, select the step and click Retry.
    • To skip the step that is associated with an error or warning, select the step and click Skip Problem.
      When you skip a runtime error, you can get unexpected results. For example, the process can take another path and not complete as you expected. Alternatively, the process cannot continue because the next step in the process is waiting for this step to complete.
    • To delete the runtime error or warning, select the step that is associated with the error or warning, and click Delete.
    • To cancel the process without fixing any errors, click Cancel Process.
Error Handling at the Action Level
When steps have multiple actions, and an error occurs at runtime, the system identifies the error at the action level. You can handle the error in the following ways: 
  • You can fix the error.
  • You can retry the action from the messages page of initiated process. The action with the error executes again on the new assignees of the action item.
  • You can skip the action instance that contains the error. The system skips the action with an error and executes the next action on the list.
Process Access Rights
View Process Access Rights for a Resource
Follow these steps:
  1. Open the process.
  2. Open the Access to the Process menu, and click Full View.
  3. View the resources with access to the process.
Grant Process Access Rights to a Resource
Follow these steps:
  1. Open the process.
  2. Open the Access to the Process menu, and click OBS Unit.
    The OBS units with access page appears, listing resources with access rights to the process.
  3. Click Add and select the access rights to assign to the resource.
  4. Click Add and Continue.
  5. Select the resources to grant access rights.
  6. Click Add.
Grant Process Access Rights to a Group
Follow these steps:
  1. Open the process.
  2. Open the Access to the Process menu, and click Group.
    The groups with access page appears, displaying groups with access rights to the process.
  3. Click Add, and select the access rights to assign to the group.
  4. Click Add and Continue.
  5. Select the group to grant access rights.
  6. Click Add or Add and Select More.
Grant Process Access Rights to an OBS Unit
Follow these steps:
  1. Open the process.
  2. Open the Access to the Process menu, and click OBS Unit.
  3. Click Add.
  4. Select the access rights to assign to the OBS unit, and click Add and Continue.
  5. Select the OBS unit to grant access rights.
  6. Click Exit.
Monitor Process Engines
If a particular area of the process engine needs further investigation, you can view pipeline data to evaluate its performance.
Follow these steps:
  1. Open Administration, and from Data Administration, click Process Engines.
  2. Review the metrics that appear in the following fields:
    • Name
      Process engine name. Click the name to view pipeline details for the process engine.
    • Active Processes
      Number of active processes. Click the value to drill down and view a list of all initiated process instances running on this engine.
    • Completed Processes
      Number of completed processes. Completed processes provide insight to the effectiveness and activity of this engine. Click the value to drill down and view a list of all completed process instances running on this engine.
    • Last Heart Beat
      Date and time of the last heartbeat indicating if the process engine instance is active and running.
    • Start Date/End Date
      Date and time the process engine instance started and when it terminated or stopped.
    • Process Errors
      Number of process errors that occurred on all process instances of a process engine. Click the value to drill down and view the list of process instances that have errors running on this engine.
    • Status
      Indicates whether the process engine instance is running, stopped, or cannot be determined.
    • Total Load
      Percentage of engine time that is used for processing.
    • Last load Snapshot
      Percentage of engine time in the last time window that is used for processing. A time window is a variable time slice that is driven by many factors, such as load on each engine.
    • Pre Condition/Post Condition/Action Execution
      Queue length for preconditions, post-conditions, and action pipelines and the total load for pipelines.
      This value gives insight on how busy each pipeline is.
: When monitoring a process engine for bottlenecks, look at the queue length of pipelines. Observe the time that it takes to process steps between pipelines. Processes in the pipeline queue refresh every 30 seconds.
Video: Process Engine Monitoring
The following video is provided by CA Technologies. Process Engine Monitoring is a lightweight framework that tracks periodic queries looking for problematic processes running in an environment. In this video, you will learn about the Process Engine Monitoring feature of 
Clarity Project and Portfolio Management (PPM)
.

To play this video in full screen, click the YouTube logo to the right of Settings at the bottom of the video. 
Process Engine Pipeline Types
Process engines use the following pipeline types:
  • Processes Loaded. 
    Displays the number of active processes that are currently loaded on this process engine. Active processes include processes with a status of Running, Error, and Aborting, but not with a status of Completed or Aborted. This pipeline appears only in the Engine Internal Queues section.
  • Event Wait List. 
    Displays the number of step instances that are currently waiting for events, such as a user action to save a change in the product. For registered events on the Event Wait list, the step instances are pushed to either the precondition queue, or postcondition transition queue.
    Process engines register only for events they are interested in. For example, the engine is processing a postcondition for an active project to go to the next step. The engine registers for the Project Update event. The pipeline appears only in the Engine Internal Queues section.
  • Retry Wait List. 
    Displays the number of step instances that are waiting to be retried. When a process engine processes a step instance, the engine can run into database deadlocks. When database deadlocks occur, the engine places these step instances on the Retry Wait List. This pipeline appears only in the Engine Internal Queues section.
  • Precondition. 
    Displays the queue length as the number of step instances in the state Ready to Evaluate Precondition. A precondition pipeline processes the step instances.
  • Action Execution. 
    Displays the queue length as the number of step instances in the state Ready to Execute Action. An Action Execution pipeline must process these step instances.
  • Postcondition Transition. 
    Displays the queue length as the number of step instances in the state Ready to Execute Postcondition. The post conditions are waiting to proceed through a Postcondition Transition pipeline.
View Process Engine Internal Queues
The Engine Internal Queues page gives the states of internal queues and the number of pipelines (if applicable) for a process engine. Engine internal queues can have the following states:
  • Run status icons. 
    Indicates if the process engine is working.
  • Total Load. 
    Displays the percentage of processing load across all internal queues.
  • Last Load Snapshot. 
    Displays the percentage of engine time in the last time window that was used for processing. A time window is a variable time slice that is driven by many factors, such as load on each engine.
  • Start Time. 
    Specifies the time when the engine started.
  • Total Processing Time. 
    Specifies the total time that the engine used for processing from the engine start time.
  • Queue Types. 
    Displays the names of the queue types in the process management infrastructure. The only queue types that you can configure are the precondition, action, and postcondition queues.
  • Queue Length. 
    Displays the number of requests that are currently pending for this queue type.
  • Number of Pipelines. 
    Displays the number of configured pipelines for every queue type.
Manage the Number of Pipelines in Queues
You can add more pipelines to reduce bottlenecks in pipeline queues, or remove pipelines from each queue. You can have up to five pipelines per queue.
Follow these steps:
  1. Open the process engine to add pipelines.
  2. Click Configure Pipelines.
  3. Select the number of pipelines for each of the following pipeline queue types:
    • Number of Precondition Pipelines
    • Number of Action Execution Pipelines
    • Number of Postcondition Pipelines
  4. Click Save and Continue.
Run Process Steps Waiting for Events
You can immediately run process steps waiting in the Event Wait list queue.
Follow these steps:
  1. Open the process engine.
  2. Click Run Event-Waiting Steps.
    The waiting process steps are placed in either the Pre Condition Pipeline queue, or the PB Cost Condition Transition Pipeline queue.
View Process Event Messages
The events page lets you view systemwide event messages across all process engines. You can view event messages that are received or sent. An example of an event is when you create, or update an object.
Follow these steps:
  1. Open Administration, and from Data Administration, click Process Engines.
  2. Click Events.
  3. View the following information about the last 20 sent or received events:
    • Event Type
      Type of event.
      Example:
      Object - Create or Object - Update.
    • Event Category
      Process component where the event is happening such as a step, a step action, or the process properties.
    • Event Initiator
      Process system area where the event was initiated. The initiator can be a process, a process template, or any other area in the product.
    • Received/Sent
      Date and time the event was received or sent.
    • Resource
      Resource that is involved in the event. For example, the process initiator, the resource retrying a step instance, an approver of an action item.
    • Process Engine
      Process engine for viewing event messages.
Process Definition Notification Templates
Use the process definition notification templates page to view a list of the process notification templates. You can edit the following types of process definition notification templates:
  • Process Escalations
  • System Actions
  • Manual Actions
  • Script Actions
  • Subprocess Actions
  • Job Actions
  • Step Escalations
Follow these steps:
  1. With the process open, click Notifications.
  2. Review the following notification fields:
    • Name
      Defines the unique name of the notification template.
    • Description
      Defines the description for the notification template.
    • Modified
      Specifies if the notification template contents are modified from the template default settings. Modified notification templates are displayed in the list with a yellow checkmark icon.
Configure a Notification Template
You can configure notification templates by adding and removing attribute tags and links to the subject and message body of the notification template. Use the notification properties page to edit the notification template subject and body.
You can modify process notification templates at the system level and at the process definition level. If you modify a template at the system level, these changes apply automatically to the corresponding notification templates at the process definition level. The changes do not apply to the notification templates that you have explicitly configured. If you modify a template at the process definition level, these changes apply automatically to the notification template at the system level. The changes also apply to all corresponding process notification template instances for that process.
If you are exporting process information using the XML Open Gateway, any instance-level process template modifications are not exported with the process information. Use the process notification read and write XML files to export and import notification information separately.
Add Attribute Variables to the Process Notification Template Subject
You can edit the Notification Subject and Notification Body fields to change the text which the product displays for these fields.
Follow these steps:
  1. With the process open, click Notifications.
  2. Click the notification template name.
  3. Select and add attribute variables to either the Notification Subject or Notification Body fields.
  4. Save the changes.
Add Links to the Process Notification Template Body
You can add a hyperlink to display in the body of a notification by modifying the process notification template.
You cannot add the following special characters to hyperlink text: $ [ ] @
Follow these steps:
  1. With the process open, click Notifications, then click the notification template name.
  2. In the Notification Body field, click the Browse icon, then click Links.
  3. Select and add the link in the process notification template body as follows:
    • Leave the default text in the Link Text field to display the text as the hyperlink in the template body. For example, "To access this process,
      click here
      ".
    • Clear the Link Text field to use the standard URL as the hyperlink in the template body. For example, "To access this process, click on:
      <URL>
      ".
    • Clear the default text from the Link Text field and enter the display text to display as the hyperlink in the template body. For example, "To access this process, click on:
      approval process
      ".
    The added hyperlink is appended to the text in the field.
  4. Save the changes.
Preview a Process Notification Template
You can preview how an instance of the process notification template appears when a resource receives it.
Follow these steps:
  1. With the process open, click Notifications.
  2. Click the notification template name.
  3. Click Preview.
  4. (Optional) You can restore modified notification templates to their default values. The Notification Templates page indicates modified notification templates with a check mark in the Modified column. To restore the notification template, open it and click Restore Defaults.