xCP Pattern Library

v3.3

EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748–9103
1–508–435–1000
www.EMC.com
 TABLE OF CONTENTS

1 EXECUTIVE SUMMARY ............................................................................................... 3

2 BASIC CONCEPTS ....................................................................................................... 5
3 INITIATE CASE ........................................................................................................... 11
4 MANAGE ..................................................................................................................... 18
5 REVIEW ...................................................................................................................... 30
6 COMMUNICATE.......................................................................................................... 39
7 CLOSE CASE ............................................................................................................. 50
8 CASE POLICIES ......................................................................................................... 54
9 DATA MODEL ............................................................................................................. 66
10 EXTERNAL INTERFACES ...................................................................................... 74
11 MONITORING .......................................................................................................... 83

xCP Pattern Library 2

 Executive Summary

1 Executive Summary
xCP is a case-based offering built on the Documentum platform. It accelerates solution
development with pre-built, reusable components. These components are configured and
assembled according to defined patterns. The Pattern Library documents these patterns so
that they can be easily used by anyone.
Patterns have been used for object-oriented software design since the 1996 publication of
the seminal book Design Patterns. We expand the notion of patterns to include requirements
definition as well as design.
The xCP Pattern Library is a major contributing factor to the success of an xCP
implementation. In addition to suggesting new ideas for solutions, the Pattern Library
reduces the time and risk of an implementation by providing design alternatives and
documenting best practices.

1.1 Audience
This document is intended for EMC partners and consultants who are responsible for
designing and building case-based applications. Specifically, it addresses the following roles:
• Solution Architects

• Business Managers

• Development Managers and Developers

• Project Managers

The Pattern Library may also be helpful to pre-sales for answering RFIs, and for creating
demonstrations and proofs of concept that address customers’ business needs.

1.2 Approach
The xCP Pattern Library is based on the observation that case-based applications are
composed using a set of common patterns. The xCP Pattern Library provides a structured,
scientific way to plan, design and implement case-based applications.
Business-level patterns are called solution patterns, while technical-level patterns are called
design patterns. A solution pattern defines a functional requirement. A design pattern
describes a method (or “recipe”) of implementation. Both pattern types are organized into
logical categories that facilitate their use. Each solution pattern is mapped to a set of design
patterns. This two-tiered approach makes it easier to define solution requirements and
ensure traceability of implementation decisions to requirements.

1.3 Using the Pattern Library

The Pattern Library, together with design patterns and mappings, is available on the EMC
Developer Network (EDN). A full methodology describing how to use these patterns is

xCP Pattern Library 3

 Executive Summary

important, but outside the scope of this document. The following are a few methodological
suggestions.
Step 1: Working with the client, the business architect defines the business requirements for
the case lifecycle. This can be accomplished using solution patterns to articulate potential
requirements. For example, there are several alternative solution patterns for initiating a
case. A requirements review with the client should then be held.
Step 2: The solution architect translates these requirements into an overall design for the
system. This requires detailed definition of data modelling, case policies, external interfaces
and monitoring. The design proceeds through a series of iterations. For example, a
preliminary case data model is defined early in the project, but the data model cannot be
completed until the data design is fleshed out. The solution architect identifies the
appropriate design pattern for each solution pattern and documents the reasons for these
design patterns. The solution architect then holds a design review.
Step 3: Implementation. The development manager assigns the selected design patterns to
individual developers for implementation. Each developer must understand how the design
patterns relate to the original business requirements, as reflected in the solution patterns.
System testers verify that the implementation actually meets these business requirements.

1.4 Document Overview

Chapter 2 explains the basic concepts underlying solution patterns and design patterns.
Each subsequent chapter focuses on one category of solution patterns, presenting the
context, business value, approach, method, and possible variations for each solution pattern.
For example, Chapter 3 addresses Case Initiation, which includes four different solution
patterns. The rest of the chapters address each of the remaining categories: Manage,
Review, Communicate, Close Case, Data Model, External Interfaces, and Monitoring.

1.5 Benefits
Benefits of the Pattern Library include:
• defining business requirements more quickly and precisely

• enabling business executives and stakeholders to understand, influence, and

communicate what is being developed and why

• reducing time for application design

• reducing development and testing time

• improving the quality of the solution delivered to the customer

• reducing overall project risk

• providing a standardized approach to xCP case-based implementations

xCP Pattern Library 4

 Basic Concepts

2 Basic Concepts
2.1 Case-Based Applications
Businesses and governmental agencies often make decisions and take action in the context
of a case. A case is a pattern of work with the following characteristics:
• an event that initiates the case

• a set of case information (structured and unstructured)

• processes for managing information flow, human decisions, and system interactions

• a case outcome, deliverable, or decision

One example of a case is an insurance claim. A case is triggered when a customer files a
claim for damage to his car. The case information comprises the forms, photographs of the
damaged car, and the body shop estimate. The case worker makes sure that all documents
are in order and that work estimates are appropriate. The outcome is the payment for the
damage.

2.2 The History of Patterns

The idea of patterns was introduced for city planning by Christopher Alexander 1. He believed
that buildings and towns should reflect the daily life of the people who live and work there.
His idea was to look for recurring patterns of use and then identify essential design elements
that address those needs. For example, in highway design, a cloverleaf pattern is often used
because it solves a common problem of getting on and off the road.

A typical pattern approach allows great flexibility and variations (for example, highways are
planned with three-leaf and four-leaf interchanges).

Patterns were introduced into software design by Gamma, Helm, Johnson, and Vlissedes in
their book Design Patterns published in 1996. It showed that object-oriented software
applications can be constructed by using recurring patterns such as the factory pattern, the
facade pattern, and the observer pattern. As they say in the introduction, “Our solutions are
expressed in terms of objects and interfaces instead of walls and doors, but at the core of
both kinds of patterns is a solution to a problem in a context.”

The authors organized their design patterns into three major categories: creational patterns,
structural patterns, and behavioural patterns. In their treatment, each of these patterns has
four essential elements:

• Pattern Name

• Problem

1
See for example “A Timeless Way of Building” or “A Pattern Language” (1977)

xCP Pattern Library 5

 Basic Concepts

• Solution

• Consequences

EMC has taken a similar approach in the xCP Pattern Library.

2.3 Structure of the Pattern Library

The xCP Pattern Library is a collection of patterns that reduce a complex application to a
series of smaller decisions. The underlying premise of the Pattern Library is that decisions
need to be made at two levels:
• business requirements level (solution patterns)

• technical design level (design patterns)

Technical decisions must be driven by the decisions at the business level.

2.3.1 Approach
At a high level, the approach is as follows:
1. Divide the application into high-level functional modules (called solution pattern
categories)

2. Reduce each of these categories to a set of solution patterns, which are patterns at
the business level

3. Map each solution pattern to a set of one or more design patterns, which address the
technical implementation

It is important to emphasize that design patterns are defined at the technical level while
solution patterns are defined at the business level.

2.3.2 Solution pattern categories

Solution patterns are grouped into a series of categories. The categories are organized as
follows:
1. Foundation categories. These are fundamental to the design of any case-based
application and determine its global behavior. This includes two categories: Data
Model and the Case Policies.

2. Lifecycle categories. These are visible in the active, ongoing case. This includes
five categories: Initiate Case, Manage, Review, Communicate, and Close Case 2.

2
The lifecycle categories consist of functions, not processes. A single activity in a case can
incorporate functions from the Manage, Review, and Communicate categories. Or a case can
interleave activities from all three categories. There is no fixed activity order implied by these
categories, except that Case Initiation comes at the beginning and Case Closure at the end.
xCP Pattern Library 6
 Basic Concepts

3. Extension categories. These are optional but in practice can provide extreme value.
This includes two categories: External Interfaces and Monitoring.

The complete set of categories is illustrated in the following figure.

Manage Review
Initiate Close
Case Case

Communicate

Data Case External

Monitoring
Model Policies Interfaces

Figure 2–1 Solution Pattern Categories

Each Solution Pattern Category is described in terms of:

• Category Overview

• Approach, including key questions to consider

• List of solution patterns in the category

2.3.3 Solution patterns

Each Solution Pattern consists of a set of closely-related business functions. An example of
a Solution Pattern is “Monitor Case Instances,” which occurs in the Monitoring category. This
is shown in the following diagram:

Solution Pattern 1 Current Activity

Monitoring
Solution Pattern 2 Historical Reports

Solution Pattern 3 Managing by Exception

Monitoring
Solution Pattern 4 Publishing

Figure 2–2 Solution patterns in the Monitoring category

xCP Pattern Library 7
 Basic Concepts

Each Solution Pattern is described in the following way:

• Context: Short description of where and how the pattern is used

• Business Value: The value to the business that the Solution Pattern creates

• Approach: Brief overview of how the solution pattern works

• Method: Step-by-step instructions for defining the Solution Pattern in an actual

project

• Variations: Suggested alternatives, enhancements, or extensions

2.4 Design patterns

A solution pattern is implemented by a set of design patterns. An example of a design
pattern is Process Initiation by DQL Query, which is linked to the solution pattern Initiate
Process, which occurs in the Case Initiation category.
Each design pattern includes the following information:
• Context

• Description

• Prerequisites

• Solution

• Consequences

• Examples of use

• Related patterns

• Attachments

2.4.1 Design pattern categories

Just as solution patterns are grouped into categories based on business function, design
patterns are grouped into categories based on technical implementation. The set of design
pattern categories is shown in the following diagram:

xCP Pattern Library 8

 Basic Concepts

User-Oriented Process-Oriented Data-Oriented Operational

User Data Administra-

Process
Interaction Structures tion

Look & Feel Activity Integration

Invocation/
Initiation

Figure 2-3: Design pattern categories

This allows developers to investigate and learn about patterns from the bottom up. For
example, a developer who is building user interfaces might go directly to the User Interaction
category and review the user interface patterns. Design pattern categories allow developers
to focus on their areas of expertise.

2.5 Mapping solution patterns to design patterns

Each solution pattern can be mapped to one or more design patterns. This helps developers
implement solution requirements. In the example is below, a solution pattern is linked to two
design patterns:

Solution Pattern Category

Solution
Pattern

Design Pattern Category 1 Design Pattern Category 2

Design Design
Pattern Pattern

Figure 2-4: Mapping a solution pattern to design patterns

Note that the design patterns can occur in multiple design pattern categories.
To be specific, map the solution pattern “Initiate Process” to the design pattern “Initiate
process from document received via SMTP,” as follows.

xCP Pattern Library 9

 Basic Concepts

Initiate Process

Initiate process from document received via SMTP

Figure 2-5: Mapping a solution pattern to a design pattern

The mapping means that this particular design pattern is used in the implementation of the
requirement as defined by the solution pattern. This solution pattern is part of the solution
pattern category “Initiate Case.” The design pattern is part of the design pattern category
“Initiate/Invoke.”
Every design pattern falls into one of the design pattern categories. However, it is not
necessary that every design pattern have a mapping from the solution patterns. Some
Design patterns are generic and can apply across multiple solution patterns. For example,
the same user interaction design pattern might recur in the Manage, Review, and Close
Case categories.

xCP Pattern Library 10

 Initiate Case

3 Initiate Case
3.1 Overview
The lifecycle of a case begins with initiation. In order for a case to become a case, it must
execute a series of steps that ensure that it is valid and meets the prerequisite criteria. Upon
passing that validation, another series of steps prepares the case for the next phase in its
lifecycle: case work. Case work consists of three solution pattern categories: Manage,
Review, and Communicate.

3.2 Approach
A case is controlled by a process or series of processes. A process is invoked by a user
performing an action or by an external event. (It is important to note that these process
initiation patterns can be reused in other solution pattern categories). After invocation, the
initiation request is validated against defined guidelines. If successful, the case is set up and
enters the case work lifecycle phase.
When implementing a case initiation pattern, consider the following:
What mechanisms are available to invoke a process to begin case initiation?
Examples of trigger mechanisms include:
• a person completes and submits a form

• a person sends an email

