CreditLens Business Process and Collaboration Tool Configuration Guide

28 JUNE 2019
CreditLens™ Business Process and

Collaboration Tool Configuration Guide
Version 5.19.22
Contact
Moody's Analytics Support

+1-212-553-1653
MA_TechSupport@moodys.com
www.moodysanalytics.com/support
MOODY'S ANALYTICS
CONFIDENTIAL
This document contains information proprietary to Moody's Analytics, Inc. ("Moody's") and its affiliates. This information may not be reproduced,
disclosed, or used in whole or in part without the express written permission of Moody's.
TRADEMARKS
Moody's Analytics, Moody's, and all other names, logos, and icons identifying Moody's Analytics and/or its products and services are trademarks of
Moody's Analytics, Inc. or its affiliates. Third-party trademarks referenced herein are the property of their respective owners.
© 2019 Moody's Analytics, Inc. and/or its licensors and affiliates (collectively, "MOODY'S"). All rights reserved.
Table of Contents
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 BPMN and CMMN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Lab: Understanding BPMN 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Subprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Lab: Understanding CMMN 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Sentries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Lab: Business Rules and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 What are Variables? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Combining Business Rules and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Where Can a Workflow Call Business Rules? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4 What Type of Business Rules Can be Triggered From a Workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 How is a Business Rule Triggered From the Workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5.1 Service Task, Decision Task, Business Rule Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.2 Execution Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.3 clExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Lab: Creating a BPMN Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Setting Up the Camunda Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Create a BPMN diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Create User Tasks and Exclusive OR Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Adding a Business Rule to a Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 Add an AND/Parallel Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6 Add Service and Business Rule Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
CreditLens™ Business Process and Collaboration Tool Configuration Guide Moody's Analytics Confidential Information - Do Not Redistribute iii
MOODY'S ANALYTICS
5.7 Add an OR/Inclusive Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.8 Add Alternate Execution Paths with Timer Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.9 Configure the Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.9.1 Create XorCheck Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.9.2 Create the DoTask6 and DoTask7 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.9.3 Create the Task9 Rule for Candidate Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.9.4 Create Alert Rule on Task10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10 Create the Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.11 Deploying the Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.12 Run the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 Lab: Creating a Nested Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.1 BPMN and CMMN Strengths and Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Outer BPMN Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 StageOne CMMN Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4 StageTwo CMMN Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5 Testing the Nested Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7 Lab: Workflow Screens Walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.1 Design-time Workflow Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.1.1 Business Process > Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.1.2 Business Process > Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2 Run-time Workflow Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2.1 Proposal > Initiate Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2.2 Proposal Center > Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2.3 Proposal Center > Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.4 Proposal Center > Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.5 Proposal Center > Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.6 Proposal Center > Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2.7 Proposal Center > Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8 Lab: Workflow Configuration Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8.1 Key Configuration Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.2 Does Your Proposal Have Custom Attributes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.2.1 Create the Extension Model From Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.2.2 Add Associations with the Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
iv Produced by Moody's Analytics - ERS Technical Communications CreditLens™ Business Process and Collaboration Tool Configuration Guide
8.2.3 Add the Attributes from the Extension Model to Proposal View Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.2.4 Add the Extension Model to the ProposalTypeMapping Reference Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.3 Do You Have Tasks in Your Proposal that Have Custom Attributes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.3.1 Create the Extension Task Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.3.2 Add the Attributes from the Extension Task Model to ProposalTaskInfo View Model . . . . . . . . . . . . . . . . . . 96
8.3.3 Add a Business Process Task to Represent Custom Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.3.4 Add the Extension Model and Business Process Task to the TaskTypeMapping Reference Data . . . . . . . . . 98
8.4 Your Custom Attribute is Reference Data-Based and You Want to Filter the Values by Task or Proposal . . . . . . . . . . 99
8.4.1 The Data Type for the Custom Attribute Has to be a Reference Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.4.2 Add the Reference Data Type That is the Filter for our Reference Data Type . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.4.3 The Filtering Reference Data Type Must Indicate Its Filter Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.4.4 The View Model Must Contain an Attribute of the Filter Reference Data Type . . . . . . . . . . . . . . . . . . . . . . . 102
8.5 Registering Artifacts with Reference Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9 Lab: The Workflow Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

9.1 Workflow Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.2 Leveraging Artifacts That Are Part of the Workflow Module in Custom Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.2.1 Using the Standard Credit Proposals as a Starting Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.2.2 Incorporating Standard Tasks into Custom Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.2.3 Using a Preconfigured Business Status Attribute for a Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.2.4 Using a Preconfigured Business Status Attribute for a Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.2.5 Reusing Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10 Lab: Configuring a Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

10.1 Standard CreditLens Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.2 Defining a Business Process Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.3 Register with the TaskTypeMapping Reference Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11 Lab: Configuring an Editable Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

11.1 Building an Editable Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.2 Managing Module Visibility for Task Assignees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
12 Lab: Configuring an Approval Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

12.1 Building an Approval Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
13 Lab: Configuring Alerts, Notifications, and Email Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

13.1 Alerts and Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
13.1.1 Customizing Alerts and Notifications Using Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.2 Workflow Notifications and Email Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
CreditLens™ Business Process and Collaboration Tool Configuration Guide Moody's Analytics Confidential Information - Do Not Redistribute v
MOODY'S ANALYTICS
13.2.1 Configuring Workflow-Related Alerts, Notifications, and Email Messages Using WorkflowEvents Reference
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
13.2.2 Message Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
vi Produced by Moody's Analytics - ERS Technical Communications CreditLens™ Business Process and Collaboration Tool Configuration Guide
1 Overview
The CreditLens™ Business Process and Collaboration Tool enables you to design and adapt client-defined
business processes for your organization.
You can leverage the CreditLens Business Process and Collaboration Tool and interface features to create
workflows within your organization by assigning tasks and deadlines to an individual user or a group of
users in the same business or credit portfolio.
This manual consists of a series of labs that will guide you through the process of building workflows for
CreditLens.
1.1 BPMN and CMMN Models

At a high-level, CreditLens supports workflows or business processes by implementing two standards:
Business Process Model and Notation (BPMN 2.0)
Case Management Model and Notation (CMMN 1.1)
Note The preceding links contain the specifications for the standards and can be reviewed in detail;
however, it is not necessary to understand the specification documents in detail to use these
standards in CreditLens to build workflows. The purpose of the labs is to educate and train
users on using the elements provided by these standards to build workflows for CreditLens.
The BPMN 2.0 standard is used when the process and the tasks to be performed are mostly known in
advance and the process can be predefined. Thus, the entire process can be modeled with this information
as a flow chart. This does not mean that the BPMN standard is sequential; in fact, it is powerful and can
support conditional logic and event-driven logic to fork and join the process. This is why it is best
described as a flow chart.
The CMMN 1.1 standard is used in cases where it is not always known in advance which tasks might be
required and which can be ignored. Also, some tasks might only be activated for certain scenarios. On a
case-by-case basis, the user or the system can make these decisions, as the case is executed. Additionally, if
there is a need to manage the case in stages, like a state machine rather than a flowchart and track
milestones associated with the case, then CMMN is a better option.
A BPMN or CMMN modeler is used to model the actual process. The modeled process is connected to
CreditLens in the following ways:
CreditLens™ Business Process and Collaboration Tool Configuration Guide Moody's Analytics Confidential Information - Do Not Redistribute 7
MOODY'S ANALYTICS
A domain model that extends the proposal model is defined in CreditLens configuration with the same
model ID as the ID of the process in the modeler. This proposal domain model should be configured
appropriately by connecting it to a reference model on which the proposal is initiated.
If the human tasks in the process are to be connected with a particular CreditLens menu so that
CreditLens specific functions can be displayed, then a domain model that extends the base Task model
is defined in CreditLens configuration. This task model can then be connected to a menu. If a
composed task model is not created, then a default task user interface appears that contains basic
information about the task.
The modeled process is uploaded into CreditLens. At which point, it is deployed into the CreditLens
database and is available to be initiated as a proposal.
Rather than building a proprietary workflow engine, CreditLens has taken the route of embracing and
adopting these standards as well as integrating a popular open-source workflow engine that has faithfully
implemented the elements in these standards. The Camunda workflow engine is used by CreditLens. This
allows CreditLens to focus on integrating the workflow engine with the configurable platform while
allowing our clients to leverage the power of these standards to model complex and comprehensive
processes and cases. As the standards grow and mature further, the Camunda engine adopts and
implements the capabilities of the standards, and the CreditLens platform's workflow capabilities grow as a
result. Adhering to these standards also allows CreditLens not only to be the overarching workflow solution
that banks use to design and implement their end-to-end workflow, but it also allows the workflows in
CreditLens to integrate as steps into a larger workflow at a bank. Banks can use the same standards they are
used to in other workflow engines within CreditLens and a comprehensive REST API allows banks to
programmatically initiate CreditLens workflows.
The following are the key components of the Workflow or Business Process framework in CreditLens:
Component Description
Workflow This is the underlying third-party Camunda workflow engine that is integrated into the CreditLens
Engine product. This engine provides the ability to execute a process defined using BPMN or CMMN
standard that are created using a modeler.
Configuration These are the artifacts in CreditLens that help you configure a proposal and associated tasks or
Artifacts stages in the workflow framework once a process model has been created and uploaded into
CreditLens. The artifacts are based on standard CreditLens configuration concepts like domain
models, reference data, and view models.
Business The Business Rules Engine acts as a conduit between the workflow engine and CreditLens. When
Rules the workflow routing is driven based on domain-specific logic, CreditLens implements this logic in
Engine business rules, which have access to domain data that influences the flow of the business process.
Workflow The Workflow module is an out-of-the-box module that ships with CreditLens. This module contains
Module the standard Credit Proposal implementation as designed by Moody's product team. It also contains
the configuration artifacts that are used by the standard Credit Proposals including the domain
models, tasks, and reference data. These artifacts can be reused by custom workflows rather than
redefining them, which reduces the amount of configuration work needed to create custom workflows.
8 Produced by Moody's Analytics - ERS Technical Communications CreditLens™ Business Process and Collaboration Tool Configuration Guide
2 Lab: Understanding BPMN 2.0
BPMN 2.0 is an elaborate and comprehensive workflow standard. There are many elements in BPMN 2.0,
but the four main element categories are:
1. Tasks
2. Gateways
3. Events
4. Subprocess
CreditLens uses these elements, as they are implemented by the Camunda engine. Therefore, the most
comprehensive way to understand BPMN 2.0 is to review the Camunda documentation on BPMN 2.0.
Note The Camunda engine has the most comprehensive support of any implementations of BPMN
2.0 for all the elements in the standard. The main page in the preceding link visually shows the
elements that have been implemented by Camunda.
Following is a summary of the most-frequently used BPMN elements for modeling processes for
CreditLens.
2.1 Tasks
Tasks represent units of work within the process.
Task Description
User The User Task represents a task in the process that will be completed by a CreditLens user. This might
Task involve some type of interaction through the CreditLens user interface to complete this task.
MOODY'S ANALYTICS
Task Description
Service The Service Task represents processing that can be done by the system without human intervention. This
Task could be a long-running process like a batch process, or it could be as simple as executing a business
rule.
Business The Business Rule Task allows a business rule to be executed, and the result of the rule can be used to
Rule influence the process flow.
Task Note Both a Service and Business Rule Task can be used to call a business rule, and it is OK to
use either.
2.2 Gateways
Gateways are used to fork or join the process flow in different manners.
Gateway Description
XOR The Exclusive OR (XOR) Gateway is used to conditionally fork the process. Each pathway leading out of
Gateway an XOR Gateway must have a condition defined on it. The condition is evaluated to determine whether to
make that particular path active or not. In an XOR gateway, at most, only one pathway can be activated.
Therefore, if multiple conditions evaluate to true, the workflow raises an exception.
AND Also referred to as the Parallel Gateway, the AND Gateway allows multiple execution paths to be started
Gateway concurrently. When forking, all pathways leading out of an AND Gateway are started unconditionally.
When joining, all execution paths leading into an AND Gateway are awaited before process execution
moves on.
OR Also referred to as the Inclusive gateway, the OR Gateway is a combination of the XOR and AND
Gateway Gateways. When forking, one or more of the pathways leading out of the OR Gateway are executed
based on condition evaluation. Unlike the XOR gateway, multiple execution paths can be activated. When
joining, only the pathways that were activated need to join before process execution moves on.
Event The Event Gateway can have multiple outgoing paths each of which can have a message, timer, or signal
Gateway event associated with it. When one of the events is raised, the pathway associated with that event is
followed. This allows external sources or other parts of the process to trigger what happens within the
process.
2.3 Events
Events are used to allow the process to communicate with the outside world and other processes by
awaiting events and raising events. The message, timer, and signal events can be used by combining them
with the start and end events. They can also be used by themselves. When used by themselves, they are
referred to as intermediate events. Message, signal, and timer events can also be used on boundaries of tasks
to set up alternate execution paths.
Event Description
Start This event starts a new process. The start event can be started manually, started by a message, started
Event by a signal, or started by a timer.
End This event signifies the end of the process. It can notify that the process has ended through a message or
Event signal.
Message This event can be used to await a specific message meant for only this process from some external
Event source. Process execution can await this event before it continues. It can also be used to raise an event
to another part of the current process.
Timer This event can be used to wait for a certain amount of time before process execution continues. When
Event used as a boundary event, it can be used to provide alternate execution paths after a certain period of
time.
Signal This event can be used to await a broadcast signal from some external source. Process execution can
Event await this event before it continues. It can also be used to broadcast a signal to other external processes
or systems.
2.4 Subprocess
MOODY'S ANALYTICS
Subprocess can be used to start subprocesses within the same process or trigger external processes.
Subprocesses can be set up to be within the scope of the parent process or be independent processes that
can be triggered by other processes. Subprocesses can be combined with events to set up interrupting or
non-interrupting subprocesses. Interrupting subprocesses cause the parent process to await the completion
of the subprocess.
Subprocess Description
Subprocess A subprocess can be used to start another process embedded within the current process. The
subprocess is only available to the current process and cannot be seen externally by other processes.
Call Activity A call activity can be used to start another process that is not embedded within the current process.
This is an independent process that can also be triggered as a subprocess of the current process. A
call activity can also be used to start a CMMN case.
3 Lab: Understanding CMMN 1.1
CMMN 1.1 is an elaborate and comprehensive workflow standard. The five main element categories are:
1. Tasks
2. Stages
3. Milestones
4. Sentries
5. Markers
CreditLens uses these elements, as they are implemented by the Camunda engine. Therefore, the most
comprehensive way to understand CMMN 1.1 is to review the Camunda documentation on CMMN 1.
Note Currently, Camunda is the only workflow engine that has an implementation of the CMMN
1.1 standard. The main page in the previous link shows the constructs that have been
implemented by Camunda.
Following is a summary of the most-frequently used elements when modeling processes for CreditLens.
3.1 Tasks
Tasks represent units of work within the case.
Task Description
Human The HumanTask represents a task in the case that will be completed by a CreditLens user. This might
Task involve some type of interaction through the CreditLens user interface to complete this task.
Decision The Decision Task allows a business rule to be executed, and the result of the rule can be used to
Task influence the case flow.
MOODY'S ANALYTICS
Task Description
Case The Case Task can be used to trigger another CMMN case from within the current case. The other case
Task effectively becomes a sub case of the current case.
Process The Process Task can be used to trigger a BPMN process from within the current case. The process
Task effectively becomes a sub process of the current case.
3.2 Stages
Stages are used as containers of tasks. There can be multiple stages in a case. Dependencies can be set up
between stages, or they can execute in tandem. Rules can be applied as to when a stage is complete by
configuring the tasks within the stage. Stages are an optional element and are not required in a CMMN
case. Tasks can exist both within and outside stages in a CMMN case.
3.3 Milestones
Milestones are used to mark intermediate milestones within a case execution over and above stages. There
can be multiple milestones within a single stage. There can also be milestones outside the scope of a stage
that are reached when multiple stages are completed. In addition, milestones can also be used in a CMMN
case without stages.
3.4 Sentries
Sentries are used to conditionally control the execution of the case, stage, task, and milestone elements in a
CMMN case. There are two types of sentries - entry and exit. The sentry itself can contain OnPart and
IfPart conditions. OnPart conditions are evaluated first through pathways to the sentry. IfParts are defined
as conditions on the sentry itself and are evaluated last.
Sentry Description
Entry Entry criteria are conditions that can be defined to control when a CMMN element like a case, stage, task,
Criteria or milestone become enabled.
Exit Exit criteria define the conditions that are to be met when execution leaves the element attached to the
Criteria sentry like a case, stage, task, or milestone.
3.5 Markers
Markers provide the ability to control the behavior of stages, tasks, and milestones.
Marker Description
Manual The Manual Activation marker controls whether a stage, task, or milestone must be manually activated
Activation during case execution. This can be done through user action or by defining a condition. This marker can
be used to eliminate unnecessary tasks in certain case instances and can be activated as needed.
Required The Required marker controls where a stage, task, or milestone is required during case execution. This
enforces that unless that particular element is completed the case execution cannot move on. This can
only be controlled through a condition not through user action.
Auto The Auto Complete marker controls whether a stage automatically completes when all conditions at the
Complete task and milestone level are met or if the user has to manually mark the stage as complete. The Auto
Complete marker only applies to stages.
Repetition The Repetition marker controls whether a stage, task, or milestone can be repeated multiple times and
the conditions under which they are repeated. This can only be controlled through a condition not
through user action.
MOODY'S ANALYTICS
4 Lab: Business Rules and Variables
CreditLens implements a comprehensive business rules engine as part of its framework. This includes the
implementation of a decision table that is based on the Decision Model and Notation (DMN) standard.
The rule engine is integrated with the CreditLens domain modeling system thus providing a rich
experience to the end user to design workflows and integrate the workflows with the rules engine. While
rudimentary business rules can be designed using decision tables and natural language, more complex rules
might need to be authored using C#. CreditLens does not use the DMN decision engine implemented by
Camunda; instead, it has its own internal implementation of a comprehensive and integrated business rule
engine.
4.1 What are Variables?

