Sample workflows

You can use the sample workflows as delivered or modify them to meet your requirements. They can also be used as templates and learning tools for your own workflows.

The sample workflows are enabled in fresh installations.

Action Item Approval workflow

When an action item is created, the Action Item Approval workflow starts automatically. An email is sent to the Action Item Assignee informing them that an action item is assigned to them. The due date for the task is set to 7 days prior to the action item’s Due Date. When an action item is complete, the assignee selects Actions > Submit for Approval. The workflow then does the following actions:

  • Copies the value in the Issue Owner field of the parent issue to the action item’s Issue Owner for Approval field.
  • Sets the action item’s Status field to Awaiting Approval.
  • Sends an email to the Issue Owner informing them that an action item is waiting for their approval.

The Issue Owner reviews the action item, and then approves or rejects the closure of the Issue. The due date for the task is set to the action item’s Due Date.

If the Issue Owner selects Actions > Approve, the workflow completes the following actions:

  • Sets the Status field to Closed.
  • Sets the Approve Reject field to Approve.
  • Sets the Actual Completion Date to today's date.

If the Issue Owner selects Actions > Reject, the task is re-assigned to the Action Assignee. The workflow completes the following actions:

  • Sets the Status field to Open.
  • Sets the Approve Reject field to Reject.
Figure 1. The Action Item example workflow
The Workflow Editor shows a schematic diagram of the stages in the workflow: Start, In Review, In Progress, and End.

Finding workflow

The Finding workflow uses the Finding System Task view and depends upon the out-of-the-box schema for Finding and related object types.

In this workflow, note the following key elements:
  • The cancellation path

    If a stage is declined, the workflow returns to the Finding Preparation stage. In your own workflow, you might choose this route or choose to go back to the immediately preceding stages. Plan the paths through the workflow in both a forward and backward direction.

  • Task overrides

    The task overrides for each stage define the Key Fields that are listed. The user guidance text is from the Task View itself. With this method, the Key Fields change with each stage and are specific to a stage.

Figure 2. Finding workflow
The Workflow Editor shows a schematic diagram of the stages in the workflow: Start, Finding Preparation, reviews and response stages, and then a Complete stage.
Figure 3. The specification for the Finding workflow
A flow diagram of the Finding workflow, from finding preparation to closure.

Incident workflow

The Incident workflow moves an incident through an investigation and approval process.

When an incident is created, the Incident workflow starts automatically. The workflow sets an owner for each stage (primary owner, approver, and reviewer). It sets the due date based on discovery date and incident criticality.

Figure 4. Incident workflow
The Workflow Editor shows a schematic diagram of the stages in the workflow: Start, In Progress, Review, Approval, and Closed.

Issue review workflow

In an Issue Management and Remediation (IMR) framework, you can effectively document, monitor, remediate, and audit issues.

Issues are items that are identified against the documented framework and are deemed to negatively affect the ability to accurately manage and report risk. In its lifecycle, an issue can have one of two states: Open or Closed.

When an issue is created, the Issue Review workflow starts automatically. The workflow sets the Status of the issue to Open and the Original Due Date to the due date that was entered when the issue was created. An email is sent to the Issue Owner, informing them that an issue is assigned to them. The due date for the task is set to 15 days prior to the issue’s Due Date.

To resolve the issue, the Issue Owner establishes and records the appropriate actions.

Figure 5. Issue Review workflow
The Workflow Editor shows a schematic diagram of the stages in the workflow: Start, In Progress, Due Date Extension Request, In Review, and Closed.

The Issue Owner can request a due date extension at any time during the issue lifecycle by setting the Requested Due Date and selecting Actions > Request due date change. The Issue Approver is notified of this request via email. The approver can approve or reject the request. If approved, the issue’s Due Date is set to the requested due date.

The Issue Owner can submit the issue for review by selecting Actions > Submit for review. The workflow performs the following validations:

  • All action items under the issue are closed.
  • The Issue Conclusion field is populated.
  • The Issue Type field is populated.

If any of the validations fails, the workflow prevents the Issue Owner from submitting the issue for review. If all the validations pass, the Issue Approver is notified of the request via email. This task due date is set to the issue’s Due Date. If rejected, the Issue Owner is notified of the rejection via email. The Issue Owner can make updates and then re-submit the issue for review. If the issue is approved, the issue’s Status is set to Closed.

The issue can be re-opened by starting the Issue Review workflow.

KRI and KPI workflows

KRI Value Creation
This workflow creates KRI Value records and initiates workflows on the KRI Value for collection.