• an external system event updates a database field

What constitutes a valid submission?

Examples of validation rules include:
• the submitted form must contain all required fields

• all fields have values within defined ranges

• the request must be submitted within the specified dates of eligibility

Are there criteria that will cause case initiation to fail?

Examples of automatic disqualification criteria include:
• the contact information provided by the requestor is invalid

• this case is a duplicate of another case

• the external system that submitted the request is unauthorized

If validation succeeds, are there mandatory data that must exist before the case can
move to the case work lifecycle phase?

xCP Pattern Library 11

 Basic Concepts

Examples of system-generated supporting data include:

• case must be assigned a unique ID

• folder hierarchy must be created and assigned to the case

• document templates must be copied to the case

• checklists for the case worker must be generated to guide their work

Is a reply to the requestor needed to acknowledge receipt of the request?

Examples of acknowledgment include:
• sending an email to the person who submitted the request

• sending a message to the system that submitted the request, passing on the unique
case ID

An Example from Grants Management:

An applicant for a grant submits a request form. A grants manager collects supporting
documentation in preparation for a review.
• What mechanisms initiate the case?

The grant applicant submits the request by completing an application form and
submitting it electronically via a variety of protocols.
• What constitutes a valid submission?

In addition to a completed submission form, the grant applicant must apply within the
eligibility window of January 1st to April 31st.
• Are there any criteria that would automatically cause case initiation to fail?

If the grant applicant is from a country that is a state sponsor of terrorism, the request
is rejected automatically and the case is not initiated.
• If validation succeeds, are there mandatory data which must exist before the case
can enter the case work lifecycle state?

The case must be assigned a unique identifier, and a folder structure must be
created and attached to the case to store supporting documentation and data for the
case.
• Is a reply to the requestor needed to acknowledge receipt of the request?

The requestor must receive an email acknowledging their request.

3.3 Solution patterns in this category

There are 4 solution patterns within this category:
1. Initiate Process

xCP Pattern Library 12

 Basic Concepts

2. Validate Case

3. Set Up Case

4. Accept Case

The solution pattern “Validate Case” is automatic – it is performed by the system. “Accept
Case” refers to human-level validation and acceptance of the case. Some setup might be
required before Accept Case and can occur in Set Up Case. (For example, assigning user
roles to the case is part of setup, but it would not make sense to assign user roles if the case
were not accepted.)

3.4 Solution pattern 1: Initiate Process

3.4.1 Context
An external event (whether triggered by a human action, another system, or another
process) provides the signal to initiate a case. This solution pattern generalizes slightly from
“Initiate Case” to “Initiate Process,” since this general pattern recurs throughout the lifecycle
of a case.

3.4.2 Business Value

The electronic capture of requests, supporting a variety of methods and protocols, gives
businesses maximum flexibility to support their clients, customers, partners, and associates.

3.4.3 Approach
Identify the conditions, data, and mechanisms by which a person or system can establish a
case.

3.4.4 Method
1. Determine if there are preconditions for initiation. For example, to submit an
automobile claims form, it is assumed that some damage to the car has occurred.

2. Identify the required case data for each type of initiation. What is the minimal
information that the case worker needs to begin working on a case?

3. Identify the mechanisms or protocols used to submit the case data. Is this done by a
human submitting a form? How should that form be submitted? Will an external
system event generate the case data? Will it be a combination of both?

4. Process the incoming request and launch a Validate Case instance.

5. Define the different types of case initiation failure that can occur and how each is
handled.

3.4.5 Variations
• Log all initiation attempts and identify those that were successful and unsuccessful.

xCP Pattern Library 13

 Basic Concepts

• Some types of cases will be assigned case numbers at this point, while other types
will be assigned case numbers only after validation and acceptance are complete

xCP Pattern Library 14

 Basic Concepts

3.5 Solution pattern 2: Validate Case

3.5.1 Context
After process initiation completes successfully, the submission will often require validation
before becoming an official case. This can sometimes be done automatically, by a system
process. However, in many circumstances a manual review task will also be needed.

3.5.2 Business Value

Case workers avoid wasting valuable time if the system can detect and reject extraneous,
fraudulent, or mistaken case initiations.

3.5.3 Approach
Define the minimum qualified data and criteria for case initiation to complete successfully.
Decide whether case validation is performed entirely by the system, or by a combination of
system and human action.

3.5.4 Method
1. Assemble all required submission data.

2. Identify criteria for validating the case.

3. Apply these criteria to the incoming request.

4. Perform human tasks, if needed, to complete screening.

5. Take appropriate action if the validation fails.

3.5.5 Variations
• Consider a two-tier validation in which a preliminary step is performed by the system
based on business rules, followed by a brief screening by a case worker.
• Send an email to the initiator if the validation fails. Provide some explanation for the
reason it failed.

xCP Pattern Library 15

 Basic Concepts

3.6 Solution pattern 3: Set Up Case

3.6.1 Context
A case request is submitted and validated. Before case work begins, however, certain basic
setup activities must be completed.

3.6.2 Business Value

Reduce the manual effort of case workers by automatically creating case data and
acknowledging cases before they reach the case worker’s desk.

3.6.3 Approach
Assemble all data required to begin case work automatically by means of a system process.
Assign an identifier to the case. Initiate communication to the person or system that
requested the case.

3.6.4 Method
1. Identify the folder hierarchy needed to support case processing.

2. Assign a unique case identifier to the case. This identifier is needed to coordinate
case-related activities across multiple users and processes.

3. Identify case data that can be created automatically, without human intervention.

4. Map any data received in the initiation to the case (for example, if the submitter fills
out a web form).

5. Import all documents submitted to the case (for example, if the submitter files a
document required to open the case).

6. Assign the case to an appropriate case manager (See the solution pattern category
“Case Policies” for details on how this is done).

3.6.5 Variations
• Based on business rules, send an automatic notification to the manager of this case.
For example, if a request is received from a government regulatory agency, notify the
department manager.

xCP Pattern Library 16

 Basic Concepts

3.7 Solution pattern 4: Accept Case

3.7.1 Context
In many business environments, a case must be reviewed by a human being to determine
that it is complete and accurate.

3.7.2 Business Value

This allows human judgment to be incorporated into the decision to move forward or reject a
case. For example, in court case management, a court clerk needs to review the filing
information to ensure it is complete and accurate. This decision cannot be automated.

3.7.3 Approach
Use a utility process to automatically assemble all data required to begin the case. Assign an
identifier to the case. Initiate communication to the person or system that requested the
case.

3.7.4 Method
1. Create an acceptance task and send it to the appropriate decision maker.

2. Ensure that all required information about the case request is available and easily
accessible.

3. Enable the user to make a decision, typically by pressing a button.

4. If necessary, allow the user to add comments explaining the reason if the case is not
accepted.

3.7.5 Variations
• Reject case. How will this be handled? One approach is to delete the case request
and associated information. A better approach is often to archive case related
information.

xCP Pattern Library 17

 Manage

4 Manage
4.1 Category Overview
The Case Initiation category brings information from the outside world into the case. This
includes both structured data and unstructured content (documents, images, audio files, etc.)
In the Manage category, the case worker must be able to view, create, or update the
information. With this information, the case worker takes appropriate actions, such as
requesting more information, sending the case for review, or making decisions on the case.
Often these actions are then followed by Review or Communicate functions.

Case Work

Review

Initiate
Manage
Case

Communicate

Figure 4-1 “Manage” in relation to other Solution Pattern Categories

The three solution patterns: Manage, Review, and Communicate constitute the “case work”
functions. They can occur in any order and can be iterated as necessary.

4.2 Approach
To manage a case, a case worker makes sure that it contains all required information,
progresses properly, and accomplishes its goal. This involves producing and consuming
case information, taking actions, and making decisions.
When implementing a case management pattern, consider the following:
Who manages the case? The case needs to be sent to a case worker to handle the details.
For example, in a typical insurance claims case, a case worker will be assigned to the case
based on a phone call from a claimant. In some cases, it might be necessary to assign
multiple case workers, or refer it to a supervisor for additional decision making.
How does the case worker find case information? Case workers need to view
information about the case. Ideally, the required case information is displayed on their

xCP Pattern Library 18

 Manage

screen in a way that is clear and easy to navigate. Often they will need to search for
documents related to the case or to examine related cases. For example, the claims worker
might want to find and inspect previous automobile claims made by the claimant.
How does the case worker manage case data? Every case contains structured data
describing the details of the case. For example, for an insurance claim, the case worker
needs to have the name and policy details for the claimant and the description of the
damage. As further information is received about the extent of the damage, the case worker
may be required to enter or change this data.
How does the case worker manage documents associated with the case? A case may
contain a variety of documents, images, or video files. For example, the case worker might
receive a digital photograph of the damaged car that must be kept in the virtual case folder.
What actions can the case worker perform and when? Case workers can initiate actions,
such as asking for more information or requesting a review. For example, the claims worker
may decide to approve the automobile claim. The actions that a case worker can perform
often depend on the state of the case: for example, the ability to import a certain type of
document might be enabled in one phase of the case but not in another.

4.3 Solution patterns in this category

The Manage category includes the following solution patterns:

1. View Case

2. Manage Case Data

3. Manage Case Content

4. Find Case Information

5. Perform Case Actions

xCP Pattern Library 19

 Manage

4.4 Solution pattern 1: View Case

4.4.1 Context
The case worker needs to view the case in order to review case status, data, documents,
and actions. This view is especially important in the non-task-oriented cases, as work is
done in a “case command center” that is independent of tasks.

4.4.2 Business Value

The ability to view the case is the most fundamental capability of case management. A well-
designed desktop can improve efficiency and help a case worker to resolve cases quickly.

4.4.3 Approach
A good example of a case view (a “folder view”) is shown below.

Figure 4-2 Case Command Center

Notice the following features:

1. User can browse through a set of folders related to the case.
2. User can access business logs and calendars, as well as documents.
xCP Pattern Library 20
 Manage

3. User can enter and view other case metadata (shown on right).
4. The interface includes a set of action buttons, which depend on the case state. For
example, if the case worker makes a telephone call, she can press the Record Call
button to enter the details of the call.

4.4.4 Method
1. Display all relevant folders (for example in a tree structure, as shown in the left).

2. Provide relevant case metadata that can be entered, viewed, and changed.

3. Identify required actions for the case worker and implement them as action buttons.

4.4.5 Variations
• Perform a validity check on data entered in a form.

• Make some fields mandatory and others optional.

• Create conditional fields, in which the fields that are displayed in a form depend on
data entered (either in the same form or in other forms).

xCP Pattern Library 21

 Manage

4.5 Solution Pattern 2: Manage Case Data

4.5.1 Context
This solution pattern addresses the creation and modification (and occasionally the deletion)
of case data (that is, information about people, objects, or events in the case).

4.5.2 Business Value

Case data describes and summarizes information about people, forms, business objects,
and events that are important to the case. For example, in a loan application, case data
might include the name of the person applying for the loan, the account number, the amount
requested, and evidence of the ability to repay the loan. Decisions are ultimately based on
case data, such as whether to approve or reject the loan application.

4.5.3 Approach
Case data is presented to the user via forms (organized collections of data fields). Data is
automatically populated in the form and case performers can enter it manually. Performers
can view the data and update it as needed.

Figure 4-3 Data fields in a form

4.5.4 Method
1. Identify data that is relevant for the case (see the Case Modeling category).

2. Decide on the presentation format for the data (for example, text field, drop down,
check box).

3. Identify the case workers who need to work on the data and in which activities.

4. Group data fields together into forms if they are logically related.

5. Show or hide different data fields for each task and case worker (In some tasks, the
data will be invisible, in other tasks it will be grayed out). Display only the relevant

xCP Pattern Library 22

 Manage

information in each task: irrelevant data distracts from the work that must be done,
and some data should not be shown for case policy reasons.

4.5.5 Variations
• Perform a validity check on data entered in a form.
• Make some fields mandatory and others optional.
• Create conditional fields, in which the fields displayed in one form depend on other
forms or affects fields in the same form.