Variables act as a way to pass information between CreditLens and the BPMN or CMMN workflow.
Variables are storage containers for data. Variables allow a clear separation to be maintained between
CreditLens and the Camunda workflow engine, so there is not a direct dependency on a particular engine.
When CreditLens wants to retrieve information from the workflow, it gets a variable that is set by the
workflow to obtain that information. When CreditLens wants to pass information to the workflow, it sets a
variable that is then used by the workflow in some manner. Essentially, variables act as conduits to carry
information between CreditLens and a running instance of a workflow.
Variables can be of any data type, but they are most often primitive types such as boolean, integer, decimal,
or string. Variables are most often used to make decisions in the workflow that impact the flow control
within the workflow. For example, a Boolean value might be used to fork a BPMN process, or it might be
used as an entry criteria for a stage in a CMMN process, but the decision is not made in a vacuum. It is
based on data generated within CreditLens, data associated with an entity or its financials or rating. This is
where business rules come in.
4.2 Combining Business Rules and Variables

Business rules can be used to access the data in the CreditLens domain. The data can then be used to write
complex conditions that can influence the behavior of the workflow. Business Rules also act as a bridge
between CreditLens and the workflow. When the workflow needs to interact with CreditLens to make a
decision, it only does this by calling a business rule. Then the rule can get and set variables in the workflow.
MOODY'S ANALYTICS
The rule also has access to the workflow context information, which tells the rule the task being executed
and the proposal information. This ensures that all CreditLens-specific code is kept in the business rule,
away from the workflow model itself and captures all the business logic that influences the decision in a
centralized manner through the rules engine. The workflow model itself purely focuses on the flow of the
process itself.
4.3 Where Can a Workflow Call Business Rules?

A workflow uses business rules whenever it wants to invoke some business logic within CreditLens. This
logic might be used to get data in to the workflow in the form of variables, or it might be used to retrieve
data that is used to make decisions on how the process continues to flow. The following table lists all the
scenarios in which business rules are used in a workflow.
Scenario Description
Service or A business rule can be used as the piece of logic to execute when a Service or Business Rule task
Business becomes active in a workflow. The executed business rule can return data back to the workflow in the
Rule or form of a result variable. This result variable can be used to make decisions in subsequent workflow
Decision elements like a gateway.
Task
Execution Execution Listeners can be triggered from almost all workflow elements in both the BPMN and CMMN
Listeners standards. These are listeners that fire rules that can be based on the proposal model, as the proposal
model is the equivalent of the workflow itself, and execution event listeners are executed at workflow
scope.
Task Task Listeners are similar to Execution Listeners with the distinction that they are only applicable to
Listeners tasks and are raised on unique events applicable to tasks like Complete and Assigned. Therefore,
these listeners can fire rules that are based on the task model.
4.4 What Type of Business Rules Can be Triggered From a

Workflow?
The preceding diagram depicts the communication between the workflow and the business rules engine.
The Workflow Context is a common bridge between the two. The variables are unique to a particular
workflow instance and stored with the workflow. The rules engine accesses the variables through the
workflow context but does not maintain the variables. The variables are always stored and managed by each
and every workflow instance.
When the workflow hits an event listener or a service, business rule, or decision task, those points can be
used as triggers for firing a business rule. A business rule triggered from a workflow can be based on the
following:
Task model - The rule fired from a workflow can be defined on the task model, which will have access
to all the task attributes. These rules can only be fired from a task event listener, as this is the only
location from where the current task's information can be passed on in to the rule. The rule can then
leverage data from the task as part of its decision-making process.
Proposal model - The rule fired from a workflow can also be defined on the proposal model, which will
have access to all the proposal attributes. These rules can be fired from any of the workflow elements, as
most workflow elements have the ability to trigger execution listeners.
Multi-model - These rules can be fired from any location within the workflow. When a multi-model
rule is fired from an execution listener, the rule context is automatically populated with both the
proposal information as well as the reference model of the proposal. So, if Entity is the reference model
for a proposal, then the appropriate entity is added to the rule context. If a multi-model rule is fired
from a task listener, in addition to the proposal and reference model information, the task information
is also populated in to the rule context.
Non-model - You can also simply fire a non-model rule that is not based on any particular model or
multi-model from a workflow.
4.5 How is a Business Rule Triggered From the Workflow?

As mentioned previously, business rules can be triggered from the workflow from three locations. The
following describes how the rules are configured directly in the Camunda modeler.
4.5.1 Service Task, Decision Task, Business Rule Task

A business rule can be triggered from each of these task types by doing the following:
MOODY'S ANALYTICS
The first item to change in the modeler is the Implementation field. Set this field to Expression. The
format for the expression is:
${clExtension.executeRule('<RuleName>', task)}
The name of the business rule that you want to trigger must be specified in between the single quotes. The
rest of the expression always stays the same when called from a service, business rule, or decision task.
4.5.2 Execution Listener

A business rule can also be triggered from any other workflow element using an execution listener.
The first item to change in the modeler is the ListenerType field. Set this field to Expression. The format
for the expression is:
${clExtension.executeRule('<RuleName>', execution)}
The name of the business rule that you want to trigger must be specified in between the single quotes. The
rest of the expression always stays the same regardless of which workflow element is triggering the rule.
4.5.3 clExtension
The clExtension object is an object that is available in the modeler for use in writing expressions. For
business rule execution, the clExtension object supports two methods:
executeRule - This returns a boolean value of true or false depending on what is set as the return value
of the business rule in CreditLens.
executeRuleMap - This returns a Map object that contains key/value pairs. The values in the map object
can be accessed using the "[<key>]" syntax. It is important for the caller to know the data type of the
value associated with the key so that the value is used appropriately in the expression.
MOODY'S ANALYTICS
Both methods take the name of the business rule to trigger as the first parameter. The second parameter is
either the execution or the task object. The following table provides guidance around what parameter to
use in the call to executeRule or executeRuleMap and under what circumstances.
Second Scenario Rule

parameter domain
model
execution Always pass execution as the parameter to invoke the executeRule or executeRuleMap Proposal
method in the modeler when the rule is not being invoked in a task listener. or Multi
Model
task The only scenario in which task is the parameter to invoke the executeRule or Task
executeRuleMap method in the modeler is when it is being invoked from a task listener.
The business rule defined in CreditLens requires a model to be specified when defining the business rule.
For example, the preceding rule is defined on the proposal model. For business rules that are called from
the workflow, there are three options for the Model field.
Proposal - Use Proposal as the model on which the business rule is defined if you want to access
attributes of the proposal in your rule. Also, use Proposal as the model if you are not sure which model
to use for the rule as the Proposal is always available for all rules that are triggered from a workflow.
Task - Use Task as the model only on business rules that are triggered from a task listener. Task is not
an option for business rules triggered from any other location in a workflow.
Multiple Models - You can choose to use Multiple Models as the model for business rules that are
triggered from anywhere in the workflow. Using Multiple Models indicates your intention to access one
or more models within the business rule; however, there is no guarantee that the model you are trying to
access will be present, so it is necessary to code your rule accordingly with appropriate checks.
MOODY'S ANALYTICS
5 Lab: Creating a BPMN Process
In this lab, we will be creating a BPMN process. The objective of this lab is to learn the common elements
of BPMN rather than building a specific type of process from a business standpoint. This gives the authors
of BPMN processes a good understanding of the key elements in BPMN, so they can make an informed
decision on the right elements to use to construct a business process based on the scenario being modeled.
In this lab, we will demonstrate the following elements of the BPMN standard:
MOODY'S ANALYTICS
5.1 Setting Up the Camunda Modeler