This workflow is set to a schedule that runs on a daily basis on KRI records. In instances when the KRI Status is Active and the Next Collection Date (see the KRI Next Collection Date calculation) is equal to the day the schedule is run and the KRI Value Date is not equal to the day the schedule is run, a KRI Value record is created.

In addition to creating the KRI Value record, the record is populated with values from the parent KRI, including Expected Collection Date, KRI Capturer, KRI Owner, Collection Status, Red Threshold, Yellow Threshold, and Value Date.

The KRI Value that is created by this workflow then enters the KRI Value Entry workflow.

Figure 6. KRI Value Creation workflow
The Workflow Editor shows the stages in the workflow: Start and End.
KRI Value Entry
This workflow assigns KRI Values to users and provides a process for KRI Value approval.

This workflow auto-starts when a KRI Value record is created and is in a Status of Awaiting Collection. When it's created, the KRI Value is populated with data from its parent KRI, including KRI Capturer, KRI Owner, KRI Value Red and Yellow Thresholds, Description, and whether approval is required. After you enter a value, you might need to click another tab and then return to the view to see the latest KRI or KPI values.

Figure 7. KRI Value Entry workflow
The Workflow Editor shows the stages in the workflow: Start, Enter KRI Value, Approval, and End.
KPI Value Creation workflow and KPI Value Entry workflow
These workflows are similar to the KRI Value Creation and KRI Value Entry workflows

Risk and control self assessment (RCSA)

Risk & Control Self Assessment (RCSA)
This workflow can be used to establish, execute, and progress through a qualitative risk assessment. Steps include: a risk owner manually kicks off the Risk & Control Self Assessment (RCSA) workflow, performs an inherent risk assessment by identifying the inherent impact and likelihood, performs a residual risk assessment by evaluating the residual impact and likelihood, and submits the RCSA for completion.
Control Assessment
A control assessment needs to be performed before the RCSA workflow can be complete. This workflow can be used to progress through your control assessment. Steps include: a control owner manually kicks off the Control Assessment workflow, performs the control assessment by evaluating the control design and operating effectiveness, and submits for approval. The Control/Risk owner or RCSA coordinator can reject the control and send back for review, or approve and close, marking the control in Approved status.

Control testing workflows

The following workflows related to the Test Plan and Test Result objects are included:
  • Create Test Result
  • Perform Control Test
  • Update & Review Test Plan

The Create Test Result workflow automatically creates a Test Result based on the schedule or frequency that is defined in the parent Test Plan. When the next due date comes for an active Test Plan, this workflow automatically creates a new Test Result, and populates it with test performer and test due date information from the parent Test Plan. With the Perform Control Test workflow, the test goes through its performance, review, documentation request (if required), and an issue is even automatically created if the test result has failed.

Loss Event Review workflow

The Loss Event Review workflow is similar to the configurable lifecycle for Loss Events.

In this workflow, take note of the following elements:
  • Different paths based on an amount value

    The workflow provides different levels of approval (approval level 1 and approval level 2) based on the gross loss value of the loss event.

  • Use of preference objects

    Approval level 1 and approval level 2 are retrieved from the Preference object. There are different approvers based on the division where the loss event occurred. Study this example if you want to learn more about how to implement a Preference object in workflows.

Figure 8. Loss Event Review workflow
The Workflow Editor shows the stages in the workflow: Start, In Progress, In Review, two Approval stages, and Closed.

Questionnaire Assessment workflow

The Questionnaire Assessment workflow moves a questionnaire assessment through the information gathering, review, and approval stages.

The Workflow Editor shows the stages in the workflow: Start, Information Gathering, Review, Approval, and Closed.

Workpaper workflow

The Workpaper workflow uses the Workpaper System Task view and depends upon the out-of-the-box schema for Workpaper and related object types.

There are multiple types of Workpapers, for example Notification Letters and Test Evidence. However, the sample workflow is high level and not defined for one specific type. In the Workpaper workflow you create, you will likely define it for a specific type of Workpaper, in which case, you can choose to have separate workflows for each type or one workflow with separate branches with conditions that specify the type.

In this workflow, take note of the following elements:
  • Who can view the Actions button

    The final two forward actions, Send for Review and Approve and Complete, are restricted to specific users, the preparer and the reviewer, respectively. These actions are displayed only to them. For all other users, there is no action on the Actions button. When you encounter a situation like this, you can add an explanation to the user guidance for the stage that explains why there is no option on the Actions button.

Figure 9. Workpaper workflow
The Workflow Editor shows the stages in the workflow: Start, Workpaper Schedule and Resource Plan, Workpaper Preparation, Workpaper Execution, Workpaper Review, and Workpaper Completed.
Figure 10. The specification for the Workpaper workflow
A flow diagram of the Workpaper workflow, from planning to workpaper completion.