xCP Pattern Library 23

 Manage

Solution pattern 3: Manage Case Content

4.5.6 Context
Case content refers to documents, video clips, photographs, scanned images and other
unstructured information. Content can play a critical role in a case (for example, a signature
in a legal document). Case workers must be able to create, access, and manage content.

4.5.7 Business Value

Case content management allows case workers to create, view, modify, transform and
delete content. Some cases are initiated when documents are received, such as an
application form. In many cases, content is required to serve as evidence (for example, a
photo ID). In other cases, the main purpose of the case is actually to create certain
documents.

4.5.8 Approach
Each type of content can have data associated with it (metadata). For example, document
metadata might include author, document type and date received. Often the management of
the content depends on the metadata.

4.5.9 Method
As appropriate for the case under consideration, create tasks that enable case workers to:
1. Import documents and other content into the case. This can be done automatically by
a utility process or manually by a case worker.

2. Organize content into folders. This is generally done automatically by a utility

process.

Figure 4–6 Managing content by folders

On the left is a list of folders for content. The contents of the Case Participants folder
are shown on the right, together with document metadata.

xCP Pattern Library 24

 Manage

3. Display content (in this case an image) together with its associated metadata

Figure 4–7 Viewing content and its metadata

4. Enter or change document metadata (manually or automatically).

5. Create or edit content, if required (for example, write a document in MS Word).

6. Modify documents (for example, deleting pages, reordering pages).

7. Manage content versions.

8. Annotate documents.

4.5.10 Variations
• Number all documents in a case.
• If the content is received in paper format, scan it, index it, and import it into the case.
• Transform the format of the content (for example, render a MS Word document in
PDF format).
• Import content from external sources (for example, SharePoint).
• Hold all content in a single folder and use a filter mechanism to restrict the view.

xCP Pattern Library 25

 Manage

4.6 Solution pattern 4: Find Case Data

4.6.1 Context
As part of their research, case workers often need to locate individual cases, documents,
person records, or other case information.

4.6.2 Business Value

Case research helps discover facts needed to make the decisions in a case. For example, in
the insurance claims industry, a case worker might want to find similar claims that have been
submitted in the past that involve the same claimant. In general, case workers must be able
to perform some level of research using case-based tools.

4.6.3 Approach
There are three ways to find case data:

• explicit search

o Search for data, documents, cases

o Full-text search

• browse folders for documents

• select items from a pre-defined list

The following graphic shows an example of an explicit search in TaskSpace:

Figure 4–8 Search criteria

The following graphic shows an example of providing the user with the ability to select a
case from a drop-down list.

xCP Pattern Library 26

 Manage

Figure 4-9 Selecting a case from a drop-down list

After selecting the case, the user presses the Open button. This is clearly simpler than
performing an explicit search.
Note: If this case had already been closed and the user selected it in the dropdown list, then
she would not see a button labelled “Open.” Instead, the button would change to “Re-open.”
This is a good example of case state-sensitive action buttons.

4.6.4 Method
1. Identify the type of item to find (for example, cases, documents).

2. Determine the technique to be used: explicit search, browsing, or select from list. If it
is an explicit search, specify the search criteria (possibly including wildcards).

3. Decide how the system should respond when the user makes a choice (for example,
how to display the hits, or what to do when the user selects an item from a list)

4.6.5 Variations
• Use full-text search for terms in a document or set of documents.
• Search a federated database.
• Select a case from a dropdown list on the Welcome screen.

xCP Pattern Library 27

 Manage

4.7 Solution pattern 5: Perform Case Actions

4.7.1 Context
Case workers need to do more than view and enter case information. They need to be able
to take action based on this information. Case workers perform actions to request more
information, send the case to a reviewer, or approve the case.

4.7.2 Business Value

Performing case actions enables the case worker to include human decision-making, based
on knowledge and experience. Many cases are ultimately approved or rejected, but there
are many intermediate actions and decisions that must be made. For example, a case
worker might find a scanned document to be unclear and request a re-scan.

4.7.3 Approach
The basic tool for performing actions is the action button.

Figure 4–10 Action buttons

Each button is configured to perform an action. For some cases, like “Approve,” pressing the
button is all that the case worker needs to do. For other actions, the button launches a form
for the case worker to fill out with details associated with the action. For example, the “Send
to Reviewers” button initiates a review activity. The case worker needs to select the
reviewers and provide some instructions, as shown in the following form:

Figure 4-11 Action button launching a form

Notice that this form includes two action buttons.

xCP Pattern Library 28

 Manage

Each action button has some result or consequence. In this example, the result is that the
system creates tasks for the selected reviewers to perform.

4.7.4 Method
1. For each role in the case, determine which actions and decisions that role needs to
perform and under what conditions (depending on the state of the case).

2. Decide which actions are needed in each activity performed by that role.

3. If additional information must be entered, describe the required information.

4. Specify the consequences of the action. For example, if the decision is to accept the
insurance claim, send an email to the claimant to that effect.

4.7.5 Variations
• Initiate an ad hoc task
• Initiate a task by supplying a URL instead of by pressing a button. (This might be
used for a scanning task or any task in which the user needs to supply data).
• Initiate a process.

• Create a form instance.

• Cancel checkout.

• Print the form.

xCP Pattern Library 29

 Review

5 Review
5.1 Category Overview
The purpose of a review is to make sure that the outcome of the business process or case
(be it a physical object, a document or a business decision) is correct and meets the desired
quality criteria. The verification is captured by the outcome of the review. The review
patterns have to be flexible enough to handle differences in the kinds of object being
reviewed, the outcome of the review, and the review policies.
The review phase can include a combination of human and system activities. For example, a
process may invoke a rules engine to determine eligibility, but also allow a human to
override that decision. However, it is unlikely that a real case review would contain only
system activities with no human activities.
Review patterns cannot be viewed in isolation, since they are dependent on solution patterns
in other categories. For instance:
• A review is typically preceded by case work (as in the Manage or Communicate
categories).

• A review can be followed by more case work.

• Case work and case review activities can be interleaved.

• Case review activities often depend on general case policies:

o The user who performs the review is determined by an assignment policy.

o A prioritization policy determines the order in which a reviewer performs

multiple reviews.

o An escalation policy determines what happens when a reviewer does not

perform the review on time.

5.2 Approach
When implementing a review pattern, consider the following:
What is it that needs to be reviewed? What is the thing, object or information being
subjected to a review? This can be an object within the system, a physical object outside of
the system or both. Examples of objects that can be reviewed are:
• a document

• an image

• a collection of documents

• a decision to approve a case

xCP Pattern Library 30

 Review

• an audit trail

• a customer call

• a Case Management methodology

What are the review criteria? Review criteria are the principles and methods by which the
reviewer evaluates the object under review and produces review results. They can be
defined in a checklist, a test procedure, a corporate policy, or codified in a legal document.
The review criteria might exist outside of the system, as such, but govern how the review is
performed, who performs it, and what the outcome is.
Who performs the review? The reviewer performs the actual evaluation and produces an
outcome. How the reviewer is assigned is governed by an Assignment Policy Pattern. (See
the section on Case Policies). Examples of reviewers are:
• the manager of the employee who produced the object being reviewed

• a subject-matter specialist

• a steering committee

• an automated system (for example, a business rules engine)

Under what circumstances is the review performed? This question captures two aspects
of the review. First, it asks when the review is performed. In certain circumstances, a review
is always performed at a certain point, while in others it depends on the context (for
example, the funding amount requested in a grant application). In other circumstances, an
external event triggers the need for the review (for example, a visit by a third-party auditor).
Second, this question asks whether the review is to be performed as part of normal case
processing,
or is performed only if requested by the case worker.
What is the outcome of the review? The purpose of the review is to produce a result.
Examples of common outcomes are:
• a decision or signoff (e.g. approved or not approved)

• a document

• a marked-up version of the document under review

• comments

• a new version of a document

• a digital signature

What effect does the review have on the case? Within the context of a case or a business
process, the outcome of a review can influence the progress of the case or decide the future
activities that will take place within the business process. This question also captures how
the review interacts with case work, since the review might trigger additional case work until

xCP Pattern Library 31

 Review

a sufficient level of quality has been reached. Examples of the effect a review can have on a
case are:
• to move the case to a revision activity

• to effect a change in the state of the case (for example, a loan is approved)

• to produce nothing other than a review outcome

• to terminate the case

Example
Consider a grant application process in which a grants manager reviews a request for the
purpose of approving or denying the grant, but he only needs to review it if the request is for
an amount greater than $10,000. The solution team might answer the questions above as
follows.
• Q: What needs to be reviewed?
A: The grant application.

• Q: What are the review criteria?

A: The grant application is judged on three criteria: originality, importance, and ability
to execute. In an actual case this would be clarified by a more explicit series of
questions that would need to be answered and judgments that would have to be
made.

• Q: Who performs the review?

A: The individual assigned to perform a peer review. How the reviewer is selected is
determined by an Assignment Policy Pattern and might, for instance, depend on the
type of grant sought or on reviewer availability.

• Q: When is the review performed?

A: When the funding requested is greater than $10,000.

• Q: What is the outcome of the review?

A: The outcome is a decision, either to approve or to deny the grant request. (In other
types of cases, the outcome might only be a recommendation and the final decision
would occur later, based on the recommendations of one or several reviewers).

• Q: What effect does the review have on the case?

A: The outcome triggers a state change of the case. The applicant is informed of the
decision and, depending on the decision, the case is closed.

5.3 Solution patterns in this category

There are two solution patterns defined within the Review Pattern Category:
1. Sequential Review

2. Parallel Review

xCP Pattern Library 32

 Review

5.4 Solution Pattern 1: Sequential Review

5.4.1 Context
This pattern occurs when case information (structured data or unstructured content) needs
to be validated in a series of one or more reviews. The simplest example of a sequential
review is the single review.
Multiple reviews can be formed by chaining together a series of single-step reviews. In many
cases, the downstream reviews depend in some way on the results of the upstream reviews.

5.4.2 Business Value

As with any review, the main business value is to ensure the correctness, quality and
compliance of the work being performed. The sequential reviews generally build upon the
previous reviews. For example, review 1 evaluates the content of a document and review 2
evaluates it in terms of style. The stylistic review requires the content to be corrected first.

5.4.3 Approach
The trivial sequential review involves only one review activity and is captured by the
following flow:

Figure 5–1 Simple sequential review

The information or work product that is to be reviewed is produced and handed over to the
reviewer. The reviewer evaluates the information or work product according to the review
criteria produces an outcome. The outcome of the review can then be used in downstream
activities in the case.
The sequential review becomes more complex as more steps are required. For example,
here is a process fragment with two review steps:

Write Department Director

Proposal Head Review Review

Figure 5–2 Complex sequential review

5.4.4 Method
1. Identify the work product that needs to be reviewed. Is it the entire case, a subset, an
audit trail or an object external to the system?

xCP Pattern Library 33

 Review

2. Identify the criteria against which the review is to be performed. Provide instructions
that explain the criteria to be used by the reviewer.

3. Identify the person or system responsible for performing the review. This could be a
specific individual (“VP, Loan Operations”), it could depend on the values of data
fields, it could be the performer of a previous task, or it might just be any individual
from a group.

4. Identify the circumstances under which the review takes place. Does the review
always take place, or only under certain conditions?

5. Identify the outcome of the review. Is the outcome a simple decision, a digital
signature, a document, or a report?

6. Identify the effect that the outcome has on the case. Does it influence the process
flow, or is simply a document stored within the case?

5.4.5 Variations
There are several important variations of the Sequential Review:
• Conditional Sequential Review
• Iterative Sequential Review
• Sequential Review with Delegation
It is not uncommon for these variations to be combined in the same process. For example, a
case might include an Iterative Conditional Sequential Review or an Iterative Sequential
Review with Delegation.

5.4.5.1 Conditional Sequential Review