In this lab, we will use the standalone Camunda Modeler, which can be downloaded from here.
Select the appropriate download based on whether you want to use the 32-bit or 64-bit version of the
modeler on Windows. Once you have downloaded and extracted the ZIP package into a folder, double-
click the camunda-modeler.exe to start the modeler application.
5.2 Create a BPMN diagram
When the modeler is started, you should land on a screen that looks like this.
MOODY'S ANALYTICS
From this screen, you can create either a BPMN or CMMN diagram. The modeler is used for both types
of models. In this lab, we will focus on the BPMN diagram.
Click Create a BPMN Diagram to create an empty BPMN diagram.
Give the BPMN process a name as shown in the following image.
If we did not have a pool in our BPMN process, the Id field shown in the previous image would be the ID
of our process. However, because we are choosing to model our BPMN process with a pool/swimlane, we
need to select the pool artifact to provide the actual Process Id as shown in the following image. This will
be the ID used for the process when we upload it into CreditLens. If we did not have a pool element, the
ID in the preceding image would be used when we upload the process into CreditLens.
MOODY'S ANALYTICS
In the designer surface, select a Pool/Participant element from the toolbox on the left, and drop it in the
designer surface as shown in the following section. Divide the lanes in the pool into two lanes and label the
lanes as shown in the preceding image. At this point, what we have on the designer surface are two swim
lanes that represent the two roles that participate in the process. Additionally, we have the basic starting
element that represents the start of the process. We are doing this to demonstrate the pool/participant
element that allows you to visually depict the transition of tasks between roles in the process. It is not
necessary to use this element if you do not want to show this visually, but it allows the process diagram to
be more user-friendly when modeled in this manner. Save this model as SampleBpmn.bpmn.
5.3 Create User Tasks and Exclusive OR Gateway

The first element we will be modeling is a user task. The user task represents a task in the process that will
be completed by a CreditLens user. This might involve some type of interaction through the CreditLens
user interface to complete this task. The second element we will be modeling is an exclusive OR gateway.
The exclusive OR (XOR) gateway is used to conditionally fork the process. Each pathway leading out of an
XOR gateway must have a condition defined on it. The condition will be evaluated to determine whether
to make that particular path active or not. In an XOR gateway, at most, only one pathway can be activated.
Therefore, the workflow will raise an exception if multiple conditions evaluate to true.
The result should look like the preceding image. The pathways leading out of the first XOR gateway are
called the diverging paths. The pathways leading into the XOR gateway at the end are called the
converging paths. Diverging paths are where decisions are made leading out of a gateway and forking the
process. Converging paths do not have conditions on them and are intended to bring multiple forked paths
together before the process moves ahead.
Select the Start element, and use the context-sensitive tools menu to select the task element as highlighted
in the preceding image to create a task element attached to the start element. The context-sensitive tools
menu allows you to quickly add the next element to the designer surface without having to drag the
element from the toolbox.
MOODY'S ANALYTICS
Set the task type of the tasks that you are adding to be User Task by selecting the wrench tool from the
context-sensitive tools menu.
Select the user task, and make sure that a value is entered for the Id and the Candidate Groups fields. The
Id gives a unique identifier to the task. Name the three tasks created above as Task1, Task2, and Task3.
For the Candidate Groups field, we are assigning these tasks to Role1, which means that any user who is in
Role1 will be able to see and work on these tasks. Alternatively, you can also explicitly set the Assignee field
to a specific user or the Candidate Users field to a list of users separate by commas. Later, we will also see
how you can set these fields to call a business rule that determines the assignee.
The XOR gateway is added similarly to the user task by using the context-sensitive tools menu. Add the
XOR gateway by picking the highlighted element shown in the preceding image and establishing a
connection between the user task Task1 and the gateway.
MOODY'S ANALYTICS
5.4 Adding a Business Rule to a Gateway

Since we added an XOR gateway before the Task2 and Task3 tasks, we know that only one of those two
tasks will get executed. We now need to use a conditional check in the XOR gateway to determine which
of those two tasks should be executed. We will do this by adding a business rule to the XOR gateway by
selecting the gateway and using the Listener tab to add the business rule as shown in the following image.
We add an execution listener for the start event on the XOR gateway. Change the Listener Type to
Expression and add the expression shown above to trigger a rule named 'XorCheck'. For more information
on Listeners and calling business rules, refer to the lab on Business Rules and Variables. At this point, the
process is set up to call the XorCheck business rule whenever the XOR gateway is triggered by the
workflow. The rule will evaluate and set a variable. The variable it will set will be a Boolean variable called
'DoTask2'. This variable can be either true or false. If it is true, we will execute Task2, if it is false we will
execute Task3.
Note We will finish modeling the BPMN process completely before circling back to implement all
the business rules inside CreditLens.
Select the arrow or sequence flow coming out of the gateway toward Task2. In the General tab, set the
Condition Type to Expression, and enter the expression shown in the preceding image. This checks for the
variable DoTask2 having a value of true, in which case we want Task2 to be started by the workflow.
MOODY'S ANALYTICS
Alternatively, select the arrow or sequence flow coming out of the XOR gateway toward Task3, and set its
expression as shown above to check that DoTask2 has a value of false. This ensures that either Task2 or
Task3 will be started.
Warning! It is important that as the author of the workflow, you ensure that only one of the pathways
leading out of an XOR gateway will evaluate to true. If multiple paths evaluate to true, the
workflow will throw an error during execution, which is not a desirable. Therefore, it is
important to set the appropriate conditions in the outgoing pathways, and debug and test the
worfklow to ensure that the business rule is performing appropriately. We cover debugging and
testing workflows in the Lab: Debugging and Testing a Proposal lab.
5.5 Add an AND/Parallel Gateway
In the next step in the process, we want to add an AND gateway. This is also referred to as the parallel
gateway. The AND gateway allows multiple execution paths to be started concurrently. When forking, all
the pathways leading out of an AND gateway are started unconditionally. When joining, all execution
paths leading into an AND gateway are awaited before process execution moves on.
The context-sensitive tools menu can be used to join a parallel gateway to the converging XOR gateway as
shown in the preceding image.
5.6 Add Service and Business Rule Tasks

The two parallel tasks that will be executed within the scope of the parallel gateways, as shown in the
preceding image, will be Task4 and Task5. Task4 will be a business rule task, and Task5 will be a service
task. We will be setting both of these tasks to execute business rules.
MOODY'S ANALYTICS
Select Task4, and set its type to Business Rule task using the wrench widget. Set the Implementation field
to Expression and the Expression value as shown above. We are calling a business rule named DoTask6,
which will return a Boolean value. The Boolean value will be captured in the Result Variable named
DoTask6, which we enter in the Result Variable field. This is an alternative way to creating a variable
instead of creating the variable inside the business rule code. The return value of the business rule can be
captured as a variable in the modeler as shown in the preceding image.
Repeat the same for Task5, except set the task type for Task5 to a service task. Both business rule and
service tasks are very similar when setting the Details in the properties section of the modeler. In this case,
we are calling the DoTask7 rule and capturing the result in the DoTask7 Boolean variable.
At this point, we are ready to transition our process from Role1 to Role2 and expand our process to include
additional elements as shown in the following diagram. Notice that we are transitioning from Role1 to
Role2 in the pool/swimlane.
MOODY'S ANALYTICS
5.7 Add an OR/Inclusive Gateway

Also referred to as the inclusive gateway, the OR gateway is a combination of the XOR and AND
gateways. When forking, one or more of the pathways leading out of the OR gateway are executed based
on condition evaluation. Unlike the XOR gateway, multiple execution paths can be activated. When
joining, only the pathways that were activated need to join before process execution moves on. The
business rules that executed in Task4 and Task5 are intended to determine whether Task6, Task7, or
Task8 will be executed. The inclusive OR gateway allows us to execute both Task6 and Task7 as opposed
to the exclusive OR gateway, which only allowed us to execute one of multiple execution paths.
The pathways leading out of the task can be selected in the designer and condition expressions can be
added to them. Add the conditions expressions shown in the preceding image from left to right for Task6,
Task7, and Task8. The idea being that Task6 is started when DoTask6 evaluates to true, Task7 is started
when DoTask7 evaluates to true, and Task8 is started when both DoTask6 and DoTask7 evaluate to false.
MOODY'S ANALYTICS
Task6, Task7, and Task8 are marked as user tasks, and each is assigned to Candidate Groups Role2 instead
of Role1 as shown above. This is reflective of the overall diagram also transitioning between the Role1 and
Role2 swimlanes indicating that the tasks are now going to a different group of users.
5.8 Add Alternate Execution Paths with Timer Event

The last step in our BPMN process will be to create an alternate execution path using a timer event as
shown in the following image.
The converging inclusive gateway leads into user task Task9. We add a boundary timer event to Task9 by
first dragging an intermediate event onto the designer surface from the toolbox.
MOODY'S ANALYTICS
Attach the intermediate event to the Task9 User task as shown in the preceding image, and change the type
of the event to be a Timer Boundary Event. A boundary event that is attached to a task is fired when the
condition for the boundary event is met. In this case, we are attaching a time-sensitive event to the Task9
task, which will trigger an alternate route in the workflow. Now, we need to set the Timer event properties
to let the workflow know how it should be triggered.
With the Boundary Timer Event selected in the designer, select the wrench widget from the context-
sensitive tools menu to set the properties of the timer event. We need to select the Timer Definition Type.
There are three options - Date will trigger the timer on a particular date; Duration will trigger the timer
after a specified duration of time, and Cycle will trigger the timer periodically. You can find more
information about the Timer Event support in Camunda here. The Timer Definition field is based on the
ISO 8601 standard. We set it accordingly to trigger in a duration of one minute with the value of
"PT1M".
The alternate route for the workflow when the timer event is triggered is Task10, which is a business rule
task that will fire an alert.
MOODY'S ANALYTICS
We make Task10 a business rule task using the context-sensitive tools menu. We can then set the
Implementation field to be an Expression, and set the Expression as shown in the preceding image. We are
triggering a business rule named TaskNineAlert, which will send an alert to a user. Both Task9 and Task10
are then terminated in an End event that completes the workflow.
Lastly, we will be using a business rule to dynamically determine what role Task9 is assigned to rather than
statically specifying it in the modeler. We can do this by configuring a business rule on the Candidate
Groups field of Task9 as shown in the following image.
At this point, we have modeled the BPMN process in its entirety as shown in the following image.
The next step is to use CreditLens to configure the business rules and roles that are leveraged by our
workflow. To do this, log in to the CreditLens application with user credentials that have access to the
Configuration and Administration tools.
5.9 Configure the Business Rules

We will use the Configuration section and the Business Rules Engine to set up the business rules used by
the workflow as shown in the following screenshot.
MOODY'S ANALYTICS
5.9.1 Create XorCheck Rule

We will first create the XorCheck rule. This rule will determine whether Task2 or Task3 is started in the
workflow by setting a Boolean variable named DoTask2.
Configure the XorCheck rule as shown in the preceding image. We are keeping this rule simple by
hardcoding the rule to always execute Task2. If you want to test with executing Task3 instead, you can
simply modify the rule to set DoTask2 to false. The SetVariable API available on the Process object allows
us to modify an existing workflow variable or introduce a new workflow variable. In this case, we are
introducing the DoTask2 variable. If you recall, the outgoing pathways of the XOR gateway are set to do
conditional checks on the DoTask2 variable as shown in the following image.
Use the and icons to save and activate the rule. Also remember to use the icon to regenerate
the rules.
5.9.2 Create the DoTask6 and DoTask7 Rules

Next, we will create the DoTask6 and DoTask7 rules, which are set to be triggered when Task4 (business
rule task) and Task5 (service task) are executed. In this case, we are returning a true value that is consumed
by the DoTask6 and DoTask7 variables that are set as the result variables in the process as shown in the
following image.
MOODY'S ANALYTICS
So, all we need these rules to do is return the value true. If we want Task8 to execute instead, then we
would change both these rules to return false instead.
MOODY'S ANALYTICS
Again, use the and icons to save and activate the rule. Also remember to use the icon to
regenerate the rules.
The following table provides guidance around what parameter to use in the expression and under what
circumstances.
Expression Scenario Rule

