xCP Pattern Library 2
TABLE OF CONTENTS
1 EXECUTIVE SUMMARY ...............................................................................................3
2 BASIC CONCEPTS.......................................................................................................5
3 INITIATE CASE...........................................................................................................11
5 REVIEW ......................................................................................................................30
7 CLOSE CASE ............................................................................................................. 50
8 CASE POLICIES ......................................................................................................... 54
9 DATA MODEL............................................................................................................. 66
10 EXTERNAL INTERFACES ...................................................................................... 74
xCP Pattern Library 3
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.
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.
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 4
important, but outside the scope of this document. The following are a few methodological
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.
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 5
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
2.2 The History of Patterns
The idea of patterns was introduced for city planning by Christopher Alexander1
A typical pattern approach allows great flexibility and variations (for example, highways are
planned with three-leaf and four-leaf interchanges).
. 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.
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
See for example “A Timeless Way of Building” or “A Pattern Language” (1977)
xCP Pattern Library 6
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.
At a high level, the approach is as follows:
1. Divide the application into high-level functional modules (called solution pattern
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
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
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 Case2
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 7
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.
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:
Figure 2–2 Solution patterns in the Monitoring category
SolutionPattern 1 CurrentActivity
Solution Pattern 2 Historical Reports
Solution Pattern 3 ManagingbyException
Solution Pattern 4 PublishingMonitoring
xCP Pattern Library 8
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
• 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:
• Examples of use
• Related patterns
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 9
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
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.
Look & Feel
User-Oriented Process-Oriented Data-Oriented Operational
Solution Pattern Category
Design Pattern Category 2Design Pattern Category 1
xCP Pattern Library 10
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
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
Initiate process from document received via SMTP
xCP Pattern Library 11
3 Initiate Case
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.
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 12
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
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
• 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 13
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
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.
Identify the conditions, data, and mechanisms by which a person or system can establish a
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
• Log all initiation attempts and identify those that were successful and unsuccessful.
xCP Pattern Library 14
• 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 15
3.5 Solution pattern 2: Validate Case
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.
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.
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.
• 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 16
3.6 Solution pattern 3: Set Up Case
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.
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.
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).
• 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
xCP Pattern Library 17
3.7 Solution pattern 4: Accept Case
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.
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
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
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
• 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
xCP Pattern Library 18
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.
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.
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 19
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 20
4.4 Solution pattern 1: View Case
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.
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 21
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.
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.
• 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 22
4.5 Solution Pattern 2: Manage Case Data
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.
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
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,
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 23
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.
• 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 24
Solution pattern 3: Manage Case Content
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
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.
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
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 25
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.
• 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
• 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 26
4.6 Solution pattern 4: Find Case Data
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.
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 27
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.
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)
• 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 28
4.7 Solution pattern 5: Perform Case Actions
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.
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 29
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.
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.
• 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 30
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
• 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
o An escalation policy determines what happens when a reviewer does not
perform the review on time.
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 31
• 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
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
• 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 32
a sufficient level of quality has been reached. Examples of the effect a review can have on a
• 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
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
• 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
• 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 33
5.4 Solution Pattern 1: Sequential Review
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.
The trivial sequential review involves only one review activity and is captured by the
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:
Figure 5–2 Complex sequential review
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 34
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?
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.
188.8.131.52 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
184.108.40.206 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 35
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.
220.127.116.11 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
xCP Pattern Library 36
Figure 5–5 Sequential review with delegation
The issues concerning patterns of delegation are addressed in the Case Policy category.
xCP Pattern Library 37
5.5 Solution Pattern 2: Parallel Review
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.
The essence of the parallel review is illustrated by the following process fragment:
Figure 5–6 Parallel review
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 38
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?
The variations of the parallel review are fundamentally the same as the variations for the
18.104.22.168 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.
22.214.171.124 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.
126.96.36.199 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 39
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.
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
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
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 40
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 41
6.3 Solution Pattern 1: Send External Communication
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,
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.
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.
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 42
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 44
• Send a reply to received external communications.
• Generate custom documents with barcodes.
• Send facsimiles.
6.4 Solution Pattern 2: Receive External Communication
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.
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.
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
• Receive an incoming paper communications. The incoming document is
commonly scanned and indexed.
xCP Pattern Library 45
6.5 Solution Pattern 3: Document Signature
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.
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.
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
• 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 46
6.6 Solution Pattern 4: Formal Internal Communication
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.
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.
Following are several techniques that are used in intra-case communications:
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 47
Figure 6–7 Case notes
Notes are comments entered by case workers and provide a running account of the
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.
Respond to a task request and provide an explanation
Figure 6–9 Accepting a case
xCP Pattern Library 48
6.7 Solution Pattern 5: Informal Collaboration
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.
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
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
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
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 49
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
• Post communications to a wiki.
• Post communications to a collaboration space in CenterStage.
xCP Pattern Library
7 Close Case
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
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
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 51
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 52
7.4 Solution Pattern 1: Case Data Archival
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.
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.
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
• Allow for unexpected case termination.
xCP Pattern Library 53
7.5 Solution Pattern 2: Case Disposition
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.
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
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
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.
• Manual or physical actions may be required as part of disposition (for example,
releasing the defendant)
xCP Pattern Library 54
8 Case Policies
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.
When implementing case policy patterns, consider a series of questions about who, how,
when, and what. For example:
• Who has access to case information?
• Who is allowed to work on a case?
• Who performs a specific task?
• 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 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 cases (if any) require special handling?
• What actions, events or decisions are logged?
xCP Pattern Library 55
• 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 56
8.4 Solution Pattern 1: Case Access Control
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.
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.
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
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..
• 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
xCP Pattern Library 57
8.5 Solution pattern 2: Performer Assignment
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
• 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.
While trying to identify and define the different assignment policies, consider the following
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 58
• 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.
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
5. Determine if the performer assignment should be static or dynamic.
• Select the performer by invoking a rule in a business rules engine.
xCP Pattern Library 59
8.6 Solution pattern 3: Information Access Control
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.
Consider the following issues when defining access control policies:
What types of information require access control? Access control operates at different
• application views within a case
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 60
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
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
• 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 data fields, in which certain data fields in an object can be viewed only
by certain security roles.
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 61
Following is a simple example of the table suggested in item 5:
Information Resource Sensitivity Security Role Access Permission
Health Claim Name of provider,
diagnosis, and treatment
Claims worker Read or Edit
Personal information of
value for identify theft
Controlled by HIPAA
Medical expert Read only
Information about case
Case executive Read only
• Define procedures for auditing
• Define procedures for exception handling
xCP Pattern Library 62
8.7 Solution pattern 4: Task Delegation & Reassignment
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
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 63
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.
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.
• 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 64
8.8 Solution pattern 5: Business Logging
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
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
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.
• 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
xCP Pattern Library 65
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
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
• Enable authorized business users to add comments to the business log, but not edit
the automatic entries.
xCP Pattern Library 66
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
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
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
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:
xCP Pattern Library 67
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
• 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 68
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
• 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 69
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 70
9.4 Solution pattern 1: Model Persistent Process Data
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
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.
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
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
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