A common variation is the Conditional Sequential Review. When a condition is added it
changes the answer to the question “When is the review performed” from “always” to “when
the condition is true.” In other words, in a conditional review the review isn’t always
performed; instead, it depends on a condition of some kind. The conditional review is
illustrated in the following process fragment.

Figure 5–3 Conditional sequential review

5.4.5.2 Iterative Sequential Review

Another common variation is the Iterative Sequential Review. In the iterative review, the
outcome results in a decision, which may continue to trigger additional work until a sufficient
level of quality has been achieved (that is, until a positive decision has been reached). The
iterative review is illustrated in the following process fragment:

xCP Pattern Library 34

 Review

Figure 5–4 Iterative sequential review

Sometimes the iterative review is restricted to a fixed number of iterations (or alternatively to
a certain time duration), after which the process either continues or is terminated.
Typically the performer of the “Revise” step is the same as the one who created the initial
work product, but this is a matter of case policy and is not invariably true.
Note that the decision point “Decision” can be a human decision, made by the same
reviewer in each review cycle. However, it could also be assigned to a different person for
each review. In some cases, it might even be an automatic activity.

5.4.5.3 Sequential Review with Delegation

Another common variation occurs when the reviewer is allowed to delegate the review.
There are several aspects of delegation that can vary as well, such as:
• Successive delegation: Can the user to whom the review is delegated delegate it
further? (that is, can delegations be nested?)

• Feedback, Is the review outcome sent back to the original reviewer, or is the
outcome just forwarded to the next activity?

The essence of the sequential review with delegation is illustrated in the following process
fragment.

xCP Pattern Library 35

 Review

Figure 5–5 Sequential review with delegation

The issues concerning patterns of delegation are addressed in the Case Policy category.

xCP Pattern Library 36

 Review

5.5 Solution Pattern 2: Parallel Review

5.5.1 Context
In some situations, it may be necessary for multiple people to perform reviews at the same
time, either because a group decision is needed or because different people are reviewing
independent aspects of the work product.

5.5.2 Business Value

The purpose of this solution pattern is to improve efficiency by the strategy of “divide and
conquer.” Different performers may have different skills and can work in parallel. This can
save a significant amount of time over performing these review tasks sequentially. The
Parallel Review solution pattern prevents the process from proceeding until all aspects of the
work product or case have been approved by the person responsible for each aspect.
There are two fundamental differences between the parallel and the sequential review:
• Multiple reviews are performed in parallel

• Multiple outcomes are produced, and they must be combined in some way. This is a
question of policy. It can be that all decisions must be positive, or perhaps multiple
decisions will be merged into one by majority vote, or that multiple review reports will
simply be added to the case.

5.5.3 Approach
The essence of the parallel review is illustrated by the following process fragment:

Figure 5–6 Parallel review

5.5.4 Method
1. Specify the information or work product that needs to be reviewed (for example, a
document, a set of information, a decision, or the entire case).

2. Identify the different aspects of the information or work product that need to be
reviewed and ascertain if they can be reviewed independently.

xCP Pattern Library 37

 Review

3. Specify the criteria against which the review is to be performed. Provide instructions
on the criteria for the review for the reviewer (that is, by providing instructions for how
the review is to be performed).

4. Identify the persons responsible for each review. This might be a specific individual
(“VP, Loan Operations”) it might depend on case data, it could be the performer of a
previous task, or it might just be any individual from a group and is governed by an
assignment policy pattern.

5. Determine when the review takes place. Does the review always take place or only
under certain conditions?

6. Describe the outcome of the review. Is the outcome a simple decision, a digital
signature, a document, or a report?

7. Explain how multiple outcomes are to be combined. Is it a majority vote, or are

multiple documents added to the case?

8. Determine the effect that the outcome has on the case. Does it influence the process
flow, or is it a document stored within the case?

5.5.5 Variations
The variations of the parallel review are fundamentally the same as the variations for the
sequential review.

5.5.5.1 Conditional Parallel Review

The conditional parallel review is similar to the conditional sequential review, except that the
entire review, as well as certain aspects of the review, might be optional. For example,
suppose the condition is “Does the document include images?” If the answer is yes, the
images are reviewed in parallel with the content of the document. However, if the document
has no images, then only the document content is reviewed.

5.5.5.2 Iterative Parallel Review

The iterative parallel review is similar to the iterative sequential review, except that if a
positive decision is not reached, all reviewers might need to perform their review again. Or
perhaps only the aspect that failed review will need to be reviewed again.

5.5.5.3 Parallel Review with Delegation

The parallel review with delegation is similar to the sequential review with delegation. Each
reviewer may be allowed to delegate all the review work, or perhaps only certain aspects.
For example, the manager might be required to review the content of the document, but the
images in the document could be delegated to someone else.

xCP Pattern Library 38

 Communicate

6 Communicate
6.1 Category Overview
Most cases require some form of communication between persons within the case, or with
external agents. Communication can occur at any phase of the case lifecycle. It can convey
a question or an answer, a request for information, a formal notification of a decision, or it
can be informal collaboration.

6.2 Approach
Different types of communication are needed and each has its own characteristics. When
implementing a communication pattern, consider the following:
1. Which parties are communicating? The communication can take place between
parties working on the case (for example, between a grants manager and a peer
reviewer), or the communication can be with an external party (for example, between
the grants manager and the applicant).
2. Who initiates the communication? In the case of communication with an external
party, the communication can be initiated by the external party or by a case worker.
The former is referred to as “receive external communication” and the latter as “send
external communication.”
3. What type of information is being communicated? This could be simple text, as in
an email, but it could also include data fields or documents. For example, a grant
applicant might send a project plan as a PDF document.
4. Is the communication formal or informal? External communication is generally
formal, but internal collaboration can be formal or informal. An example of informal
collaboration might be a collaborative discussion between a grants manager and
grants reviewer.
5. Is a legal signature required? This is an important special case, in which an
external party must sign and return a legal document. For example, if a party applies
for a loan of $500,000, then a wet signature is required on the loan application.
6. What is the mechanism of communication? Communication can take place in a
variety of ways, such as email, text message, a web form, a telephone call, or
standard paper mail. If paper mail is used, then conversion from paper to digital
format is generally required.
7. How can this communication be secured? For example, https can be used for
transport layer encryption.

xCP Pattern Library 39

 Communicate

6.2.1 Solution patterns in this category

The following solution patterns are defined within the Communicate category:
1. Send External Communication

2. Receive External Communication

3. Document Signature

4. Formal Internal Communications

5. Informal Internal Collaboration

xCP Pattern Library 40

 Communicate

6.3 Solution Pattern 1: Send External Communication

6.3.1 Context
It is often necessary to send communications to the outside world. Some communications
are one-way, such as notifications, approvals, or document delivery. Others follow a request-
response model, as, for example, a request for tax forms. If the outgoing communication
contains documents, the documents can be automatically generated, based upon case data,
and personalized.

6.3.2 Business Value

The aim is to integrate seamlessly all forms of communication within the case, so that the
case worker is not distracted by switching to separate systems, each with its own user
interface. For example, the xCP application interoperates with the organization’s email
system so that the case worker receives and sends emails from within the case. This saves
time, minimizes errors, and keeps the case worker focused on the task at hand.

6.3.3 Approach
Begin by identifying the touch points in the case where it is necessary to send notifications
and receive responses. The designer can take advantage of pre-built activities and utility
processes for implementing the different forms of communication. If necessary, create new
interfaces for external communication. See the section of this document called “External
Integration” for more on this subject.

6.3.4 Method
Following are typical techniques for sending external communications:
1. Send outgoing email. In the following example, the user is prompted to fill out a form.
The process automatically transforms into an email.

xCP Pattern Library 41

 Communicate

Figure 6–1 Outgoing email

Once the user presses the Send button, the system sends an email based on the
form to the recipient.
2. In many cases, it is necessary to attach documents or images to the email. Custom
documents can be automatically generated from case text and data. They can be
personalized for the recipient as shown in the following example:

xCP Pattern Library 42

 Communicate

Figure 6–3 Custom generated document

xCP Pattern Library 43

 Communicate

6.3.5 Variations
• Send a reply to received external communications.
• Generate custom documents with barcodes.
• Send facsimiles.

6.4 Solution Pattern 2: Receive External Communication

6.4.1 Context
It is often necessary in a case to receive communication from the outside world. Examples
are filing documents, email with attachments, and responses to requests for information. In
some cases, the incoming communications will have to be correlated with previous outgoing
communications (as in a response to a request).

6.4.2 Business Value

As in the Send External Communication pattern, the aim is to integrate all communication
within the case seamlessly, so that the case worker is not required to switch between
different systems, each with its own interface.

6.4.3 Approach
The designer can take advantage of pre-built activities in business processes to receive the
required types of communication. If necessary, create new mechanisms for external
communication. See the External Integration section for details.

6.4.4 Method
Following is the typical method for responding to a request sent by email:
1. The case-based application listens for incoming email,

2. The application detects the case identifier

3. It saves the body of the message to the identified case

4. It saves the email attachments to the case

6.4.5 Variations
• Receive an incoming paper communications. The incoming document is
commonly scanned and indexed.

xCP Pattern Library 44

 Communicate

6.5 Solution Pattern 3: Document Signature

6.5.1 Context
This particular pattern is a variation of the simple external communication. It occurs when an
organization requires a wet or electronic signature on a document.

6.5.2 Business Value

This pattern is common in financial services and also within government. For example, a
bank sends a new account application to the customer for signature. Once the bank receives
the signed document, the document is added to the case.

6.5.3 Approach
The case sends an outgoing communication to the customer and waits for the response. The
incoming (paper) document with the signature is scanned and added to the case.

6.5.4 Method
1. Identify documents that require a wet signature.

2. Generate and print the documents.

3. Send the printed documents to the customer for signature.

4. When the document is received from the customer, scan and digitize it.

5. Add the digitized document to the case

6.5.5 Variations
• Generate a barcode on the document.
• Ask the customer to attach additional paper documents (for example, a tax form).
• Configure a time-out on the incoming communication.
• Use a digital signature instead of a wet signature (for example, this can be done if the
document is in PDF format and the customer has Adobe Acrobat Pro).

xCP Pattern Library 45

 Communicate

6.6 Solution Pattern 4: Formal Internal Communication

6.6.1 Context
Case workers interact in a variety of ways. For example, managers assign tasks to case
workers, and case workers sometimes delegate tasks to other persons. There needs to be
some form of communication between these participants.

6.6.2 Business Value

Formal case communication is used to provide clear instructions and feedback on tasks.
These communications will also become a persistent and auditable part of the case.

6.6.3 Approach
Formal communication is generally handled in the actual tasks that workers perform. The
tasks contain appropriate fields in which a worker provides input or response.

6.6.4 Method
Following are several techniques that are used in intra-case communications:
1. Instructions

Figure 6–5 Instructions

2. Feedback or response to a task

Figure 6–6 Reviewer response

This represents an official evaluation of the grant application.

xCP Pattern Library 46

 Communicate

3. Notes

Figure 6–7 Case notes

Notes are comments entered by case workers and provide a running account of the
case.

4. Action Log

Figure 6–8 Action log

The Action Log keeps track of all significant business events in the lifetime of the
case. It provides a good communications vehicle for all case workers to understand
the history of the case.

6.6.5 Variations
Respond to a task request and provide an explanation

Figure 6–9 Accepting a case

xCP Pattern Library 47

 Communicate

6.7 Solution Pattern 5: Informal Collaboration

6.7.1 Context
Case Workers complete most tasks by themselves. However, some tasks require informal
interaction with other case workers or internal experts.

6.7.2 Business Value

Collaboration enriches the store of information available to the case, expands the breadth of
alternatives to consider, provides new insights, and enables better decisions.

6.7.3 Approach
Collaborative activities can take place in different forms:
1. Joint activity: An activity in which two people work simultaneously together

2. Request/response: An activity done by person A, who requests assistance from

person B

3. Discussion or chat: Person A sends comments to person B through the case in an

informal band of communication

4. Common knowledge base: An activity in which one or more people contribute