parameter domain
model
execution Always pass "execution" as the parameter to invoke the executeRule or Proposal
executeRuleMap method in the modeler when the rule is not being invoked in a task or Multi
listener. Model
task The only scenario in which "task" is the parameter to invoke the executeRule or Task
executeRuleMap method in the modeler is when it is being invoked from a task listener.
If the last parameter of the Expression in the modeler, when invoking a rule, is 'execution', the
corresponding model on which you are defining the rule should be Proposal. If the last parameter of the
Expression in the modeler when invoking a rule is 'task', the corresponding model on which you are
defining the rule should be Proposal. In almost all cases, the parameter will be 'execution' except in the case
where you are invoking a rule from a user task listener as shown in the following image.
Task1 is a user task, and it has both an Execution Listener and a Task Listener. When you add a task
listener and try to trigger a rule on a task event, it is necessary to pass a task as the parameter to the rule
expression.
5.9.3 Create the Task9 Rule for Candidate Groups

For Task9, we will create a business rule that uses the Proposal Type and the Task ID to determine the
appropriate candidate group to which the task is assigned. Rather than writing this rule using C#, we will
use the decision table rule to create an assignment matrix.
MOODY'S ANALYTICS
We create a Decision Table rule based on the Proposal model.
We create an input based on the Proposal Type attribute in the Proposal model.
We then use the Process object from the rule context and access its ActivityId property. This value will be
the same as the current task from which our rule will be triggered. In the sample BPMN process that we
are creating, we have not mapped our tasks to Task types by creating a business process task and creating
an entry in the TaskTypeMapping artifact. You can reference the Workflow Configuration Artifacts
section to get a better understanding of business process tasks and the TaskTypeMapping reference data.
They can be used to associate your task with a custom menu within CreditLens as well as register your task
with the reference data, so it can be selected from a drop-down list. With this additional configuration, you
can then set the Data Type field shown in the image above for your ActivityId expression to be
TaskTypeMapping, which would allow a predefined task type to be selected.
MOODY'S ANALYTICS
We next set up the output for this rule. We will be returning the role to assign the task to as the output of
the rule. In our case, given that the user roles are configured as a Reference Data in the system, we can
make the UserRole reference data as the Data Type of the return value. In addition, we have to specify the
key for the return value. In our case, we can specify "Role" as the key. We will use the key in the modeler
to retrieve the result of the rule and as the value for the Candidate Groups field.
In the workflow, we extract this key from the rule result, and use it as the Candidate Groups value.
Leave the default value of Single Hit for the decision table. This means that the decision table will stop as
soon as it finds the first condition that evaluates to true and not look for additional conditions that evaluate
to true.
The last step is to add rows to the decision table. The objective with this rule is that given a particular
Proposal Type and Task Id, we want to return a particular role to assign for that task. In our case, the entry
in the decision table focuses on the Task9 task in the SampleBpmn proposal type. We have set up this task
to be assigned to Role1.
Finally, we can go back into the modeler and retrieve the value from the rule using the following
expression.
Note that the expression is set in the Candidate Groups field.
5.9.4 Create Alert Rule on Task10

The last business rule we need to create is the one that sends an alert. Creating an alert is a two-step
process.
Define the Message Template

A message template captures the message that you want to send as part of the alert. Use Configuration >
User Interface > Message Templates to create a new message template.
Message templates are stored and managed separately from the locations where alerts are triggered for the
following reasons:
Messages can be defined in rich text format
Messages can be translated to multiple locales
Messages can format in model-specific attributes

Message templates can be reused across multiple alerts
As shown previously, we create a message template based on the Proposal model. We can use the Insert
Attribute widget to insert the Proposal name into the message. Save the message template, and we can
return to the Business Rules section to define our alert business rule.
Create Alert Business Rule

The alert business rule will use the SendAlert API to send the alert. The SendAlert API has the following
method signature.
Context.Collaboration.SendAlert(<Message Template Name>, <Alert Category>, <List of users>, item);
MOODY'S ANALYTICS
To determine the alert category, we can use the reference data named AlertCategory. The Business Process
category with a CategoryId of 1 is what we want to use in our case because this alert is being fired in the
context of a business process. We know the template name we have created is 'AlertTask10'. Lastly, we
need to pick one or more users that we want to send the alert to. With this information, we are ready to
create our business rule to send the alert as shown in the following image.
In this case, we are hardcoding the recipient of the alert, but in a real-world scenario, you might want to
maintain a reference data of user IDs that should be targeted for different purposes, and use the reference
data to retrieve the appropriate list of users for the the alert in question.
5.10 Create the Roles

In the workflow, we have introduced two roles - Role1 and Role2. We need to create these two roles in
CreditLens. We can do this through Configuration > Reference Data and modifying the UserRole
reference data.
Add Role1 and Role2, and save this reference data.
Also use the Administration > Users menu to add your user to Role1 and Role2 as shown in the preceding
image.
MOODY'S ANALYTICS
5.11 Deploying the Workflow

At this point, we have the BPMN model created and the business rules associated with the workflow
defined as well. It is time to upload our workflow into CreditLens for testing purposes.
The first step is to save the BPMN model as an XML file if you have not already done so and the diagram
as an SVG file.
You can save the SVG file from the Camunda modeler toolbar. At this point, you should have two files in
your file system as shown in the following image.
From the Configuration > Business Process > Processes screen, use the Choose Files button to upload the
two files.
The SampleBpmn process should now show in the list of deployed processes. Click the button to
preview the diagram was uploaded correctly.
MOODY'S ANALYTICS
We can now create an entry in the ProposalTypeMapping reference data to ensure the process we uploaded
is mapped to a Proposal and is available for initiation within CreditLens.
Select the SampleBpmn process, and provide a display name for it.
5.12 Run the Process

We can now use CreditLens to run our business process and walk through the tasks to validate that it is
behaving as expected.
Initiate a new Sample Bpmn proposal from the Proposal > Initiate Proposal menu as shown in the
preceding image.
From the Proposal Center, select the Progress tab, and select and complete Task1. When you return back
to the Progress tab in the Proposal Center, Task2 should be open.
This validates that our XorCheck business rule ran correctly because it set the DoTask2 variable to true,
and the workflow forked to the Task2 pathway instead of the Task3 pathway.
MOODY'S ANALYTICS
This is further validated by switching to the Process tab. Here we can see a graphic view of our process,
which is highlighted to show the path the current instance of our process is taking. Here, we can see that
Task1 is highlighted in green to indicate that it has been completed. While Task2 is highlighted in blue to
indicate that it is open. Notice that Task3 stays black as that is not the path that was chosen by the
workflow, as it exited the XOR gateway. Mark Task2 complete.
When Task2 is completed, the Task4 business rule task and the Task5 service task are triggered
automatically in tandem. These tasks are set up to call business rules that enable Task6 and Task7. Thus,
we see Task6 and Task7 are now open in the Proposal Center. Mark both tasks complete.
This moves the workflow to Task9. If you recall, the following Decision Table rule determines the
assignment for Task9 to Role1.
If we switch to the My Work Items > My Tasks screen, we can see that Task9 appears in the queue of the
current user.
This is true because we earlier ensured that Role1 and Role2 were assigned to the user through the
Administration > Users screen.
MOODY'S ANALYTICS
If we wait for one minute without completing Task9, we should see the Alerts count updated on the
navigation menu.
This happens because after one minute, the Task10 business rule task is executed and triggers a business
rule that fires the alert.
We can open the Alerts screen to verify that the alert from our proposal was fired.
5.13 Summary
In this lab, we built a sample BPMN proposal that showcases the key elements of the BPMN standard that
might be used in a real-world scenario. The objective was to learn how these elements are modeled and
behave as well as how the workflow is integrated with the business rules engine to drive decision flow.
MOODY'S ANALYTICS
6 Lab: Creating a Nested Business
Process
Nested business processes are processes where you combine the following scenarios:
A BPMN process calls another BPMN process
A BPMN process calls another CMMN case

A CMMN case calls another CMMN case
A CMMN case calls another BPMN process
If the business process you are modeling is large, and there are multiple subworkflows involved within the
larger workflow, then nested processes can be used to model such relationships. If there is a need to reuse
the subworkflows themselves directly as proposals, that might also qualify as a reason to break up the
overall workflow into multiple workflows, and use them independently as well as part of a larger workflow.
Nested processes are also a way to combine both the BPMN and CMMN standards to model processes by
taking advantage of the strengths of each standard to achieve a target solution. In this lab, we will build an
example to explore the benefits of combining the two standards.
6.1 BPMN and CMMN Strengths and Weaknesses

Having explored the two standards, we know that the strengths of BPMN lie in its ability to predefine a
structured workflow. The BPMN workflow is a flowchart, which can contain forks, joins, and loopbacks.
It can contain parallel, sequential, and conditional tasks, but all tasks defined in a BPMN workflow must
be completed unless gateways are used to bypass certain tasks. There is no built-in capability to opt out of
finishing certain tasks. On the other hand, CMMN focuses on the ad-hoc workflows that allow tasks to be
marked as optional and be dismissed if they are not needed for a particular instance of a workflow.
Additionally, it also allows for tasks to be grouped in stages and allows for the creation of milestones.
CMMN lacks the ability to loop back and repeat stages easily. By combining the strengths of BPMN to
make control flow decisions and loopbacks with the stage and the ad-hoc nature of CMMN tasks, you can
create workflows that provide an overall structure to a business process but provide more freedom on which
tasks are completed or opted out of in specific stages within the workflow. Let us create a nested business
process sample to demonstrate these strengths. If you have not done so already, first complete the Creating
a BPMN Process and Creating a CMMN Case labs before proceeding further.
MOODY'S ANALYTICS
6.2 Outer BPMN Process

We will begin by defining a BPMN process that will represent the outer overall process. The purpose of
this process will be to define the stages in our workflow and the conditional logic that determines the stage
transition logic including the logic that determines whether stages are repeated or which stage to move to
next. In our workflow, we will have three stages.
Create a BPMN diagram that looks like the preceding image. The bolded tasks are not regular tasks;
instead, they are call activity tasks.
You can use the context-sensitive menu to select Call Activity as the type of task. The Call Activity element
acts as a placeholder for the point in the process where a subworkflow will be triggered. That subworkflow
can either be a BPMN process or a CMMN case.
MOODY'S ANALYTICS
With the Call Activity selected, we can use the properties section to set the CallActivity Type to CMMN.
This is because we intend to call a CMMN case as the subworkflow associated with this Call Activity. For
the Case Ref field, we provide the value StageOne. This will be the ID of the CMMN case we trigger.
Select the loopback sequence flow, and set the Condition Type field to Expression, and set the Expression
field to ${RepeatStage1 == true} as shown in the preceding image. We are modeling that if a variable
named RepeatStage1 is true after Stage1 is processed, we will be looped back to repeat Stage 1.
Set the opposite condition for the sequence flow going from the gateway to Stage2 - ${RepeatStage1 ==
false}. This will allow the process to proceed to Stage 2 if the variable is set to false.
We are using a variable named RepeatStage1 to make decisions in the outer process. However, this variable
is going to be altered by the StageOne CMMN case. The altered value of this variable needs to be returned
back to the outer process. What this means is there needs to be a way to pass variables back and forth
between the parent and child workflow. In order to enable this, we need to configure the outer process
accordingly.
Add an entry for both the Stage1 and Stage2 call activity to the Variables > In Mapping and Out Mapping
. Set the Type field to All. This ensures that variable exchange for both the call activity elements goes both
ways from parent process to child and back.
That is all for the outer process. The outer process consists of two call activity elements that represent the
stages of the parent process, with a gateway being used to conditionally transition from one stage to
another. There can be any number of call activity elements representing additional stages with gateway
elements being used to conditionally transition.
6.3 StageOne CMMN Case

Next, we will implement a CMMN case that will be triggered when the Stage1 call activity is executed by
the outer process.
MOODY'S ANALYTICS
Design a CMMN case that looks like the preceding image. The case has only one stage that represents the
stage that will be visualized in the Proposal Center.
We add a task listener to Task1 on the complete Event Type, and set the Expression to ${task.setVariable
("RepeatStage1", false)}. This expression initializes the RepeatStage1 variable to the value false as soon as
Task1 is marked complete.
MOODY'S ANALYTICS
We also add a task listener to Task2 on the complete Event Type, and set the Expression to the opposite
value - ${task.setVariable("RepeatStage1", true)}. This expression initializes the RepeatStage1 variable to
the value true as soon as Task2 is marked complete. Task2 is an optional task, which means that the stage
can be completed without completing Task2. This means that Stage1 will only be repeated when Task2 is
completed.
6.4 StageTwo CMMN Case

We will keep the second stage pretty simple with a few tasks.
Now we can save and generate an SVG image for all three processes. Then upload the processes into
CreditLens using Configuration > Business Process > Processes.
MOODY'S ANALYTICS
Verify that you can see the Outer and StageOne and StageTwo processes deployed within CreditLens.
Next, we can configure the Outer process as a proposal.
We only configure the Outer process as a Proposal. We do not configure StageOne and StageTwo. This is
because in our example, StageOne and StageTwo are subworkflows that can only be started in the context
of the Outer parent workflow. We do not want CreditLens users to independently start the CMMN cases
as a Proposal. This might or might not be true for the use case you are trying to model. We are now ready
to test the Outer Proposal within CreditLens.
6.5 Testing the Nested Process

Go to the Proposal menu and initiate the Outer proposal.
Navigate to the Proposal Center and the Progress tab. Here you will see that there is already an active Stage
One from the StageOne case, and Task1 and Task2 from that stage are appear. Task1 is Open while Task2
is Enabled. Task2 is Enabled because it was set to manual activation and can be optionally disabled. We
know that if it is disabled, then there will be no repetition of Stage One because the RepeatStage1 variable
will never be set to true.
Complete Task1. Then enable Task2 by using the icon. Complete Task2.
MOODY'S ANALYTICS
You can see that Stage One was repeated. The previously completed instance of Stage One shifts down,
and the latest open instance of Stage One appears at the top of the Proposal Center. Task1 and Task2 are
now in Open and Enabled status again. Complete Task1 first. Then disable Task2.
The act of disabling Task2 will automatically complete Stage One, and Stage Two is now shown as the
active Stage with Task4 and Task5 open. When Task2 was disabled, the RepeatStage1 variable was never
set to true; therefore, Stage One was no longer repeated. Complete Task3 and Task4.
This should result in the Outer proposal being completed. We can return to the My Work Items > My
Proposals and filter by completed proposals. You can open and verify that the Outer proposal that was
started now has a State of Completed.
6.6 Summary
The objective of this lab was to demonstrate that the BPMN and CMMN standards can be combined to
model scenarios that require the flexibility of CMMN combined with the flow control structure that
BPMN offers. In this case, we demonstrated how the looping back portion of the process, based on
conditional logic, can be modeled in BPMN while preserving the concepts of stages and flexible tasks at the
stage level using a CMMN case. The use of variables and passing variables between the parent and child
workflow allows data to be passed between the parent and child workflow and used on both sides to drive
decisions. While this example directly modified a variable value in the child process rather than using
business rules, it is possible to use business rules to drive decision making in both the parent and child
workflow by setting variables within business rules.
7 Lab: Workflow Screens
Walkthrough
In this lab, we will walk through all the screens associated with the workflow or business process
functionality in CreditLens. There are essentially two facets to the workflow functionality in CreditLens
Design-time - This is the facet of workflow where the user models a workflow and configures the
artifacts related to the workflow using the Configuration tools available in CreditLens.
Run-time - This is the facet of workflow where the user initiates a proposal and uses the screens within
the CreditLens product, like the Proposal Center and the My Tasks views, to complete his/her work.
We will now walk through the screens associated with the design-time and run-time facets.
7.1 Design-time Workflow Screens

This section describes the screens associated with the design-time facet.
7.1.1 Business Process > Tasks
MOODY'S ANALYTICS
This screen is accessible by selecting the Business Process menu and the Tasks tab. Business Process Tasks
allow the user to configure a task artifact in CreditLens that shares the same identifier as a task in a BPMN
or CMMN model, thus linking the task in the model to a CreditLens task by convention. The Business
Process Task can be associated with menu items that allow the user to navigate to functional modules in
CreditLens and to provide localized display names for the tasks. In addition, they can also be used to tie the
task to an extension task model that contains custom attributes associated with the task.
7.1.2 Business Process > Processes
This screen is accessible by selecting the Business Process menu and the Processes tab. This is where the
user can upload a BPMN or CMMN model that he/she has created outside of CreditLens using the
Camunda Modeler. The user can optionally select an .SVG file that is an image of the process. The .SVG
file can be generated using the Camunda modeler. We recommend that the user do this, as this allows the
status of a process instance to be tracked visually in the Process tab of the Proposal Center.
7.2 Run-time Workflow Screens

This section describes the screens associated with the run-time facet.
7.2.1 Proposal > Initiate Proposal
Selecting the Initiate Proposal menu item from the Proposal menu, allows the user to initiate a new
Proposal by entering the proposal's attributes.
7.2.2 Proposal Center > Details
Once a proposal is initiated, the Proposal Center screen can be used to work on the proposal. The proposal
attributes can be edited from the Details tab in the Proposal Center. Additionally, proposal-specific
checklist items can be added.
MOODY'S ANALYTICS
7.2.3 Proposal Center > Documents
The Documents tab in the Proposal Center can be used to upload and attach documents to the proposal.
7.2.4 Proposal Center > Commentary
The Commentary tab in the Proposal Center can be used to add rich text comments associated with the
proposal.
7.2.5 Proposal Center > Progress
The Progress tab in the Proposal Center allows users to work to manage and work on tasks associated with
the proposal.
7.2.6 Proposal Center > Process
The Process tab in the Proposal Center allows users to view the progress of the proposal in a visual manner.
7.2.7 Proposal Center > Task
The Task tab of the Proposal Center is visible when you navigate into a specific task. From here you can
mark a task complete. Additionally, you can also enter the attributes of a task and enter checklist items for
the task. Just like the proposal, the task also has tabs for attaching documents and providing commentary.
See the Configuring a Task section to learn how CreditLens-specific menus can be added to a task.
MOODY'S ANALYTICS
8 Lab: Workflow Configuration
Artifacts
In this lab, we will cover the list of configuration artifacts that support extending and customizing the
workflow framework within CreditLens. The following artifacts are used extensively in the configuration of
the workflow framework.
Domain Models
Reference Data
View Models
It is important to have a good understanding of all these concepts from previous sections in the CreditLens
Business Process and Collaboration Tool Configuration Guide before proceeding further with this lab.
8.1 Key Configuration Artifacts

Artifact Type Description
Proposal Domain The Proposal model represents the base model that contains the common
Model attributes for all proposals in CreditLens. The attributes in the Proposal model
appear when a new proposal is initiated as well as when an existing proposal
is opened in the Proposal Center. The Proposal model should be extended to
add any attributes specific to a custom proposal.
ProposalTypeMapping Reference The ProposalTypeMapping reference data is used to register a workflow

Data modeled in BPMN or CMMN with CreditLens by linking the ID of the process
that was uploaded in to CreditLens with the proposal name and optionally
base that Proposal on an extension model.
ProposalInit and View The ProposalInit view model is shown when a new proposal is initiated. The
ProposalInfo Model ProposalInfo view model is shown when an existing proposal is opened in the
Proposal Center.
MOODY'S ANALYTICS
Task Domain The Task model represents the base model that contains the common
Model attributes for all tasks in CreditLens. The attributes in the Task model appear
when a user navigates into a task in the Task tab. The Task model should be
extended to add any attributes specific to a custom task.
ProposalTaskInfo View The ProposalTaskInfo view model is shown when a user navigates in to a
Model task. This view model shows all the standard task attributes and associated
models including the CheckList, Documents, and Commentary sections of the
standard Task screen.
Task Business The Business Process task is used to establish a task item that can be
Process associated with one or more menus. These are the menus that are visible
when a user navigates in to a task to work on the task. It is also used to
establish a link with the Task ID defined in the BPMN or CMMN model both of
which must match. Defining this artifact is optional, and without a Business
Process Task entry, CreditLens will show the default screen when a user
navigates into a task, which is the ProposalTaskInfo. This artifact is required if
a custom extension Task model is defined.
TaskTypeMapping Reference The TaskTypeMapping reference data is used to register a task with
Data CreditLens, provided it also has a Business Process Task artifact defined. An
entry here is also necessary if a custom extension task model has been
created and has to be registered along with its Business Process task. If
neither is true, an entry in this reference data is not necessary. CreditLens will
automatically display the standard task screen for any tasks that do not have
an entry in this reference data.
Stage Domain The Stage model represents a stage in a CMMN workflow. Currently, it cannot
Model be extended further. It contains the standard attributes associated with a
stage.
StageTypeMapping Reference The StageTypeMapping reference data is used to register a stage and its
Data corresponding localized Display Name. The primary reason to create an entry
in this reference data is to support localization of the Stage name. If no entry is
made here, CreditLens will use the stage name entered in the CMMN model
When building a custom proposal/workflow or extending a standard proposal that ships with CreditLens,
the extent of configuration changes needed is dictated by the answer to a few questions. Let us review these
questions.
8.2 Does Your Proposal Have Custom Attributes?

This section describes using custom attributes in your proposal.
8.2.1 Create the Extension Model From Proposal
The first question to be answered is whether the custom proposal that you are building contains custom
attributes that you want to capture above and beyond what is available in the standard Proposal model.
The attributes associated with every proposal in CreditLens are stored in the Proposal model. You can
navigate to the Domain > Models section and search for the Proposal model.
The standard Proposal model can be extended by adding a new model that extends the Proposal model.
MOODY'S ANALYTICS
This can be done by using the Extends field in the Model to indicate that the Proposal model is being
extended. It is good to add the word Proposal as a suffix to your model to indicate that it is extending the
Proposal model. All the other fields can be left at the default values. Your custom attributes can be added to
this model.
8.2.2 Add Associations with the Reference Model
In certain scenarios, the extension Proposal model might require you to establish associations between that
model and other models in the CreditLens environment. This will depend on if the extension model is
being created to capture a reference to an associated object on which the proposal is being based. In our
example, we are creating an EntityProposal extension model, which is used to start proposal on an Entity.
Therefore, we need to capture the ID of the Entity on which the proposal is being initiated.
In this case, a single entity can have multiple proposals, which is a one-to-many association from the Entity
model's perspective. But the association is created from the perspective of the EntityProposal model, so we
define a many-to-one association between EntityProposal and Entity. The association is based on the
EntityId attribute, which is used to establish the link between the proposal and the entity.
8.2.3 Add the Attributes from the Extension Model to Proposal View
Models
The next step is to ensure that your custom Proposal attributes are showing on the Proposal screen. There
are two View Models that show Proposal-related attribute information
ProposalInit - This view model is shown when a new proposal is being initiated.
ProposalInfo - This view model is shown when an existing proposal is viewed in the Proposal Center.
These view models can be accessed by navigating to User Interface > View Models.
MOODY'S ANALYTICS
The attributes from the extension Proposal model can be added to the ProposalInit and ProposalInfo view
models by selecting the model from the list of models. This will show the list of added attributes in the
extension model, which can then be added to the view model.
8.2.4 Add the Extension Model to the ProposalTypeMapping

Reference Data
Now that you have configured the extension model and the related view models, the last step in setting up
your custom Proposal is to let CreditLens know that your Proposal is based on a custom Proposal model.
This is done by configuring the ProposalTypeMapping reference data.
The name of your extension model is specified in the ChildModelId column. The Display Name is a
localized value that can be specified for multiple locales.
At this point, the extension Proposal model has been set up to be used in place of the standard Proposal
model.
8.3 Do You Have Tasks in Your Proposal that Have
Custom Attributes?
You might want to capture custom attributes entered by the user in your tasks that help route the
workflow. In that case, the standard attributes that come with the base Task model are not sufficient, and
you might need to create an extension Task model that captures the additional attributes. The alternative is
that instead of introducing the attributes in the Task model, you can introduce them in the domain model
of the business module that contains the functionality associated with the task. This might be more
relevant if the data being captured is related to the business function, and it makes more sense to store the
data in a domain model associated with that business module. Assuming that this is not the case, and you
want to extend the Task model, then you would go to the Domain > Models section. Here you can search
for the Task model, which is the base for all Task extensions.
MOODY'S ANALYTICS
8.3.1 Create the Extension Task Model
You can create an extension Task model based off the Task model.
The extension model extends the Task model, but you can leave all the other fields set to their default
values.
Tip It is a good practice to suffix your Model Id with the keyword Task to indicate that it is
extending the Task model. This allows all Task-based models to be located quickly through
search later.
Custom attributes can be added to the extension model in addition to the attributes that are automatically
inherited from the base Task model.
MOODY'S ANALYTICS
8.3.2 Add the Attributes from the Extension Task Model to