information to a topic in a common knowledge base, which can then be accessed by
case workers.

6.7.4 Method
1. Joint Activity. Assign two workers to perform a single activity. They can interact on
this task in different ways: on the phone, in the same office, or by web-based
communication.

Figure 6–10 Joint activity

2. Discussion: This technique enables informal channels of communication, so that

case workers can send (out of band) messages to one another.

Figure 6–11 Informal interaction

xCP Pattern Library 48

 Communicate

This is incorporated into the Grants Management application as a threaded

discussion, as shown below:

Figure 6–1 Entering an informal comment

3. Common knowledge base. This is modeled as a standalone activity assigned to a

group of workers. They create information that can be accessed by the case. For
example, a group of healthcare researchers might be contributing information that is
needed to make decisions for an individual patient.

Figure 6–2 Interaction using a common knowledge base

6.7.5 Variations
• Post communications to a wiki.

• Post communications to a collaboration space in CenterStage.

xCP Pattern Library 49

 Close Case

7 Close Case
7.1 Overview
After a case is finished it needs to be closed. In order to end a case, the system performs a
series of automated or manual activities. These activities update case status for reporting,
move case data to offline storage, and ensure the case meets compliance and audit
requirements.

7.2 Approach
During the lifecycle of a case, a set of case data, documents, and folders typically transition
from state to state. Once the case is complete, it is usually necessary to separate and
archive this information. In addition, most reports need to distinguish between active cases
and closed cases.
When implementing a case closing pattern, consider the following:
1. What case actions trigger case closure? A user may decide to initiate case
closure based on external events or predefined criteria might be set for automatic
case closure.
2. Does a final disposition document representing the case need to be
generated? For historical or audit purposes, there may be a requirement to generate
a read-only disposition document that contains a combination of different case
documents and data.
3. Do the case folders, documents, and data need to be moved? In many
situations, it is useful to store active case data in a separate physical location from
the data of closed cases. The data might be moved to a cheaper storage medium
since data access will be less frequent.
4. Will the case ever need to be reopened? If a case can be reopened after it has
been closed, then you might need to store the active state of the case, such as the
security applied to data or transient data such as the case actors.
5. Do external systems need to be updated with the results of the case? Case
management systems frequently interact with other systems to retrieve case data, to
make this data persistent, or to carry out case management functions.
6. Does the case information need to be published to a website? Once a case is
closed, there may be a requirement to publish the results to a broader audience. For
example, most modern judicial systems allow the public to view the case verdict after
it has been issued.
Depending on what decisions were taken to complete the case, the system might need to
execute specific business logic or perform updates to other systems in order to close the
case. It might also need to generate documents that represent the official verdict, outcome,
or summary of actions that lead to the conclusion of the case.

xCP Pattern Library

50
 Close Case

7.3 Solution patterns in this category

The following solution patterns are defined within the Close category.
• Case Data Archival

• Case Disposition

xCP Pattern Library 51

 Close Case

7.4 Solution Pattern 1: Case Data Archival

7.4.1 Context
All cases contain persistent data, documents, and folders that need to be maintained long
after the case is complete. Live case data is usually stored in different logical and physical
locations from completed case data. In order to bring proper closure, the system needs to
move this information to the proper locations.

7.4.2 Business Value

Logically separating live cases from completed cases allows for easier maintenance of the
system. Usually, live case data is accessed frequently and should utilize more expensive
and responsive storage media. Archived case data is usually accessed less frequently and
can be moved to less expensive storage. Archiving and securing the data ensures
adherence to retention, regulatory, and audit requirements.

7.4.3 Approach
Identify the data and documents associated with the case and determine the requirements
regarding auditing, retention, accessibility, security, and retrieval performance. The system
designer can take advantage of pre-built activities that assist in applying these requirements,
while others might require some degree of customization, depending on complexity.

7.4.4 Method
1. Identify the retention policy for case data. For example, you may be required to keep
all documents and data for a minimum period of 7 years from the time the case
completes but discard the case folder structure if it is not needed.

2. Identify a base location for archived data. For example, you might create a separate
cabinet that represents the year in which a case completed such that the retention
disposition for all data in the cabinet is the same.

3. Identify the format of the case archive. For example, you might place all documents
in an immutable virtual document, or you might render all documents to a single PDF
file.

7.4.5 Variations
• Allow for unexpected case termination.

xCP Pattern Library 52

 Close Case

7.5 Solution Pattern 2: Case Disposition

7.5.1 Context
When a case is closed, there is a result based upon the decisions taken during the review
state of a case lifecycle. The system must capture that result for reporting purposes, and
take actions based upon the final case judgment.

7.5.2 Business Value

Case management allows organizations to evaluate the merits of a case and make business
decisions based upon the outcome of the case. Disposing of the case involves implementing
the results, updating systems, and enabling reporting. In this way, case disposition enriches
the collective intelligence of the organization.

7.5.3 Approach
Identify the different case actions and outcomes that must be taken in order to officially close
the case. Ensure the reporting system knows the case disposition. Execute these actions as
necessary by updating internal or external systems. Communicate the disposition to the
interested parties.
For example, the defendant in a court trial has been found not guilty. Case closure requires
the following actions: updating the district attorney’s performance statistics, clearing the
defendant’s record, releasing the defendant from custody, and informing the public of the
verdict.

7.5.4 Method
1. The case enters disposition after the final decision has been taken and the case data
has been archived.

2. Update the external systems that store the data related to the case.

3. Update the systems that gather and report the outcomes of cases.

4. Update the internal status of the case to “closed.”

5. Close all internal artifacts associated with the case.

7.5.5 Variations
• Manual or physical actions may be required as part of disposition (for example,
releasing the defendant)

xCP Pattern Library 53

 Case Policies

8 Case Policies
8.1 Overview
Many solution patterns depend on establishing policies first. For example, the review
delegation patterns assume that policies for task delegation are defined.
Case Policies refers to decisions that govern the behavior of the case across all phases of
its lifecycle. In general, case policies are established at design time and enforced at run
time. Each type of case has its own policies, as appropriate. For example, policies important
for law enforcement are probably not relevant to opening a new account. In addition, policies
of the same type might be applicable in different parts of the same case. For example, a
case might use one assignment policy for document authoring, but a different assignment
policy for document reviewing.

8.2 Approach
When implementing case policy patterns, consider a series of questions about who, how,
when, and what. For example:
Who:
• Who has access to case information?

• Who is allowed to work on a case?

• Who performs a specific task?

How:
• How are case workers assigned to cases?

• How can case workers seek assistance or delegate tasks to other workers?

• How (under what circumstances) can a case be escalated?

• How do we track incremental versions of case documents?

When:
• When are alerts raised?

• When does a case require escalation?

• When does a case milestone occur, or a case progress to a new phase?

• When should cases be removed from archival records? (In general, are there
other policies pertaining to archiving?)

What:
• What cases (if any) require special handling?

• What actions, events or decisions are logged?

xCP Pattern Library 54

 Case Policies

• What quality metrics are tracked for case management?

These questions affect the design and implementation of Case Initiation, Case Work
(Manage, Review, and Communicate), and Case Closure. Effective system designers
consider these questions early in the planning, well before the other Solution Pattern
Categories are finalized.

8.3 Solution patterns in this category

There are five solution patterns included in the Case Policies category, as listed below:
1. Case Access Control
2. Performer Assignment

3. Information Access Control

4. Task Delegation & Reassignment

5. Business Logging

This is not a comprehensive list. With more experience, additional solution patterns in this
category might be identified.

xCP Pattern Library 55

 Case Policies

8.4 Solution Pattern 1: Case Access Control

8.4.1 Context
Some cases are linear and task oriented: one discrete task is performed after another.
However, other cases are more ad hoc. A case worker might do work as the need arises. Or
a group of people might share responsibility for working on the case. It is important to
determine which type of case is called for in the xCP application.

8.4.2 Business Value

If the case control policy is rigorously task oriented, then each user performs their work
within the context of tasks. If the case control policy is not task oriented, then it is necessary
to provide a “command center” that allows a case worker (or group of workers) to perform
work without the overhead of a task. This entails anticipating the functions they perform.
Some cases involve a blend of task-oriented and non-task-oriented work.

8.4.3 Approach
Consider the following questions:
Who can work on the case? Specify whether it is a single case worker or a group.
What information must be provided? This might include case data, access to folders
containing documents, an action log showing what has already happened in the case, and a
case comments tool in which to add descriptive notes.
What actions can the performer take? An example would be sending a message to the
case originator or importing documents into the case. Many of these functions can be
exposed as action buttons.

8.4.4 Method
1. Decide which type of case control is necessary by asking questions about the
sequence of tasks that must be done. If the answer is “well, it all depends…it varies
and is unpredictable,” then it is likely that the approach is not task oriented.

2. Describe the notion of a “command center” or “control panel” that provides the user a
workspace.

3. Determine which data and document management functions need to be performed in

the command center.

4. Identify the actions that users may need to take in the case.

5. Determine if the case is a group responsibility, where everyone in the group can see
everyone else’s work If so, then decide who will has access and with what rights..

8.4.5 Variations
• If a task is defined as a group responsibility and a user in that group claims the task,
then make sure that this task is removed from the inbox of all other workers in that
group.

xCP Pattern Library 56

 Case Policies

8.5 Solution pattern 2: Performer Assignment

8.5.1 Context
Throughout the life of a case, there can be several users performing different tasks in the
case. The assignment policy defines which performer is assigned to each task.

8.5.2 Business Value

The assignment of tasks to workers depends on a balance of several criteria:
• completing the tasks as efficiently as possible

• making sure that the person who is most appropriate to handle a task is assigned to
it

• distributing tasks fairly, so that no one is overworked

• minimizing the number of resources

• maintaining the required level of quality

Different organizations prioritize these criteria in different ways, depending on criteria such
as type of case, the nature of the work required, and the skills of their people. The goal of
case policies is to ensure that each organization achieves optimal assignments according to
their own criteria.

8.5.3 Approach
While trying to identify and define the different assignment policies, consider the following
questions:
Is the performer named? Certain tasks must be performed by a specific user, such as the
system owner, case owner, or a manager approving the work of a subordinate, while other
tasks can be performed by any user within a group.
Is the performer static or dynamic? Static performers are performers who never change. It
might be that a particular type of task is always done by one person, or a task is automated
(performed by a system). Dynamic performers are those that are determined by a rule. For
example, it might specify that a task should be performed by:
• the owner of a case

• the manager of a specific user

• any member of the underwriting group

Is there a backup defined? When defining an assignment policy with a named user (either
static or dynamic) consider what happens if that user is not available. This typically involves
specifying a backup performer.
Sample assignment policies
There are different types of assignment policies; for example, a task can be assigned to:

xCP Pattern Library 57

 Case Policies

• the case owner

• the manager of the case owner

• the system owner

• the support case queue

• the resident expert on insurance fraud

Try to limit the number of policies to a small and consistent set that still covers your needs. If
you have dynamic policies, make sure that any data necessary for the business rules are
available, either within the process or through integration with a directory service.

8.5.4 Method
Decide how work is assigned to performers. Options include the following:
1. The manager (or some other designated individual) assigns performers by name.
2. The performer of a task assigns the performer of the next task.
3. A work queue automatically assigns the next performer.
4. A business rule determines the next performer.
o Define the business rule that determines the performer. This could be the
manager of the performer of the previous activity, the manager for the current
account, or some calculation made by the business rule.

o Make sure that all the data needed for the calculation are available in the
process.

5. Determine if the performer assignment should be static or dynamic.

8.5.5 Variations
• Select the performer by invoking a rule in a business rules engine.

xCP Pattern Library 58

 Case Policies

8.6 Solution pattern 3: Information Access Control

8.6.1 Context
Information Access Control specifies the persons who can access a case and its contents,
the level of permissions associated with this access and the actions they can perform in the
case. Access control is generally based on the security group of the user and the state of the
case at the point in question.

8.6.2 Business Value