ProposalTaskInfo View Model
The next step is to ensure that the custom attributes we have added to our extension Task model are added
to the Task Information screen that appears when a user navigates in to the task. This is represented by the
ProposalTaskInfo view model. You can navigate to User Interface > View Models to search for this view
model.
Here the custom attribute in your custom extension of the Task model can be selected by selecting your
model from the list of models and dragging the attribute into the view model. This ensures that your
custom attribute is now visible to the user on the Task information screen. If you want this attribute to be
required in order for the Task to be completed, then you need to make sure that the Required Validator is
turned on in the Validations section for this attribute in the view model.
Without turning on the Required Validator, it will be possible for users to complete your custom task
without entering a value for your custom attribute, and this might prevent the workflow from using the
attribute value to route the workflow appropriately.
8.3.3 Add a Business Process Task to Represent Custom Task
A Business Process Task is a special Task artifact in the CreditLens configuration framework.
It can be accessed from the Business Process menu and the Tasks tab under this menu. There is a twofold
purpose for the Business Process Task artifact:
It establishes a link between a task and task ID defined in the BPMN or CMMN model and the
CreditLens representation of that task. The ID of the Task in the BPMN or CMMN model must be a
case-sensitive match with the ID of the Business Process Task artifact created in this section.
It allows one or more CreditLens menus to be associated with the task artifact. This allows users
navigating in to a task to be able to do the actual work associated with the task by navigating to the
functional module screens within CreditLens.
There are three circumstances under which a Business Process Task is required:
If you want the display name of the task to be localized
If you want to associate one or more CreditLens-specific menus with the task
If you have created an extension Task model and want to associate that extension task model with a task
you have defined in the BPMN or CMMN model
If none of the preceding are true, you can bypass defining a Business Process Task, as CreditLens
automatically renders the standard Task screen for your task without having to do any further
configuration.
In our scenario, since we have created a custom extension Task model, we need to create a corresponding
Business Process Task for each task in the BPMN or CMMN model that we want to base on our custom
extension Task model instead of the base Task model. In addition, at this point, we can also associate the
custom task artifacts with any CreditLens menus that are appropriate for that task.
MOODY'S ANALYTICS
Tip It is always a good idea to add the Proposal Center as one of the menu items so that participants
of the Proposal with access rights to the Proposal Center can quickly navigate to the Proposal
Center from the task.
8.3.4 Add the Extension Model and Business Process Task to the
TaskTypeMapping Reference Data
Now that we have created our Task extension model and view model as well as the Business Process Task
to go with it, it is time to register both these artifacts with CreditLens so that the framework knows to use
these artifacts when the user navigates to work on the tasks in question. This is done by registering these
artifacts with the TaskTypeMapping reference data, which can be accessed by navigating to Domain >
Reference Data.
We need to add an entry in this Reference data for each Business Process Task that we created that we want
to show our custom extension Task model. The Artifact column is selectable from the list of Business
Process Tasks that have been defined. The Display Name can be a localized value. The ChildModelId
column should be set to the Model ID of the custom extension Task model that we created earlier.
Note Even if we did not have a custom extension Task model, we would still need an entry in the
TaskTypeMapping reference data to register the Business Process Task if we created it either for
the purpose of creating a localized Display Name or for the purpose of showing a list of
CreditLens-related menus.
At this point, when a user navigates into these custom tasks, the appropriate menus would show on the left
navigation pane. Additionally, the custom attributes you added to the ProposalTaskInfo view model would
be picked up and shown on the Task Information screen.
8.4 Your Custom Attribute is Reference Data-Based and

You Want to Filter the Values by Task or Proposal
You might have a scenario where the custom attribute that you want to add to the Proposal or Task
extension model is a Reference Data data type. However, the list of values that are shown for the attribute
are to be filtered based on the task that you are in. This might be the case if you want to use a single
custom field to allow the user to provide additional information, but you want to regulate the value that
the user can select depending on the particular task that he/she is in. In this case, you can apply a filter
attribute on your reference data derived from the Proposal or TaskTypeMapping reference data. Let us
look at an example.
MOODY'S ANALYTICS
8.4.1 The Data Type for the Custom Attribute Has to be a Reference
Data Type
We have added a BusinessStatus attribute in our custom extension Task that is based on a Reference Data
of the same name.
8.4.2 Add the Reference Data Type That is the Filter for our Reference
Data Type
This reference data contains all the values we want to show for the BusinessStatus attribute; however, it also
contains a TaskType column.
8.4.3 The Filtering Reference Data Type Must Indicate Its Filter
Attribute
The TaskType column is based on the TaskTypeMapping Reference data and is used as a filter. The Filter,
Filter Id, Is Parameter, and Is Multi-select fields have been set for this attribute. The filter setting indicates
that the TaskType attribute in the BusinessStatus reference data is being used as a filter. It is using the
TaskType Filter Id from the TaskTypeMapping reference data.
MOODY'S ANALYTICS
Looking at the TaskTypeMapping reference data's Attributes tab, we can see that the Artifact attribute,
which shows the list of Business Process Task artifacts, has the Filter Id column also set to TaskType. This
allows other reference data to use this column as a filter for their own purposes, and that is what the
BusinessStatus reference data is doing.
When the TaskType column value is selected, it shows the values from the Artifact column in the
TaskTypeMapping reference data to filter by. The Is Multi-select setting allows one or more values to be
selected to filter by. In this case, the idea is that we want to limit the particular BusinessStatus value to only
the selected tasks and not show it for other tasks.
8.4.4 The View Model Must Contain an Attribute of the Filter

Reference Data Type
There is one last configuration change needed to complete the ability to filter, and that is in the
ProposalTaskInfo view model.
The BusinessStatus attribute that we added to this view model needs to know that it is also dependent on
another attribute in the same view model, which is the TaskType attribute.
TaskType is an attribute that is a part of the base Task model and therefore an attribute that shows in all
Task screens. Given that we want to filter the data in the BusinessStatus attribute by this attribute, not only
do we need to apply the filtering on the Reference data, but we also need to indicate the attribute in the
View Model on which the BusinessStatus attribute is dependent. In this case, it is the TaskType attribute.
MOODY'S ANALYTICS
At this point, the configuration steps are complete. When the user navigates to different task types that are
based on the custom BusinessStatusTask extension and attempt to view the values for the BusinessStatus
attribute, the values for the attribute will be filtered based on the TaskType. The TaskType itself will be a
case-sensitive match of the ID of the Task in question as entered in the BPMN or CMMN model.
8.5 Registering Artifacts with Reference Data

There are three primary reference data that are used to register artifacts with the CreditLens framework.
ProposalTypeMapping
TaskTypeMapping
StageTypeMapping
The ProposalTypeMapping reference data is used to register new proposal types with the system. After a
BPMN or CMMN process has been uploaded, a proposal entry needs to be added to this reference data
before it becomes available for initiation within CreditLens. While adding an entry here, a localized
Display Name for the proposal can also be specified. In addition, an extension model specific to the new
proposal entry can also be specified.
The TaskTypeMapping reference data is used to register new task types with the system. An entry in this
reference data is required if the display name of the task needs to be localized if there are custom menus
associated with the task or if the task is based on an extension task model. An entry is not needed if these
reasons are not valid for the task being introduced.
The StageTypeMapping reference data is used to register stages for which a localized display name is
needed.
9 Lab: The Workflow Module
In this lab, we will cover the Workflow module that ships out-of-the-box with CreditLens. We will
understand the differences between the workflow or business process framework within CreditLens versus
what is included as part of the Workflow module. Up to this point, most of what you have learned is about
the framework available for integrating workflows or business processes into CreditLens. As covered in
other labs, the three key components of the framework are:
Workflow Engine
Configuration system (Domain Models, Reference Data, View Models)
Business Rules Engine
9.1 Workflow Module

In this section, we will focus on the fourth component which is the Workflow module. The workflow
module is a separate module that houses the following artifacts:
Standard Credit BPMN The Workflow module contains the BPMN/CMMN model that contains the
Proposal and standard Credit Proposal that will ship with CreditLens.
CMMN
Standard Business Business The Workflow module contains all the standard Business Process tasks
Process Tasks Process associated with navigating to business functional modules. The relevant
menus are attached to these tasks.
BusinessTask Domain The Workflow module contains the extension task model called
Model BusinessTask. This model contains the Business Status attribute that can be
used to route the workflow appropriately.
BusinessProposal Domain The Workflow module contains the extension proposal model called
Model BusinessProposal. This model contains the EntityId as an attribute and
allows a Proposal to contain Entity as the reference model. In addition, it
also contains the Business Status attribute for the Proposal.
Business Rules Business The Workflow module contains business rules that are used as part of the
Rules standard out-of-the-box Credit Proposal.
MOODY'S ANALYTICS
ProposalBusinessStatus Reference The Workflow module contains this reference data that stores the list of
Data values for the Business Status attribute at the proposal level. The values in
this reference data can be filtered by the entries in the
ProposalTypeMapping reference data.
TaskBusinessStatus Reference The Workflow module contains this reference data that stores the list of
Data values for the Business Status attribute at the task level. The values in this
reference data can be filtered by the entries in the TaskTypeMapping
reference data.
The Workflow module has a separate license and is not part of the core framework of CreditLens. All the
artifacts in the Workflow module are there for a twofold purpose:
They are used in the standard out-of-the-box Credit Proposal.
They can also be used by custom proposals that are created that are either extensions of the standard
Credit Proposal or completely customized.
9.2 Leveraging Artifacts That Are Part of the Workflow

Module in Custom Proposals
In this section, we will discuss leveraging artifacts that are part of the Workflow Module in custom
proposals.
9.2.1 Using the Standard Credit Proposals as a Starting Point

The standard Credit Proposals (both the CMMN and BPMN variation) can be used as the starting point
for a custom proposal being designed for a client rather than starting a new proposal from scratch.
When doing this, the proposals can be downloaded, both the filename and ID of the process can be
renamed, and it can be used as the starting point for the custom proposal.
OOB Credit Proposal (BPMN)
Tasks
Manage Entities
Spread Financials
Risk Grade Entities
Deal Structuring
Prepare Credit Memo
Business Approval
Credit Approval
Committee Approval
An XOR Gateway Example
Add a task listener to listen “Task completion” to execute a business rule to pass Business Status for the
gateway. The gateway makes decisions accordingly.
OOB Credit Proposals (CMMN)
Tasks
Manage Entities
Spread Financials
Risk Grade Entities

Deal Structuring
Prepare Credit Memo
Business Approval
Credit Approval
Committee Approval
Prepare Letter of Offer
Client Negotiation
Operational Activities
Condition Precedent Checking
Milestones
Risk Grading Ready
Deal Structuring Ready

Ready for Business Submission
Credit Approved
Credit Declined
Client Accepted
Client Appealed
MOODY'S ANALYTICS
Client Rejected
Stages
Pre-Approval
Client Negotiation
Post-Approval
Stage’s Repetition
Stages can be repeated under condition of the repletion rule via a business rule.
User Roles
9.2.2 Incorporating Standard Tasks into Custom Proposals
The Business Process tasks that ship with the Workflow module can be incorporated into any custom
proposal. These tasks contain the menus for the functional modules that are available in CreditLens and
provide immediate support for being able to navigate to the functional module screens without having to
do any additional configuration. Where possible, these standard tasks should be reused even if the
workflow itself is being custom built.
Tasks of OOB Credit Proposal Defined in Workflow
9.2.3 Using a Preconfigured Business Status Attribute for a Proposal

The BusinessProposal provides a version of the proposal with a preconfigured Business Status attribute.
The custom proposal can be based on BusinessProposal, and if there is a need for setting a business status
in the proposal, the ProposalBusinessStatus reference data can be modified to add/remove values.
The BusinessProposal also comes with a preconfigured association with Entity; therefore, any proposal
based on this model will automatically be initiated with Entity as the reference model. This avoids
additional configuration steps that are needed if you base a custom proposal directly on the proposal
model.
MOODY'S ANALYTICS
9.2.4 Using a Preconfigured Business Status Attribute for a Task
The BusinessTask provides a version of the task with a preconfigured Business Status attribute. Any custom
tasks that need a Business Status attribute can be based on this task type, and the TaskBusinessStatus
reference data can be modified to add/remove values.
MOODY'S ANALYTICS
Now, the business status of task can be filtered by Task Type and Proposal Type to support different
proposals that have the same task definitions.
Configuration in ProposalTaskInfo View Model
9.2.5 Reusing Business Rules