In many government and business applications, cases contain sensitive information.
Controlling access to information is needed to comply with legal requirements, and to protect
the privacy of clients.

8.6.3 Approach
Consider the following issues when defining access control policies:
What types of information require access control? Access control operates at different
levels:
• case

• application views within a case

• dashboards

• documents

• data

For example, a case worker might not be allowed to view dashboards that show
performance metrics for other case workers.
What are the relevant security groups? Users are commonly assigned to security groups
for the purpose of defining access control. Examples of security groups include case worker,
clerk, reviewer, manager, and auditor. The access control capabilities for the auditor group
would likely be different than for the clerk group.
What is the granularity of the access policy? Access control can apply to a group of
cases, to an entire case, to selected objects within the case, or to individual data fields within
a case object. For example, in an insurance claim handling system, medical records are
viewed only by medical personnel while claim documents are viewed by all claim handlers.
What level of permission is allowed? Some individuals have the right to view information
but not to change it. Other individuals have the right to delete documents from a case. It is
important to specify the level of permissions for each user or group of users. For example, a
clerk may be able to change certain data fields but might be limited in terms of what data to
view, while the auditor would have wide scope in viewing data but could not change it.
Is the access static or dynamic? Static access does not change with time or circumstance.
Dynamic access changes over time: for example, once a decision is made in a case, a case

xCP Pattern Library 59

 Case Policies

worker is no longer permitted to change certain data fields. Static access is easy to define,
maintain, and audit, but it might not always meet business needs.
When is access granted? This is closely related to the granularity and whether access is
static or dynamic. Access might be assigned to a case or an object within the case at design
time or at runtime. The latter can further depend on when the object is created, added to the
case, when a case worker is assigned to work on a case, or when an internal or external
event occurs.
How are exceptions handled? Sometimes access needs to be granted or restricted on an
individual basis. For instance, if a relative of a grants manager applies for a grant, then
access to that case might need to be restricted to prevent the grant manager from accessing
the case and influencing the decision. One should always strive to minimize the number of
exceptions, and it must be easy to audit any exceptions that arise.
Examples of access control policies
Below are common examples of access control policies:
• Case Based Access, in which all objects in the case have the same level of access
control.

• Security Classification Based Access, in which access to an individual object is

controlled by the security classification of that object (for example, “public” or
“confidential”).

• Confidential data fields, in which certain data fields in an object can be viewed only
by certain security roles.

8.6.4 Method
1. Define the security roles for the case (or group of cases).

2. Identify any sensitive case information, such as application views, dashboards,

documents, and data.

3. Using a table, map the sensitive information to the security roles and specify the
appropriate permission levels for each.

4. Specify when and how access is granted.

5. Identify documents that are hidden from certain users (in some cases the users must
not be able to look inside these documents; in other cases the users must not even
be aware of the existence of these documents).

6. Ensure that all information access is auditable

xCP Pattern Library 60

 Case Policies

Following is a simple example of the table suggested in item 5:

Information Resource Sensitivity Security Role Access Permission

Health Claim Name of provider, Claims worker Read or Edit

diagnosis, and treatment

Customer Account Personal information of Claims worker, Read only

Details value for identify theft Claims manager

Customer Medical Controlled by HIPAA Medical expert Read only

Records regulations
Claims worker, No access
Claims manager

Performance Information about case Case executive Read only

Dashboard workers

8.6.5 Variations
• Define procedures for auditing
• Define procedures for exception handling

xCP Pattern Library 61

 Case Policies

8.7 Solution pattern 4: Task Delegation & Reassignment

8.7.1 Context
In some cases, a performer needs the assistance of other resources to complete a task. In
other cases, a manager might decide to reassign a task to a different performer.

8.7.2 Business Value

Delegation is an important tool for a manager. It allows the manager to increase the
productivity of an organization by transferring work from one resource to another; for
example, when the original case worker lacks the necessary skills or is not available at the
required time. It also allows a case worker to ask an expert for help handling a particular
aspect of the work. For example, a complex insurance claim may need the judgment of an
underwriter.

8.7.3 Approach
When implementing task delegation, consider the following:
Who is allowed to delegate work? The delegation policy must determine if no one is
allowed to delegate work, if only certain roles can delegate, or if anyone can delegate.
To whom can a task be delegated? This question is closely coupled to the case
assignment policy. Delegation involves a transfer of responsibility, but the person doing the
delegation might be restricted in terms of to whom they can delegate a task. A manager
might be allowed to delegate work only to her subordinates, while an individual contributor
might only be able to delegate to his peers or to a designated group of people.
Is feedback required? Since delegation is a transfer of responsibility to another person, a
key consideration is who decides if that responsibility has been properly fulfilled or not. Is it
the person delegating or the person being delegated to? If the former case, the delegate
must report back, while in the latter case the person completes the task and the case
continues. The most common policy is delegation with feedback, which gives the
responsibility to the person doing the delegation (that is, the one who was originally assigned
the task). This policy difference is illustrated in the following two process patterns.

xCP Pattern Library 62

 Case Policies

Figure 8–1 Delegation without feedback Figure 8–2 Delegation with feedback

Does the same delegation policy apply to all tasks? Within case management solutions
there are often multiple delegation policies, because certain tasks cannot be delegated (for
example, a decision) and the restrictions on further delegation and feedback might also vary
depending on the nature of the task.

8.7.4 Method
1. Decide whether to allow task delegation.

2. Decide which tasks, if any, can be delegated.

3. Decide to whom the tasks can be delegated.

4. Specify which tasks can be delegated with feedback, and which tasks can be
delegated without feedback.

8.7.5 Variations
• Can a task be successively delegated? This might occur if the task was delegated to
a performer who was unable to complete it properly, and therefore needed to
delegate to a different performer.
• Can the task be delegated further? For instance, a manager might delegate the
review of a document to his employee and that employee might want to delegate the
review of the graphics to a graphic designer. The mandate given to the employee by
the manager might or might not allow this type of nested delegation.
• Address the situation in which a task is delegated but is never performed. This is
most relevant to the delegation without feedback pattern.

xCP Pattern Library 63

 Case Policies

8.8 Solution pattern 5: Business Logging

8.8.1 Context
A business log is similar to an audit trail, but it is focused on information of business interest,
such as case actions, events and decisions. The business log should be easily accessible by
authorized business users. Most business logs are created manually by users entering
comments; some business logs are generated automatically by the system, based on
specific events. Other business logs will contain a combination of system-generated and
human-entered information.

8.8.2 Business Value

For many types of cases, having a record of significant events and actions is useful. It might
also be a legal requirement. For example, court case management has a requirement for a
document called a “docket” that records every important action in the case, such as a motion
filed, a hearing scheduled, or a judge’s decision on a motion. The information in the business
log must be recorded in a way that allows all authorized users to access it easily.
In investigative case management, an electronic notebook may be used to collect the
comments of various police officers as the case progresses (for example, “the victim was
visibly distressed”).

8.8.3 Approach
When defining a business log policy for a case management solution, consider the following.
What events should be logged? For example, it might be important to log all incoming
information, all phone calls, and all decisions in the case.
What information should be logged? This refers to the attributes associated with events.
For example:
• event identifier

• date the event occurred

• description of the event

• case worker who was proximate to the event

A business log can be as complex as business requirements dictate.

How are events created? Ideally, events are logged automatically as part of normal case
processing. If the events occur outside of the case process, this might not be possible. For
instance, if a client calls in to a call center, a case worker might have to enter notes in the
corresponding case, recording the key facts about the phone call. However, if the same
client submits a web form, the system might automatically add that event to the case.
Can users create entries into the log? As mentioned above, some business logs are
designed to capture comments from system users while others simply capture events
automatically.

xCP Pattern Library 64

 Case Policies

What is the access policy of the business log? One issue of policy is which business
users should have access to the business log. Another important aspect of the business log
is whether or not it is editable. For example, can an error detected in the log be corrected? It
generally is not permissible to delete events from the business log, but that is also a matter
of policy.

8.8.4 Method
1. Define the event types in the case that need to be logged.

2. Decide if users will enter comments into the log, the system will record events
automatically, or both.

3. Specify the set of attributes that is associated with each event.

4. Specify each activity that automatically triggers event logging

5. Define the access policy for the business log

8.8.5 Variations
• Enable authorized business users to add comments to the business log, but not edit
the automatic entries.

xCP Pattern Library 65

 Data Model

9 Data Model
9.1 Category Overview
Case management solutions require facts, observations, statistics, measurements, and
items of information that allow users or systems to draw conclusions about a case
throughout its lifecycle. Without this information, a case cannot be defined, much less
executed.
Data can be structured, such as XML files or database tables, or unstructured, such as
images or video files. The definition of how, where, and for what duration this data is stored
will have consequences throughout the solution. Moreover, changes to the data model made
in later stages of a project will generally may require rework of those components that
depend on the data definition. It is important to understand how data are produced and
consumed by a case and to define the data model as fully as possible early in the project
lifecycle.

9.2 Approach
The data model is a holistic representation of all information needed to originate, execute,
and maintain a historically accurate representation of a case once it is completed.
When designing a data model, consider the following:
What content is required for case workers and reviewers to make appropriate
decisions? Case management systems require content to enable case work, review, and
completion. Examples of content include:
• Office Documents

• Audio/Video

• Images

• Emails

What metadata is needed to describe content? Metadata is structured data that describes
content. It enables searching, reporting, and system-to-system interaction. For example, the
following metadata could be used to describe a contract:
• Contract ID

• Client ID

• Contract Start Date

• Contract End Date

Are there other entities needed by the process? Metadata can also describe entities that
contain no content. Examples of these entities include:
• Person

xCP Pattern Library 66

 Data Model

• Place

• Application

What data is needed for systems to make appropriate decisions? Some data are not
consumed by end-users, but instead enable systems to make decisions as the case
executes. Examples include:
• threshold levels that trigger alerts

• data values that are used in making routing decisions

What is the origin of case data? Data and content can originate from various sources, and
influence design decisions, determine the system of record, and affect security
requirements. Examples include:
• information ingested from external sources, such as incoming email

• data entered by a case worker

• static variables set on a case

• application-specific or environment-specific variables

How will users, applications, and other systems interact with case data? This helps
drive requirements for other aspects of the application, particularly its interfaces with external
systems. Examples include:
• a case worker needs to create a MS Word document from a template

• a case reviewer needs to annotate a document in a web browser

• an external system needs to ingest certain data fields from an approved application

When is information needed? This will help define security, audit, retention, and
persistence requirements. Examples include:
• a case worker needs access to all case documents until the case completes

• compliance requirements call for case documents to be stored for 7 years after the
case completes

• data published to an external system must be discarded upon case completion

Where should information be stored? Based on the nature of the data, there can be
several storage and format options. This decision might be constrained based on how that
data must be produced or consumed. Examples include:
• External database tables

• File storage

• Regulations concerning information privacy

xCP Pattern Library 67

 Data Model

Example:
Consider a grant application process in which a formal review is required whenever the
funding amount requested is greater than $10,000.
• Q: What content is required for case workers and reviewers?

A: The grant application document

• Q: What metadata is needed to describe content?

A: The funding amount; that is, the amount requested in the grant application
• Q: What data is needed for systems to make appropriate decisions?

The threshold amount ($10,000)

• Q: What is the origin of the case data?

A: The grant application documents are submitted externally by applicants. Business

requirements dictate the threshold amount.
• Q: How will users, applications, and other systems interact with case data?

A: Grant managers must be able to view the application electronically in a web

browser and annotate the document. The case management system needs to
retrieve the threshold amount.
• Q: When is information needed?

A: The grant application is needed during case review and is archived for compliance
reasons. Upon completion of the case, the threshold amount is no longer needed and
is discarded.
• Q: Where is information stored?

A: The grant application is stored in a case folder and written to disk, with its
metadata stored in a database. The threshold amount is stored in a database.
• Q: What relationships exist between the case and the data?

A: A case can include only one grant application. The persistent amount of the grant
must be compared to the transient threshold amount.
In this example, the data model could be represented as follows.

Figure 9–1 Data model example

xCP Pattern Library 68

 Data Model

9.3 Solution patterns in this category

There are three solution patterns within the Data Modelling category:
1. Model Persistent Process Data

2. Model Transient Process Data

3. Model Data Relationships

xCP Pattern Library 69

 Data Model

9.4 Solution pattern 1: Model Persistent Process Data

9.4.1 Context
Business entities, such as customer, order, invoice, and product, are modelled as persistent
data. This persistent data is consumed by business processes. This data is ingested,
created, generated and transformed by the business processes. Its output is preserved after
a case is completed.

9.4.2 Business Value

Structured data, as well as unstructured content (such as documents, images, multimedia
files) is a critical element in case processing. It depends upon the core information model
with which organizations conduct their operations, even after the case is complete. This is
the “persistent data model.” An example is the folder taxonomy in which that content is
organized for case execution. This hierarchy is valuable and needs to be preserved upon
case completion.

9.4.3 Approach
The basic approach is to identify the content, metadata, and case information that is
consumed (and created) during the case lifecycle and which, upon completion of the case, is
retained for future use.

9.4.4 Method
1. Define and model persistent entities. These data entities should accurately mirror
real business entities (contract, order, invoice, etc.).

2. For each entity, specify its attributes and their types.

3. Define and model the case folder structure, its metadata, and logical storage
locations.

4. Identify documents and other unstructured data that are necessary for case workers
to perform their tasks.

a. Specify the necessary metadata for each piece of unstructured content.

b. Model the content in Documentum as custom object types.

c. Consolidate and normalize the data model as appropriate.

9.5 Solution pattern 2: Model Transient Process Data

9.5.1 Context
Some data that are important in the case lifecycle are not needed once the case is complete.
These data elements are “transient process data.” They are kept in temporary storage and
discarded after the case completes. An example of transient process data is a counter, a
data structure that keeps track of the number of items in a list, such as a list of items
received from another system. Transitory data, even though it is not maintained in persistent

xCP Pattern Library 70

 Data Model

storage, is monitored by the Business Activity Monitor. See the chapter in this document on
Monitoring.

9.5.2 Business Value

There are several reasons for distinguishing between persistent and transitory data. First of
all, separating data used only during process execution from persistent data allows for
streamlined maintenance of the underlying storage structures. Second, it eliminates the
storage of data that comes from external systems of record and might become outdated.
Finally, there are performance implications associated with the way in which data is stored.

9.5.3 Approach
The basic approach is to look for data elements that are needed temporarily, during process
execution. Do not expect to identify all transitory data elements in the requirements phase.
This task will be completed during the design phase, when these elements will be mapped
into “Process Variables.”

9.5.4 Method
For each case:
1. Specify the data elements that are used for:

a) transition decisions
b) inter-process communication
c) inbound correlation events
d) environment-specific variables (i.e. is a the document generation system is
enabled)
e) communication with external systems
f) counters
g) variables that an Administrator can manually update mid-process (See
Managing Process Parameters in the Process Builder User Guide Release
6.6, page 61)
2. Map the elements into the appropriate process variables

3. Consolidate and normalize the data model as appropriate

4. Assign the process variables to the appropriate process templates

xCP Pattern Library 71

 Data Model

9.6 Solution pattern 3: Model Data Relationships

9.6.1 Context
Data entities will often be related to other data entities. It is important to understand these
relationships when building solutions.

Example 1: Composition Relationships

Figure 9–2 Data relationships

In this example, the cardinality of the relationship is 1-1. One customer has a unique
address. However, we may want to allow a customer to have multiple addresses (for
example, to include a summer home). In that case, the relationship would be 1-n. If the
household can contain several customers, then the cardinality would be modelled as n-n. In
general, the modelling is based on certain assumptions about the domain.

Example 2: Inheritance Relations

A Case-Based Application is a kind of Business Application (that is, “Case-Based
Application” inherits from “Business Application”).
Example 3: “Uses“ Relationship
An employee uses a Case-Based Application.

9.6.2 Business Value

Reusing and repurposing data allows organizations to maintain the integrity of their data
sources, while minimizing the cost of maintaining that data.

9.6.3 Approach
Identify and model the semantics of the entities and other data.
• Direct relationships – Entity Person of type Lawyer is assigned to a case

• Indirect relationships – Entity document of type docket is located in the case folder

xCP Pattern Library 72

 Data Model

9.6.4 Method
Given the data model:
1. Identify a relationship. Then determine

a. Cardinality

i. 1-1 (customer to address)

ii. 1-many (customer to order)

iii. many-many (order to product)

b. Hierarchy and Direction

i. Are the related entities describing a master object (master to detail)?

ii. Is the relationship hierarchical (parent to child)?

c. Recursion: Can an object relate to itself?

d. Ordering: Is the order of objects related to a master object important in a

master-detail relationship

2. Create an entity relationship diagram (ERD)

3. Evaluate the design criteria and adjust as necessary

a. Performance: ability to construct efficient queries

b. Space consumption

c. Deployment and referential integrity: when moving from one system to

another, are the relationships maintained?

4. Determine the implementation approach for each relationship

9.6.5 Variations
• Use a UML model to show data entities and relationships.

xCP Pattern Library 73

 External Interfaces

10 External Interfaces
10.1 Overview
Cases rarely exist in isolation from other systems and data in the enterprise (or beyond the
enterprise). There are often several points in the life of a case where interaction with external
systems occurs. For example:
• The case is initiated by an external user. An external client might submit a form from
a website, send an email to a case mailbox, or mail a paper form that is scanned and
ingested.

• The case is initiated by an automated system by invoking a web service.

• During the life of a case, validation rules require access to an external database.

• When a task is assigned to a case worker, an assignment policy requires the name
of the user’s manager from the corporate directory for subsequent approval tasks.

• During case closure the case updates back office systems. For example, the case
sends account opening details to a CRM system.

Note that there is considerable overlap between External Integration and other solution
pattern categories; for example, sending an email is a communications function as well as a
form of external integration.

10.2 Approach
When designing integration points for a case management solution, consider the following:
What is the direction of the contact? There are four possibilities:
• incoming, unsolicited (i.e., not a response)
• incoming, response
• outgoing, response
• outgoing, unsolicited (i.e., not a response)

What is the nature of the interaction? Consider three types of interaction:

• Exchange of structured data

• Exchange of unstructured data (that is, content such as images and text documents).

• Service request or invocation, to perform some form of action

These types are not mutually exclusive. For example, a request might involve acting on
content, such as a request to render a MS Word document into PDF format.
What is the timing of the interaction? Consider three types of interaction protocols:

xCP Pattern Library 74

 External Interfaces

• On demand. On-demand integration means “invoked when needed.” The interaction

can be synchronous (that is, the process waits for a response) or asynchronous (that
is, the process continues without waiting for a response). Typical examples of on-
demand interaction protocols are web service calls and external database queries.

• Scheduled. A scheduled integration pushes or pulls data periodically, at a regular

interval. A typical example is synchronizing a group from a directory service.

• Publish/Subscribe. In this mode of interaction, a case subscribes to messages

published by an external data feed. For example, the external data feed might post
significant stock market changes, to which the case could react.

10.3 Solution patterns in this category

There are four solution patterns in this category.
• Data Integration

• Content Integration

• Outbound Service Requests

• Inbound Service Requests

xCP Pattern Library 75

 External Interfaces

10.4 Solution pattern 1: Content Integration

10.4.1 Context
Sometimes it is necessary to import content produced outside of the case. At other times, it
is necessary to publish content that exists within a case to an external system.

10.4.2 Business Value

Case-based applications operate in a business environment in which content can be created
inside the case or outside the case. It is critical that the case-based application can
exchange documents, images, and other types of content with its environment.

10.4.3 Approach
Consider the following questions when trying to identify and define content integration
needs:
What is the direction (incoming/outgoing) of the communication? Content can either be
sent out from the case (system) or received by the case (system).
What is the communication mechanism or protocol? There are many ways of
exchanging content between systems. For example:
• web-based submissions (HTTP)

• file exchanges (FTP)

• the local file system

• email

• facsimile

• web services

• physical posting of a paper document (requiring a scanning or printing solution)

What is the content being communicated? It can be a single document or multiple

documents.
What is the format of the content? A case document written in MS Word might need to be
transformed into PDF format before being sent to the external destination.
How is content be correlated to the case? Incoming documents are either used to start a
new case or else they need to be correlated to an existing case. This means that the
incoming document must be marked with a case ID or similar identifier to indicate the case
with which it is associated.
Who is the recipient of the content? The recipient of the content can be a system, a
specific user, or a set of users (as in an email or a post).
When is the content communicated? In some situations, content is received on demand,
as in a filing to institute a civil lawsuit. In other situations, legal restrictions require that

xCP Pattern Library 76

 External Interfaces

content be sent out by a certain date. The solution must reflect the time constraints of the
interaction.

10.4.4 Method
1. Determine the direction of the communication.

2. Define the communication protocol.

3. Specify the content to be communicated and its format.

4. If necessary, define the case identifier for the content.

5. If necessary, define the recipient of the content.

6. Specify when the content is to be sent or received.

xCP Pattern Library 77

 External Interfaces

10.5 Solution pattern 2: Data Integration

10.5.1 Context
Sometimes it is necessary to retrieve from external systems data used in the processing of a
case. At other times, it is necessary to update an external system with data produced by the
case. Both involve data integration.

10.5.2 Business Value

In many enterprises, certain systems and databases are designed as systems of record.
They contain the official data and are generally outside the scope of the case. That is, the
case may read, consume, modify and transform this data, but its ultimate destination is with
these external systems. A good example of this is an enterprise’s organization data, which
often resides in an enterprise directory system.

10.5.3 Approach
Consider the following questions when trying to identify and define the data integration for
your solution:
What is the nature of the data? The data could be of various types: customer data, product
data, data from industry databases, or data stored in systems of record.
What is the direction (incoming/outgoing) of the integration? As with content
integration, data can flow into or out of the case. A common pattern is for data to flow into
the case, be consumed and transformed by the case, and then flow from the case to the
external system.
When is the data communicated? The data might be sent or received based on an explicit
request by a case manager, or it might be received automatically (at any time).
What is the mechanism or protocol of communication? Data can be sent and received
using a variety of mechanisms. For example:
• database read or write

• web forms (HTTP), in which a user submits data from a form on a website

• web services, an automated application-to-application mechanism

10.5.4 Method
1. Determine the direction of the communication.

2. Define the communication protocol.

3. Define the nature of the data.

4. Specify the content to be communicated and its format.

xCP Pattern Library 78

 External Interfaces

10.6 Solution pattern 3: Outbound Service Requests

10.6.1 Context
In the outbound pattern, the case requests external services. For example, it might request
that SAP perform a calculation and return the results. or it might request currency conversion
from Kronor to Euros.

10.6.2 Business Value

Outbound service requests enable the case to utilize services provided by systems inside or
outside of the enterprise. They also enable a case to take advantage of a Service Oriented
Architecture, which offers the benefits of loose coupling and flexibility.

10.6.3 Approach
Consider the following questions when identifying outbound service requests applicable to
your solution:
What is the mechanism or protocol of communication? The service can be invoked
using:
• web services

• HTTP

• a low-level API call

• an external program

What is the interface of the service? The interface of the service is defined by the service
name (or URL), parameter list, and the result produced. For example, consider a method,
openNewAccount, which is exposed by a back office system. This method might take a
complex parameter structure specifying the individual to open the account and the type of
account. It would then return the account ID of the newly constructed account.
When is the service invoked? The service might be invoked on demand when a case
worker seeks to change an account type. Alternatively, the case might send periodic updates
to another system about the progress of the case. The service might be invoked only when
an event happens in the case (for example, when the case enters the case closing phase).
Is the result of the invocation synchronous or asynchronous? Regardless of the
direction of the method invocation, the invocation can be either synchronous (a response is
produced immediately) or asynchronous (the response is delayed and either pushed back
later or polled for).