The Business Rules that are used to push the business status attribute value into a workflow variable, which
in turn can then be used to route the workflow appropriately, can also be reused by configuring these rules
to be run at the relevant points in the custom workflow.
SetBusinessStatus
To spread the business status value from task to gateway to make a decision for the next direction
MOODY'S ANALYTICS
SetProposalBusinessStatus
To update the business status of CreditProposal by using the status of Business Task when it is
CreditApproval or Committee Approval
IsProposalBizStatusReadonly
To control the Business Status field of the proposal is read only under certain conditions
EditableMatrix
Editable Matrix rule by decision table with certain input dimensions to support readonly/editable in each
business module
Note Refer to the Lab: Configuring an Editable Matrix section for more information.
DisplayConcurrentBizProposalsRule
To filter concurrent proposals by the attributes of the Initiate Proposal page
MOODY'S ANALYTICS
ValidateSpreadFinacialsTask
To validate that at least one historical statement must be added before completing the SpreadFincials task
GetTaskAssignee
To support the task assignee can be determined during the proposal/task’s runtime
10 Lab: Configuring a Task
In this lab, we will cover in detail the configuration options are when defining a new Workflow User or
Human task. A User task in BPMN or a Human task in CMMN represents interactive work that needs to
be performed. This work could be performed within CreditLens or outside of CreditLens. Tasks are
defined in the modeler, but they can be associated with a CreditLens Business Process Task artifact and
further configured if the following additional control is desired:
Add CreditLens-specific menus that link to CreditLens module features
Localize the Task name
Extend the Task to add custom attributes
In this lab, we will examine the details around the additional configuration that is done within CreditLens.
10.1 Standard CreditLens Task

When work is performed outside of CreditLens, the standard UI that goes with a task might be sufficient
to capture the work that is being done.
MOODY'S ANALYTICS
The preceding screen shows a Task Center screen. The attributes of a task are shown on the Details tab
along with a Checklist that can be used to capture work that was completed outside CreditLens. The
Documents tab allows documents to be uploaded and attached to this specific task. The Commentary tab
can be used add notes and discussions on the task.
This Task Center screen does not have a CreditLens-feature specific menu. You only have the ability to
mark the task complete or exit the task. This is the generic task provided by CreditLens. A task defined in a
modeler that does not have a corresponding Business Process Task artifact defined automatically becomes a
generic task and gets the preceding capabilities.
10.2 Defining a Business Process Task

When you want to further customize a task beyond what is offered by the Generic Task, you create a
Business Process Task artifact.
Select Business Process > Tasks, and select the SpreadFinancials task. You can see that this artifact is
defined in the Workflow module, which contains the out-of-the-box workflows that are part of CreditLens.
The SpreadFinancials task defines the CreditLens-specific menus for this task including the landing page
for the task, which is the top-level navigation menu that users see when the navigate to this task.
Additionally, there is a Visibility Rule, which allows control over the menu items associated with the task.
It determines which menus are visible and whether the pages under the menu are editable or read-only.
The EditableMatrix rule that is attached to visibility is a decision table determines the visibility or read-
only status of menus items based on the Proposal Type, Task Type, and State of the task. Refer to the
Configuring an Editable Matrix section for more information.
Although both top-level menus and submenu items are available as options for the landing page, only a top-
level menu should be selected for the landing page. Submenu items can also be visualized as tabs; therefore,
they are not candidates for the landing page. The read-only and visibility can be applied to both top-level
menus and submenu items.
MOODY'S ANALYTICS
10.3 Register with the TaskTypeMapping Reference Data
We can use the TaskTypeMapping reference data to register the Business Process Task with CreditLens.
Currently, we can also provide a localized display name for the task. Additionally, the ChildModelId field
can be used to specify if the task is an extension of the standard Task model. In the preceding image, note
that the SpreadFinancials task is not an extension task, but the RiskGradeEntities task is based on an
extension task called BusinessTask.
Use the Models tab to search for the BusinessTask domain model, and open it. You can see on the
Information tab that the BusinessTask model extends the Task model. Now, switch to the Attributes tab.
You can see that the BusinessTask automatically inherits all the attributes of the Task model, and they are
all locked from further editing. But the BusinessTask model adds one additional attribute called
BusinessStatus. This is a custom field specific only to tasks that are of the BusinessTask type. The
RiskGradeEntities Business Process task artifact can specify that it is BusinessStatusTask type by using the
ChildModelId field in the TaskTypeMapping reference data to register itself as a task of that type. This
means that when the user navigates to the Task tab in a RiskGradeEntities task, the user will see the
additional BusinessStatus attribute, which would not be seen when you navigate to the SpreadFinancials
tab.
10.4 Summary
In this lab, we examined how workflow tasks can be configured to provide CreditLens-specific menus so
that work within CreditLens can be completed as part of the task. In addition, we also looked at how
editability of the menus associated with a task can be controlled using a business rule attached to the
Business Process Task artifact. We also looked at how a default landing page in CreditLens can be
configured for a task. We then registered the task artifact that was created with the TaskTypeMapping
reference data, which allowed us to specify a localized display name for the task within CreditLens.
Additionally, it also allowed us to specify if the task in question only contained the standard task attributes
or if it was based on a task extension domain model, which allows additional attributes to be added.
MOODY'S ANALYTICS
11 Lab: Configuring an Editable Matrix
In this lab, you will learn how to configure an editable matrix for the Business Process and Collaboration
Tool workflow feature in the CreditLens™ application.
The editable matrix is a decision table business rule that configures read and write access of task owners and
assignees to task-associated business modules. It ensures that task owners and assignees have the correct
level of module access to complete their tasks and that users have a clearly defined user interface to act on
their deliverables. For example, a spreader assigned to complete a spreading task on ABC Entities might
need to review the credit hierarchy for the borrower before spreading financials for the entity. In this
example, you would enable the spreader with read access to the Entity Management section and write
access to the Financial Analysis module. Since the spreader does not need access to rating information, you
can hide the page from this user.
11.1 Building an Editable Matrix

Complete the following steps to configure the editable matrix to suit your unique business processes.
1. Log in to the CreditLens application.
2. In the navigation menu, select Configuration > Domain > Business Rules. A list of business rules
appears.
3. Click the pencil icon to edit the EditableMatrix business rule.
MOODY'S ANALYTICS
4. Select the version of the business rule you want to be active.
5. Enter the description for the business rule.
6. Select DecisionTable in the Rule Type drop-down list.
7. Select Multiple Models in the Models field for business rules that are triggered from anywhere in the
workflow.
8. You can edit an existing rule by clicking it and editing the existing information, or click Add Rule at the
bottom of the page to add a new rule.
9. In the Inputs section, select the proposal and task type for the editable matrix.
10. In the Return readonly column in the Outputs section, select which menu items (of those that are
visible to the user) are read-only.
11. Click the Save icon.
12. Click the Activate icon to save as a new version.
Note In the preceding image, the settings in the highlighted row give users working on a Spread
Financials task read-only access to the Entity Management menu item.
11.2 Managing Module Visibility for Task Assignees

Complete the following steps to manage which modules appear on a user's interface.
2. In the navigation menu, select Configuration > Business Process > Tasks. A list of tasks appears.
3. Click the task you want to configure (for example, SpreadFinancials).
3.
4. Select the landing page users are directed to when they open a task (for example, FinancialAnalysis).
5. In the Visibility Rule field, select EditableMatrix.
6. Specify the menu items a task assignee has access to by dragging menu items from the Available Menus
column to the Selected Menus column.
7. To hide a menu item from a task assignee, click the red X next to the menu item in the Selected menus
column. Then, click the Hard Delete button when you are asked to confirm if you want to remove the
menu item from the Available Menus column.
8. Select the Multi-select check box next to Available Menus to select multiple menu items to move to the
Selected Menus column at one time.
MOODY'S ANALYTICS
12 Lab: Configuring an Approval
Matrix
In this lab, you will learn how to configure an approval matrix for the Business Process and Collaboration
Tool workflow feature in the CreditLens™ application.
The approval matrix is a decision table business rule that ensures that approval tasks, such as Credit
Approval or Committee Approval, are completed by users who have the appropriate level of approval
authority as determined in your bank policy. It ensures that task owners and assignees can complete a task
but not approve it unless they have the required level of approval authority.
12.1 Building an Approval Matrix

Complete the following steps to configure the approval matrix to suit your unique business processes.
appears.
3. Click the pencil icon next to ApprovalMatrix to edit the business rule.
MOODY'S ANALYTICS
5. Enter the description for the business rule.
6. Select DecisionTable in the Rule Type drop-down list.
7. Select Multiple Models in the Models field for business rules that are triggered from anywhere in the
workflow.
8. You can edit an existing rule by clicking it and editing the existing information, or click Add Rule at the
bottom of the page to add a new rule.
9. In the Inputs section, select the proposal and task type for the approval matrix. You can also use the size
of a deal or a proposal rating as input dimensions in determining approval authority.
Note For CommitteeApproval task type, you cannot select Any Value in the
ProposedEntityRating column. Instead, select Has No Value.
10. In the Outputs section, select which users or candidate roles have approval authority.
For example, for a Credit Approval task, if you set the ProposedEntityAggregatedLimit value to Greater
than $10 million, you might set the ReturnCandidateRoles column to CreditCommittee requiring
committee approval to approve the deal as shown in the preceding image.
13 Lab: Configuring Alerts,
Notifications, and Email Messages
In this lab, you will learn how to configure alerts, notifications, and email messages in the CreditLens™
application.
The CreditLens application offers the following communication tools to improve collaboration and user
efficiency.
Global and entity alerts
Global, entity, and workflow notifications
Internal email messages
You can send the communication to one user or specific users depending on your business needs.
13.1 Alerts and Notifications

The CreditLens™ software generates alerts and notifications to keep users up-to-date on issues regarding
their responsibilities and also warns them of actions they must take. Alerts and notifications are used in all
core modules.
The following table lists the standard out-of-the-box alerts and notifications. You can customize these alerts
and notifications, or create your own alerts and notifications to meet your business needs.
Standard Out-of-the-Box Alerts and Notifications
Feature Alert / Name Condition Message Recipient

Notification Users
Covenants Alert Covenants Publish This workflow was declined. The Multiple
Not Covenant on covenants in this workflow will not be users
Published Completion published. defined in
of Credit a rule
Approval
MOODY'S ANALYTICS

Notification Users
Covenants Alert Covenants Publish This workflow was declined. The Multiple
Not Covenant on covenants in this workflow will not be users
Published Completion published. defined in
of a rule
Committee
Approval
Financial Alert Industry Industry The industry classification of the entity Multiple
Analysis Classification Code [[LongName]] has been changed. Please users
Change Change By make sure that the peer selection is still defined in
Classification valid. a rule
Financial Alert Historical Historical The rating for Entity [[LongName]] was Multiple
Analysis Statement Statement generated using Statement [[statement]]. users
Changed Updated Please note that the statement is now defined in
updated. Please review Rating Scenario a rule
[[Rating Scenarios]].
Financial Alert Contributing Send Alert The contributing statement of entity Multiple
Analysis Statement For [[Contributing Entity Name]] has been users
Change Contributing changed. It will affect the combined defined in
Statement statement [[Combined Statement Date]] - a rule
Change [[Periods]] of entity [[Combined Entity
Name]].
Proposal Notification Proposal Proposal [[Proposal Type]] ([[WorkflowId]]) has Users

Completed Completed been completed for [[Entity Long Name]]. configured
in
Workflow
events
Ref Id
Proposal Notification Proposal Proposal The due date for [[Proposal Type]], Users
Due Date Due Date ([[WorkflowId]]) has changed to [[Due configured
Changed Change Date]]. in
Workflow
events
Ref Id
Proposal Notification Proposal Proposal [[Proposal Type]], ([[WorkflowId]]) is due Users

Near Due – Near Due [[Due Date]] and requires your attention. configured
Action in
Required Workflow
events
Ref Id
Notification Users
Proposal Notification Proposal Proposal [[Proposal Type]], ([[WorkflowId]]) is past Users

Past Due – Past Due due and requires your attention. configured
Action in
Required Workflow
events
Ref Id
Proposal Alert Proposal Proposal Changes in the [[Modules]] module(s) for Multiple
Data Data Entity [[EntityId]] - [[Entity Name]] in the users
Published Published proposal [[Proposal Name]], defined in
([[ProposalId]]) have been published. a rule
This may impact the open proposal
[[Target Proposal Name]], ([[Target
ProposalId]]).
Risk Alert Rating Out of Rating Out of The rating for Entity [[Target Long Multiple
Grading Date Source Date Source Name]] was cascaded from [[Source users
Change Change Long Name]]. However, [[Source Long defined in
Name]] has been removed from the a rule
hierarchy, so the cascade relationship is
no longer valid.
Risk Alert Contributing Change The contributing statement of entity Multiple

Grading Statement Contributing [[Contributing Entity Name]] has been users
Template Statement changed. It will affect the combined defined in
Change Template statement [[Combined Statement Date]] - a rule
[[Periods]] of entity [[Combined Entity
Name]].
Risk Alert Financial Send Alert The Financial Template for Entity Multiple
Grading Template For Financial [[LongName]] was changed. Please users
Changed Template review Rating Scenarios. defined in
Changed a rule
Risk Alert Rating Out of Send Rating The rating for Entity [[Target Long Multiple
Grading Date Out of Date Name]] was cascaded from [[Source users
Alert Long Name]]. However, [[Source Long defined in
Name]] rating has been updated, please a rule
review it.
Risk Alert Historical Send Alert The rating for Entity [[LongName]] was Multiple
Grading Statement For Historical generated using Statement Set. Please users
Added Statement note that a new statement [[statement]] is defined in
Added now available which was not included in a rule
the statement set used to generate the
rating [[Rating Scenarios]].
MOODY'S ANALYTICS

Notification Users
Risk Alert Projection Projection The rating for Entity [[LongName]] was Multiple
Grading Statement Statement generated using Statement [[statement]]. users
Updated Updated Please note that the statement is now defined in
updated. Please review Rating Scenario a rule
[[Rating Scenarios]].
Task Notification Task Task Task [[TaskType]] ([[WorkflowTaskId]]) Users

Assigned - Assigned to for [[Proposal.ProposalType]] configured
Action User ([[WorkflowId]]) has been assigned to in
Required you. Workflow
events
Ref Id
Task Notification Task Task Task [[TaskType]], ([[WorkflowTaskId]]) Users

Completed - Completed for [[Proposal.ProposalType]] configured
Action by User ([[WorkflowId]]) has been completed. in
Required Workflow
events
Ref Id
Task Notification Task Task Task [[TaskType]] ([[WorkflowTaskId]]) Users

Returned - Returned to for [[Proposal.ProposalType]] configured
Action Task Owner ([[WorkflowId]]) has been returned. in
Required Workflow
events
Ref Id
Task Notification Task Task Task [[TaskType]], ([[WorkflowTaskId]]) Users

Pending - Pending for [[Proposal.ProposalType]], configured
Action ([[WorkflowId]]) has been pending in
Required completion for [[Pending Days]] days and Workflow
requires your attention. events
Ref Id
Task Notification Task Past Task Past Task [[TaskType]] ([[WorkflowTaskId]]) Users
Due - Action Due for [[Proposal.ProposalType]] configured
Required ([[WorkflowId]]) is past due and requires in
your attention. Workflow
events
Ref Id
13.1.1 Customizing Alerts and Notifications Using Business Rules
Business rules can be used to trigger alerts and notifications for a model based on a valid condition.
Creating Alerts and Notifications Via an Existing Business Rule

Complete the following steps to configure alerts and notifications using an existing business rule.
1. Log in to the CreditLens™ application.
appears.
3. Filter the business rules in CreditLens by using the Alerts category. You can also search for a specific
rule by clicking the three horizontal lines icon in the Rule Name column and entering the rule name.
4. Click the Edit icon to edit an existing business rule (for example, SendRatingOutOfDateAlert).
6. Enter a description for the business rule.
7. Select a rule type from the drop-down list (for example, CSharp).
8. Select a model from the drop-down list (for example, EntityRating).
9. Select Alert in the Category drop-down list.
10. Update the following parameters to generate an alert or notification.
Message template name

Alert category
Alert or notification classification

User or list of users
Model on which the business rule is executed
Trigger to execute the business rule
MOODY'S ANALYTICS
Creating Alerts and Notifications Via a New Business Rule

Complete the following steps to configure alerts and notifications using a new business rule.
appears.
3. Click the Add icon to create a business rule.
4. Enter a name for the business rule using Pascal case (for example, SendAlertNow).
5. Enter a description for the business rule.
6. Select a rule type from the drop-down list. You can configure the rule using CSharp or Natural
language.
7. Select a model from the drop-down list (for example, EntityRating).
8. Select Alert from the Category drop-down list.
9. Use the following parameters to generate an alert or notification as shown in the following example.
Message template name
Alert category
Alert or notification classification
User or list of users

Model on which the business rule is executed
Trigger to execute the business rule
11. Click the Activate icon.
13.2 Workflow Notifications and Email Messages

A standard feature of the CreditLens™ Business Process and Collaboration Tool is the ability to send
notifications and email messages to proposal participants based on common business scenarios. The
following common proposal scenarios trigger notifications and email messages. These common
notifications are applied to all proposal types and do not require additional configuration.
Proposal initiation
Proposal completion
Proposal cancellation
Assignment of a task
Completion of a task
Return a task
Also, notifications and email messages can be triggered by the following deadline-related scenarios.
When a proposal/task due date has been changed and saved
When the proposal or task is nearing its due date

When a proposal or task is past due
When a task has been pending for a specified number of days
MOODY'S ANALYTICS
The following table provides more information about configuring email notifications.
Scenario Event Configurable To Email Message CC
Proposal Initiated ProposalInitiate Yes Proposal N/A

Owner
Task Completed (owner is TaskCompleted Yes Task N/A

assignee) Assignee
Task Completed (owner is TaskComplete Yes Task Task Owner

different from assignee) Assignee
Task Assigned (owner is TaskAssigned Yes Task N/A

assignee) Assignee
Task Reassigned (owner is TaskAssigned Yes Task Task Owner

different from assignee) Assignee
Task Returned TaskReturned Yes Task N/A or Task Owner if

Assignee different from the Task
Assignee
Proposal Canceled ProposalCancel Yes Proposal Proposal Participants

Owner
Proposal Finalize ProposalFinalize Yes Proposal Proposal Participants

Owner
Proposal’s Due Date Changed DueDateChanged Yes Proposal Proposal Participants if any
for proposal Owner
Task’s Due Date Changed DueDateChanged Yes Task N/A or Task Owner if
for task Assignee different from the Task
Assignee
Proposal is Close to Due Date CloseToDueDate Yes Proposal Proposal Participants if any
for proposal Owner
Task is Close to Due Date CloseToDue for Yes Task Task Owner if different from
task Assignee the Task Assignee
Proposal is Past Due PastDue for Yes Proposal Proposal Participants if any
proposal Owner
Task is Past Due PastDue for task Yes Task Task Owner if different from
Assignee the Task Assignee
Task is Pending Completion TaskPending Yes Task Task Owner if different from
Assignee the Task Assignee
The following are sample email messages that you can send to your proposal participants.
Sample of a Proposal Initiated Email Message
Sample of a Task Assignment Message
MOODY'S ANALYTICS
Sample of a Task Completed Message
Sample of a Past Due Email Message
Administrative users can configure additional email messages and notifications depending on the
requirements of your institution.
13.2.1 Configuring Workflow-Related Alerts, Notifications, and Email

Messages Using WorkflowEvents Reference Data
Complete the following steps to configure alerts, notifications, and email messages using the
WorkflowEvents reference data. This reference data uses predefined events in the system, such as
PropsalInitiate and ProposalCancel to trigger an alert, notification, or email message. These events map to
the Camunda modeler where you can configure who receives an email message based on the event type.
2.
2. In the navigation menu, select Configuration > Domain > Reference Data. A list of reference data
appears.
3. Filter the reference data in CreditLens by typing WorkflowEvents in the Search box.
Tip Recently viewed reference data appear at the top of the page.
4. Click the Data tab.
5. Click the Edit icon next to the EventId to edit whether an alert, notification, and/or email message
should be sent to a user. The following table lists the column descriptions.
Tip Click the column headers to sort the WorkflowEvents data.
Column Description
Edit icon Click the icon to edit a WorkflowEvents reference data item.
Delete icon Click the icon to delete this item from the WorkflowEvents reference data.
Revert icon Click the icon to revert this item from the WorkflowEvents reference data.
EventId Lists predefined events in the system that map to the Camunda modeler ( for example,
TaskComplete).
ProposalType Select the proposal type (for example, Credit Proposal v2).
TaskType Select the task type(s) (for example, Manage Entities).
MessageType Select the message type (for example, Email).
AlertMessageTemplate Select the message template to use when an alert is generated for the event identifier
(for example, ProposalDueDateChanged).
Email Message Select the message template to use when an email message is sent for the event
Template identifier (for example, ProposalDueDateChanged).
EmailTaskRecipient Select which task recipients you want to receive the email messages sent for the event
identifier (for example, TaskOwner).
EmailProposalRecipient Select which proposal recipients you want to receive the email messages sent for the
event identifier (for example, ProposalOwner).
DontSendToSelf Select this check box if you do not want to be copied on email messages sent for the
event identifier.
Active Select this check box if the event is active.
6. Click the Check icon to accept the changes, or click the Cancel icon to cancel the changes to an item.
MOODY'S ANALYTICS
13.2.2 Message Templates

You can configure existing message templates or create new message templates to send to proposal
participants using the CreditLens™ Advanced Designer (CLAD).
Editing an Existing Message Template

2. In the navigation menu, select Configuration > User Interface > Message Templates. A list of message
templates appears.
3. Click the Edit icon. The Message Templates detail information screen appears.
4. Edit the message information you want to update.
Creating a New Message Template

2. In the navigation menu, select Configuration > User Interface > Message Templates. A list of message
templates appears.
3. Click the Add icon. The Message Templates detail information screen appears.
4. Enter the name for your template using Pascal case (for example, TestTemplate).
5. Select a model from the Model drop-down list (for example, Task).
6. Select a language from the Language drop-down list (for example, English 1 en).
7. Enter a subject for your message in the Subject field (for example, Immediate Action Required).
8. Enter the text of your message in the Content field using the rich text editor.

CreditLens Business Process and Collaboration Tool Configuration Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CreditLens Business Process and Collaboration Tool Configuration Guide

Uploaded by

Copyright:

Available Formats

28 JUNE 2019

CreditLens™ Business Process and

Moody's Analytics Support

2 Lab: Understanding BPMN 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Lab: Understanding CMMN 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Lab: Business Rules and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Combining Business Rules and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Where Can a Workflow Call Business Rules? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5 How is a Business Rule Triggered From the Workflow? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Lab: Creating a BPMN Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Create a BPMN diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.3 Create User Tasks and Exclusive OR Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4 Adding a Business Rule to a Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.5 Add an AND/Parallel Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.6 Add Service and Business Rule Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.7 Add an OR/Inclusive Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.8 Add Alternate Execution Paths with Timer Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.9 Configure the Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.10 Create the Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.11 Deploying the Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.12 Run the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 Lab: Creating a Nested Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2 Outer BPMN Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.3 StageOne CMMN Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.4 StageTwo CMMN Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.5 Testing the Nested Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7 Lab: Workflow Screens Walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.2 Run-time Workflow Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8 Lab: Workflow Configuration Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8.2 Does Your Proposal Have Custom Attributes? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.5 Registering Artifacts with Reference Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

9 Lab: The Workflow Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

10 Lab: Configuring a Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

10.2 Defining a Business Process Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

10.3 Register with the TaskTypeMapping Reference Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

10.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

11 Lab: Configuring an Editable Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

11.2 Managing Module Visibility for Task Assignees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

12 Lab: Configuring an Approval Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

13 Lab: Configuring Alerts, Notifications, and Email Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

13.2 Workflow Notifications and Email Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

1.1 BPMN and CMMN Models

Case Management Model and Notation (CMMN 1.1)

Tasks represent units of work within the process.

Tasks represent units of work within the case.

4.1 What are Variables?

4.2 Combining Business Rules and Variables

4.3 Where Can a Workflow Call Business Rules?

4.4 What Type of Business Rules Can be Triggered From a

4.5 How is a Business Rule Triggered From the Workflow?

4.5.1 Service Task, Decision Task, Business Rule Task

4.5.2 Execution Listener

Second Scenario Rule

5.1 Setting Up the Camunda Modeler

Click Create a BPMN Diagram to create an empty BPMN diagram.

5.3 Create User Tasks and Exclusive OR Gateway

5.4 Adding a Business Rule to a Gateway

5.6 Add Service and Business Rule Tasks

5.7 Add an OR/Inclusive Gateway

5.8 Add Alternate Execution Paths with Timer Event

5.9 Configure the Business Rules

5.9.1 Create XorCheck Rule

5.9.2 Create the DoTask6 and DoTask7 Rules