10.6.4 Method
1. Specify the mechanism of communication.

2. Define the interface of the service the solution exposes.

3. Specify when the service can be invoked.

xCP Pattern Library 79

 External Interfaces

4. Specify the synchronicity of the service and, if it is asynchronous, specify how the
results are fetched/received.

xCP Pattern Library 80

 External Interfaces

10.7 Solution pattern 4: Inbound Service Requests

10.7.1 Context
External systems sometimes need to control certain aspects of a case (for example, starting
a new case automatically when a web form is submitted). Inbound service requests specify
how external systems or external clients can direct and control case processing.

10.7.2 Business Value

Some customers will prefer to keep their familiar existing systems and user interfaces but
use xCP for case-related services. Inbound service requests enable this pattern of use. They
ensure that the case management system presents its functionality as a set of services,
which fits well with an enterprise-wide Service Oriented Architecture.

10.7.3 Approach
Consider the following questions when identifying inbound service requests that are
applicable to your solution:
What is the mechanism or protocol of communication? The service can be invoked
using:
• web services

• HTTP

• a low-level API call

• an external program

• email sent to a functional mail box

What is the interface of the service? The interface of the service is defined by the method
name (or URL), parameter list, and the result produced. For instance, a service
“startCaseWithDocument” exposed by a case management solution might take a single
parameter (the document) and return the case ID of the newly constructed case.
When is the method invoked? One possibility is that the service can be invoked on
demand at any time by another system. Alternatively, an existing case process might have to
wait in a suspended mode until a service is invoked. The service might only be available at
certain times.
Is the result of the invocation synchronous or asynchronous? Regardless of the
direction of the service invocation, the invocation can be either synchronous (a response is
produced immediately) or asynchronous (the response is delayed and either pushed back
later or polled for).

10.7.4 Method
1. Specify the mechanism of communication.

2. Define the interface of the service that the solution exposes.

xCP Pattern Library 81

 External Interfaces

3. Specify when the service can be invoked.

4. Specify the synchronicity of the service; if it is asynchronous, specify how the results
are fetched/received.

xCP Pattern Library 82

 Monitoring

11 Monitoring
11.1 Category Overview
Case Monitoring gives workers, managers and executives visibility into cases, allows them
to see patterns and assess trends, and to take corrective actions. The benefits of business
activity monitoring (BAM) include faster response time to problems, better decision making,
and improved service to customers and partners.

11.2 Approach
When defining how the solution will be monitored, consider the following:
What real-time information about executing processes is needed? Typically, this
includes activities that have completed, the activity that is currently executing, the durations
of activities, the names of performers, and so forth.
Who needs this information? This could be an operational manager or a group of
operational managers, a case worker, or a business executive. Their responsibility is to
ensure that the processes are running smoothly and achieving the expected business
outcomes.
What types of historical reports are needed? Since the number of completed individual
processes can be very large, it is common to provide summary reports that aggregate this
information. For example, a summary report might show the number of new insurance
claims grouped by month, geographical location, or type.
How will this information be presented? Normally, summary reports are organized into
related groups and presented in dashboards. Some dashboards will be targeted at
operational managers, some at process owners, and others at line-of-business executives.
Individual reports can also be embedded in the workspaces of case workers.
What should happen if Service Level Agreements or Key Performance Indicators are
not met? The monitoring subsystem provides the ability to generate alerts based on various
conditions. For example, if an automobile claim takes more than five days to adjudicate, an
alert is raised and sent to the responsible claims supervisor.
Monitoring collects real-time information from executing business processes. This includes
information about the:
• activities in the process (for example, when each activity start and ends)

• performers of activities (for example, who performs the activities – both users and
queues)

• business data managed by activities (for example, order number, date of order, items
ordered)

11.3 Solution patterns in this category

There are four solution patterns defined within the Monitoring Pattern Category:
1. Current Activity Monitoring
xCP Pattern Library 83
 Monitoring

2. Historical Reporting

3. Management by Exception

4. Publishing

xCP Pattern Library 84

 Monitoring

11.4 Solution pattern 1: Current Activity Monitoring

11.4.1 Context
Assume that a process instance is in progress. Some activities may have completed while
others have yet to occur. Instance Monitoring allows you to:
1. see where the process instance is at this moment (which activity is executing)

2. understand the progression (path) of the process up to this point

11.4.2 Business Value

Instance Monitoring enables an operational manager to determine the current status of a
specific ongoing case or process instance. For example, it allows the manager to answer the
question: “What is the status of Customer X’s Order of January 22?” It also allows her to
estimate when the order will be completed. If the order has been delayed, it helps to
diagnose the problem.

11.4.3 Approach
A dashboard displays a list of in-flight processes. When the user selects a specific instance,
the process diagram shows the current state of the instance, with the current activity
indicated.

11.4.4 Method
1. Create a dashboard called “Instance Monitoring” (or something equivalent but more
meaningful for the business, like “Current Loans”).

2. Add a Process Instance list and a Process Diagram report to the dashboard.

3. Create a drilldown relationship between the Process Instance list and the Process
Diagram (meaning that the Process Diagram you see depends on the Process
Instance the user selects).

4. Decide if users want to filter the report results to their own department or region.

5. If you are monitoring a case that contains many processes, it might not be
convenient or helpful to monitor each and every case. In this situation, you need to
create a special BAM Control Flow to represent the progress of the case. This single
process collects significant events from the other processes, thereby allowing the
user to see them displayed in a single process diagram.

11.4.5 Variations
• Include a gauge report in the dashboard that shows the time elapsed (for the
specific case or process instance). You could also add a dial-gauge that shows
the average duration (for example, over a day, week, or month).
• For the current activity, provide a report detailing the performer, start time,
duration, and possibly the business data.

xCP Pattern Library 85

 Monitoring

• Provide a report that shows the same information for all completed activities.

Figure 11–1 Process instance dashboard

xCP Pattern Library 86

 Monitoring

11.5 Solution pattern 2: Historical Reporting

11.5.1 Context
When process instances finish, it is useful to summarize performance in the form of
analytical reports. These reports are displayed in dashboards.

11.5.2 Business Value

Summary Reports provide insight into operational results and performance. There are four
main types:
1. Classification Reports – for example, how many orders were received from gold,
silver, and bronze customers (pie chart), how many orders were received from each
state (bar chart), or what was the average time for order fulfillment for each sales
region (bar chart)?

2. Detail Reports – for example, for each order received this week, show the date of
the order, the name of the customer, the customer’s state, the products ordered, the
branch office responsible, and the total amount of the order.

3. Performer Reports – for example, how many cases is each performer working on,
what is the average case duration for that performer, and what is the total dollar
value of all orders for that performer (for example, over the last week)?

4. Trend Reports – for example, how many loan applications have been received each
week for the preceding month, and what is the average duration of the loan process
each month for the last year?

With this information, managers can accurately measure the efficiency of people and
processes, correct operational problems, and help performers succeed. Executives can
analyze costs, determine when to increase or decrease the workforce, and decide when to
restructure the underlying processes.

11.5.3 Approach
Plan the dashboards, based on the needs of the operational managers and other dashboard
users. Create the required reports and insert them in the appropriate dashboards.

11.5.4 Method
Proceed as follows:
1. Identify a set of potential dashboard users. This might include executives, line of
business managers, IT professionals, operational managers, and business analysts.

2. Interview the users to understand their reporting needs. Describe the four types of
summary report (described above) and ask what information they need.

3. Determine the time filter for each report (for example, data grouped by day, week, or
month).

xCP Pattern Library 87

 Monitoring

4. Based on feedback from interviews, create prototype dashboards and hold another
review. For each report, discuss why this information is important and how it will be
used.

5. Periodically reconvene the users and assess the effectiveness of the dashboards.
Make any necessary changes, adding new reports, deleting reports, or changing the
content of reports.

Be careful about the number of reports per page. Do not include too many reports in a
dashboard, as usability may suffer.

11.5.5 Variations
• Reports can include the ability to click and drill down for more details. For example,
the user can click a segment in a pie chart and display a bar chart that provides the
next level of detail.
• Analytical reports can be inserted in the worker portal of individual task performers.
The information in these singleton reports is relevant to the tasks of the worker and
throws light on the task at hand. For example, the report might show the number of
orders that a customer has made over the last year, together with the date and
amount of each order. This provides context for the task performer.
• Reporting with data in external systems

xCP Pattern Library 88

 Monitoring

11.6 Solution pattern 3: Management by Exception

11.6.1 Context
Management by exception involves the following functions:
1. Noticing that something exceptional has occurred, generally a weakness or
operational problem. For example, a certain process is not meeting its Service Level
Agreement.

2. Identifying the root cause of the problem, which could be a resource problem, a data
problem, a process problem, or a performer problem.

3. Taking appropriate corrective action, for example, to add more resources or change
the process.

11.6.2 Business Value

Managers want to be informed when a problem occurs, and the earlier the better. Problems
that are caught early cost less to correct. Even better is to be informed before the problem
has occurred, based upon the past performance of a process.

11.6.3 Approach
1. Notice an exceptional situation. You might be able to detect a problem from a
summary report. For example, one branch office might have a much longer cycle
time than the others. You can also define alerts that indicate in real time a problem or
exceptional situation. These alerts are displayed in a dashboard.

2. Identify the root cause. This is generally done by reviewing a report to understand the
details. You might have to look at multiple reports to understand the full picture.

3. Take corrective action. When an alert occurs, an email is sent out to the responsible
parties. Alternatively, the alert can trigger a remediation process.

Note: Alerts can be based on a variety of parameters, including:

• process duration (for example, if the duration of the ongoing process takes more than
8 hours, generate an alert)

• activity duration

• average process duration

• business data, such as the number of instances completed in a unit of time, or

calculated values, such as the dollar value of an order (for example, if an order
amount > $1M, generate an alert).

11.6.4 Method
1. Define SLAs: these are the thresholds set by business for alerts.

2. Based on the SLAs, define each alert and set its severity level.

xCP Pattern Library 89

 Monitoring

3. For each alert, decide which users (by name) who should be alerted.

4. Define the alert resolution process. What must they do in order to close the alerts?

5. Create one or more alert reports and insert them into the appropriate dashboards.

11.6.5 Variations
• Add an Alert List Report to the Instance Monitoring dashboard
• An alert can automatically trigger a remediation business process. This process
would typically define the steps needed to investigate and resolve the alert
condition.

xCP Pattern Library 90

 Monitoring

11.7 Solution pattern 4: Publishing

11.7.1 Context
Publishing is the means by which BAM reports are conveyed to the consumers of these
reports.

11.7.2 Business Value

Reports on current activities or historical metrics must be communicated in an appropriate
way to case workers, supervisors, and managers. This allows these individuals to
understand the state of the business, make better decisions, and take corrective actions
when needed.

11.7.3 Approach
Publishing is based on the needs of the audience. Understand the audience for monitoring
reports and design a communication mechanism that best meets their needs. Different types
of user will have different needs. For example:
• An executive might only be interested in historical business metrics.
• A case supervisor might want to know the status of the work queues in her group.
• An operational manager might need to know what is happening at the moment.
• A heads-down case worker might need only a report that shows how many of his
cases are new, how many have been screened, and how many need screening.

11.7.4 Method
Proceed as follows:
1. Identify the users who require monitoring reports.

2. Interview the users to determine what type of monitoring reports they need.

3. Decide if it is most appropriate to use dashboards as the means of communication.

Which dashboards will each individual need? What should each dashboard be
called?

4. Determine the reports that each dashboard will contain. Create mockups of the
dashboard. Review with the target users.

5. Decide if individual reports embedded in a user workspace are more appropriate for
a different group of target users. Which reports do these users need and in what
context? For example, the case worker may need to see a report on order history for
the customer they are servicing.

11.7.5 Variations
• Create a batch job that generates a set of reports and send them to users via email.
• Embed selected BAM reports in a custom web application.

xCP Pattern Library 91