- Before you start
- Introducing IBM Case Manager and the solution templates
- Implementing the Credit Card Dispute Management template
- Extending the template using the Process Designer
- Maintaining a one-touch case policy
- Working with the UI assets
- Downloadable resources
- Related topics
Introducing the Credit Card Dispute Management sample solution template for IBM Case Manager
This content is part # of # in the series: Use industry templates for advanced case management, Part 1
This content is part of the series:Use industry templates for advanced case management, Part 1
Stay tuned for additional content in this series.
Before you start
Case management is a critical function for virtually every business. The capability to efficiently process cases has impact on top and bottom lines, could have regulatory implications, and most importantly, is critical to maintaining customer satisfaction and loyalty. Effectively implementing a case management solution that meets today's needs requires a broad platform that brings together a range of capabilities, including content management, business process management, business rules, collaboration, and analytics. The solution needs to integrate seamlessly with existing infrastructure, leveraging those assets to provide complete, consistent context to case workers in a user interface tailored to how and where they work.
IBM Case Manager provides the platform and tools for a business analyst to define and implement this new generation of case management solutions. To accelerate the development of solutions in particular industries, IBM Case Manager offers solution templates, which are case management assets that can be customized and extended to build a complete solution. To illustrate the value of solution templates and the capabilities of IBM Case Manager, IBM offers two sample solution templates. This tutorial introduces one of those templates: Credit Card Dispute Management from the financial services industry. This sample template can serve as a foundation for clients who want to build a similar solution. The template can also serve as a learning tool and reference for clients to build other solutions in other industries.
After reading this tutorial, you will understand what a template is, which assets are delivered in this sample template, and how the assets were built. This tutorial includes the code for this sample template and instructions on how to extract and deploy the template.
This tutorial supplements your knowledge of IBM Case Manager by providing a deeper understanding of how to build and deploy a solution. This tutorial assumes you have at least a basic level of familiarity with IBM Case Manager and the IBM Case Manager Builder, as well as the IBM FileNet® P8 Platform and tools. You should have installed IBM Case Manager and have some experience working with the tools to build a case management solution. For more information about IBM Case Manager, including a guided tour, see the Related topics section.
This tutorial addresses business analysts and IT users looking to supplement their understanding of IBM Case Manager with an understanding of templates and some concrete examples of building specific assets.
Deploying the sample template
This tutorial includes a ZIP file with the artifacts of the solution (see Download). While downloading and deploying the template is not a prerequisite for this tutorial, you might want to deploy the solution before you read the tutorial so you can refer to the code directly as particular topics are discussed. The steps to deploy the template and then create a solution from it are straight-forward. It should take you no more than a couple of hours to deploy the template.
To deploy the solution, open the ZIP file and extract the contents onto your local file system. You will see the following assets:
CCDM_Solution_for_ICM52.zip CCDM 5.2 Assets - Forms Deploying the Credit Card Solution on ICM 52.pdf Credit Card Demo Script ICM 5.2.pdf Letter_To_Polestar.tif Marmalade_Confirm.tif Previous version-CCDMforICM5.1.zip
The file called Deploying the Credit Card on ICM 52.pdf contains detailed instructions to deploy the sample and run it. There is also a demo script that guides you through the solution and helps you to become familiar with the assets.
Introducing IBM Case Manager and the solution templates
Overview of IBM Case Manager
There are many types of case management applications. This tutorial focuses on solutions that are more human-centric in nature and that require the coordination of different services throughout an organization, such as health, legal, and financial, in order to provide a business service for a customer or party. Typically, this includes creating a case file and following a process (or collection of processes) to ensure the delivery of the business service. Case managers or a case team collaborate to resolve and close a case. After the case is completed, information about the case is typically retained for compliance or to support longer-term business processes.
These case management scenarios require highly collaborative, dynamic, and event-driven work. Often cases and the processes that support them can have long life cycles, which can include closing, suspending, or reopening the case.
Credit Card Dispute Management in financial services is the example case management solution featured here. In the example scenario, a customer calls in to dispute a charge on his credit card statement, and a case is opened to track this dispute. Many times, these cases can be resolved right on the phone with the customer. But a subset of cases are more involved and require the creation of a case where details of the case might be gathered from customers, third parties, and disparate systems. Resolving the case requires collaborative work between multiple teams, inside and outside the organization. There are regulatory and company SLAs to factor in that dictate time lines and interactions with the customer.
Delivering this type of solution requires the effective integration and leveraging of a broad set of capabilities, as shown below.
Figure 1. Capabilities required for advanced case management
Case content must be gathered and maintained in a single, secure location and passed seamlessly among everyone working on the case. Context must be complete and consistent across all users. Events, business rules, and workflow help to automate elements of the process to reduce errors, help to ease the burden on the user, and help increase efficiency. Efficient collaboration among team members is critical. Providing transparency into the process is important, not just for operational purposes but also to assess the impact of the solution on the overall business.
IBM Case Manager provides a platform that seamlessly integrates capabilities from across IBM Software Group to deliver the advanced requirements needed to drive better case outcomes. The platform combines enterprise content management and business process management, along with integrated rules, events, collaboration, and analytics to deliver a comprehensive case management product. On top of this platform, IBM Case Manager provides a set of tooling that enables business analysts to quickly define solutions and then to collaborate with customers and IT to deliver them.
Introducing case management solution templates
There are case management solutions for virtually every industry, as shown in Figure 2.
Figure 2. Case management in different industries
Most of these case types are vertical in nature, solving a specific problem in a specific industry. But some case types are more horizontal, addressing a challenge that occurs in many industries.
To help in the deployment and delivery of these solutions, IBM Case Manager offers a solution template. A solution template contains case management assets that are applicable to a particular business problem. The solution template can be easily customized and extended to deliver a complete solution.
To illustrate the concept of a template and demonstrate how the features of IBM Case Manager can be used to deliver a solution, IBM provided two sample solution templates with the first release of the product. These templates can be used as starting points to build a solution. They can also be used as general references and learning tools for clients looking to build their own solutions. The first sample template is Credit Card Dispute Management in financial services. The remainder of this tutorial introduces this template, describes the assets it contains, and details how the template was built. The second sample template is Auto Claims Management in the insurance industry, which is described in Part 2 of this series.
Understanding credit card dispute management
Successfully managing customer credit card disputes requires efficient interactions among customers, merchants, the card issuing bank, and credit card agencies. The increased number of disputes over the past few years, coupled with increased regulatory requirements and higher focus on customer satisfaction and retention, have put significant pressure on banks and credit card agencies to improve efficiencies in handling disputes. Errors or inefficiencies in the processing of dispute cases can result in additional costs, delays, and eventually unresolved disputes and decreased customer satisfaction.
In the example flow, a customer calls in to dispute a transaction. After working through the automated system, a customer service representative (CSR) picks up the call and gathers details about the case. If the service representative is unable to resolve the issue, the case is passed on to a dispute adviser, who works the case to conclusion. The dispute adviser works with the customer, merchant, and others to review the case and gather details. He can close the case directly, apply a credit to the customer's statement, or request a charge-back. If the merchant accepts the charge-back, the case is resolved. If not, a representment process is initiated, and the dispute adviser must decide based on the details of the case whether to pursue it further with the merchant or re-bill the customer. At any point, the CSR or dispute adviser can submit the case to the fraud department. There might also be rules in place to automatically determine if there is potential fraud. If the fraud department accepts the case, they will likely create a new case to investigate the account.
Figure 3 provides a high-level view of the case flow.
Figure 3. High-level process flow for credit card dispute management
Throughout the case lifecycle, there can be incoming supporting documents and correspondence being generated sent to the customer, the most common of which are status updates. All participants have access to the case details, and it is critical that the case context is as complete and consistent as possible during and after the case is completed.
The IBM Credit Card Dispute Management sample template implements illustrative aspects of this process, providing assets that support the processing of a disputed item. A case type for fraud investigation is defined, but the details of that case type are not detailed in this tutorial.
Implementing the Credit Card Dispute Management template
IBM Case Manager enables the business analyst to design, build, test, and deploy a solution using IBM Case Manager Builder. The Case Manager Builder product provides an easy-to-use environment that enables business analysts to describe their solutions using terminology familiar to them, while abstracting away the underlying complexities of the technical implementation.
To understand the implementation of the Credit Card Dispute Management sample, start with the assets defined using the Case Builder tool. Then learn about some places where the template is extended using the IBM FileNet P8 Process Designer. Finally, read about some of the user interface assets in the template.
Understanding the structure of an object model
The artifacts of a case management solution are organized into an object model. Each solution includes a unique user-provided descriptor used as a prefix on all assets within the solution. The solution also contains one or more properties, document types, roles, and case types. Document types, properties, and document types are defined at the solution level and used across the defined case types. There is one personal in-basket defined for all solution users.
Within a case type, there are properties, case property views, folders, and tasks. All properties defined at the case-type level are mapped up to the solution level so they can be reused in other case types. Case types also contain user pages, which can be customized and new pages created to meet the needs of the case workers. Figure 4 shows the case management object model.
Figure 4. The case management object model
Understanding the case builder artifacts for the credit card sample template
The assets in this section were defined and implemented using the IBM Case Manager Builder tool. Collectively, they provide the definition and high-level structure of the template.
There are a significant number of properties defined in the template. Many properties are used to store details of the dispute, such as customer, transaction, and merchant information. Others are properties associated with document types important to the solution. Finally, there are a number of properties that aren't immediately or directly exposed to the end user that play important roles in the processing of a case instance. Properties are discussed in more detail under "Extending the template using Process Designer." Figure 5 shows the properties view in Case Builder.
Figure 5. The properties view in Case Builder
In this view, you can edit the Dispute Case State property, which is a string property with a choice list to enumerate the possible states of the case. You can see the elements you can set on a property:
- Single or multiple valued
- Default value
Roles and in-baskets
There are a number of roles defined for the solution, as shown in Table 1.
Table 1. Roles in the solution
|Customer service representative||First point of contact for the customer; gathers details about the case and if he can't close it, hands it off to dispute adviser.|
|Dispute adviser||Owns the dispute case; once it lands in his in-basket, processes it from review to completion.|
|Dispute supervisor||Manages a team of dispute advisers; handles escalations, reviews cases, reassigns work.|
|Correspondence team||Generates and sends all outbound correspondence to the customer.|
|Data clerk||Receives all incoming content for the case from customer, merchant, third parties, etc.|
|Fraud team||Investigates cases with potential fraud, including lost or stolen cards, unauthorized charges, etc.|
|Legal||Usually not involved in dispute cases; only involved in arbitration cases or maybe some escalations.|
Each role has an associated in-basket. The template defines a simple personal in-basket for handling work items that are directed to individuals or workgroups.
Figure 6 shows the CSR role in the roles view of Case Builder.
Figure 6. The Roles view in Case Builder
Throughout the dispute management process, there are documents that might be included with the case. Table 2 lists the document types that categorize these documents.
Table 2. Document types
|Dispute form||Captures details of the issue if the customer were to mail, email, or fax in a dispute form.|
|Supporting document||Categorizes any document of content stored with the case, including receipts, invoices, emails, etc.|
|Correspondence document||Categorizes any letters or documents sent to the customer. Includes a property that identifies the specific type of document (status, finality, need info, fraud, etc.).|
|Charge-back document||Categorizes the generated documents sent to the credit card agency or association representing the merchant.|
|Survey form||Collects survey information completed by the customer; could perform content analytics on the responses to improve processes.|
|Phone recording||Stores phone recordings generated during the case.|
For the correspondence document and the supporting document, a property is used to identify the specific type of document. This is useful for audit purposes, as well as analytics. For example, the correspondence documents type has properties for date requested, date sent, and type of letter. These properties can be used together to analyze whether correspondence SLAs are being met. The analytics can look across all correspondence documents or use the type of letter property to look at specific types. Figure 7 shows the definition of the correspondence document type in Case Builder.
Figure 7. The document types view in IBM Case Builder
There are two case types defined within the template. The first is manage dispute item, which defines the processes for resolving a dispute around an individual transaction. This is the case type addressed in detail in this tutorial.
The second case type is investigate fraud, which corresponds to the case where a disputed transaction might involve potential fraud. While many of the processes that implement the fraud case type are similar to that of the manage dispute item type, following are the two fundamental differences that merit the creation of a new case type:
- The approach to investigating each case is different. For a manage dispute item type, the focus is on the individual item. When investigating fraud, the focus shifts to the entire account. This difference is important, as it affects case details and process flows.
- The lifecycle of the cases is different. Most individual item disputes are resolved within days. However, a fraud investigation case can be open significantly longer as the case team works through impacted items within the account.
Structure of the manage dispute item case type
When defining a case type, the business analyst can define many aspects of the case structure, from the tasks that process the case to the user interface presented to the case worker to the actual case folder structure for a case instance.
Within IBM Case Manager, a case instance is represented as a case folder in the ECM repository. Case properties for that case type are represented as properties on that folder. In addition, a business analyst can specify that additional sub-folders be created for a new case instance.
For the manage dispute item case type, there are two additional sub-folders: a correspondence folder and a supporting documents folder. Whenever a new instance of the manage dispute item case type is created, this folder structure is created. The correspondence sub-folder stores any correspondence that goes to the customer. The supporting documents sub-folder is created to store any content relevant to the case instance. Providing this additional infrastructure makes it easier to add documents to the case. It also becomes easier to search and do analytics on the case content. Figure 8 shows the folder structure. Each instance of the credit card solution has this structure.
Figure 8. Folder structure for credit card sample solution template
To help organize the case information for the case worker, the Case Builder allows the business analyst to create a view of the properties in the case. For the manage dispute item case type, the viewable case properties are organized into the following three groups:
- Customer information
- All information about the customer, including the account on which the transaction is being disputed
- Transaction details
- Details about the transaction
- Dispute details
- Information about the dispute to be completed by the dispute advisor as he reviews the case
Figure 9 shows the Case Data view.
Figure 9. Case Data view for the manage dispute item case type
You will see in "Customizing the work details page using an eForm" how to use an eForm to present this view information to the CSR and dispute adviser.
Figure 3 shows a high-level task flow for managing a dispute item. Figure 10 shows the same flow with the processes mapped to tasks in the template.
Figure 10. High-level process flow for credit card disputes
Each box in Figure 10 map to a tasks within the manage dispute item case type. Figure 11 shows the tasks listed in IBM Case Manager Builder.
Figure 11. Tasks defined for the manage dispute item case type
Review dispute item and close case are the only required tasks in the case type. They are supported by a number of optional, automated tasks, most of which are instantiated by the setting of case properties. A case worker can instantiate the following three user-created tasks:
- Request letter
- Review case
- Request sales copy
The review dispute item task is the main required task for the case type. Figure 12 shows its task flow.
Figure 12. The review dispute item task flow
When the case is opened, the review dispute item is launched, and a work item is presented to the CSR. After gathering some initial information, the CSR can choose to close the case, submit the case to fraud, or process the dispute. If he processes the dispute, control is passed to the dispute adviser, who then owns the case through to its completion. In this flow, the process charge-back, initiate fraud investigation, and close-case system steps set case properties that will launch new task instances. The next section shows how to do this.
Extending the template using the Process Designer
As the business analyst is implementing his solution, there are instances where he needs to use the Process Designer to implement additional required features. For this template, Process Designer was used to add system or content integrator steps to perform work. Process Designer was also used to set values for in-basket columns, manage the state of the case, and configure workgroups. Process Designer also integrates an eForm into the UI, as described in "Customizing the work details page using an eForm."
Using Process Designer to set values for in-baskets
It is common to use functions or system fields to set values for case properties or in-baskets. To accomplish this, step outside of the Case Builder to work in Process Designer. The integration between these tools makes it easy to move between them to extend a solution.
Following are things you should be aware of as you move between Case Builder and Process Designer:
- Before opening a solution in Process Designer, make sure you have saved and closed the solution in Case Builder.
- You are likely to overwrite changes if both tools have the solution open. So your best bet is to only have the solution open in one tool at a time.
- When opening the solution in Process Designer, make sure you use the File > Solution > Edit menu option.
- Navigate to the solution directory and select the solution definition file so the entire context of the solution is provided to Process Designer.
- Case properties are referenced by their symbolic names in Process Designer.
- This is actually true anywhere outside of Case Builder. As an example,
if your credit card solution has a solution identifier of CCDM, all
properties, document types, roles, etc. should have a prefix of
CCDM_. The symbolic name of a case owner property defined in Case Builder would be
CCDM_CaseOwner. Note the case sensitivity and removal of spaces.
- Case properties, case instance properties, and workflow data fields are different entities.
- When a case type is defined in Case Builder, it is modeled as a case folder in the FileNet P8 Content Engine. When you define a property within a case type, it is modeled as a property of the case folder. This is where property values for a case instance are persisted. Workflow data fields must be initialized with the case data properties. Case Builder does this for you automatically, but when you are using Process Designer to create steps, you must do this manually.
Consider a simple example in which you want to set the value of an in-basket column. When a fraud investigator views his in-basket, it looks like Figure 13.
Figure 13. Fraud investigator's in-basket
The CSR fills in the Customer Name column when gathering details about the case. The system fills in the Assigned Date and Work Item column values as part of the task flow. To understand how this is done, look at the task flow in Process Designer for the evaluate for fraud task, as shown in Figure 14.
Figure 14. Setting the value of in-basket columns in Process Designer
Figure 14 shows the simple flow for the evaluate for fraud task, as created in the Case Builder. You can see the pre-assignments for the user step evaluate for fraud. The values for CCDM_AssignedDate are set using a system function (systemtime) and for CCDM_WorkItem using a system field (F_StepName). These values will appear in the in-basket when displayed. This is the simplest way to access functions and system fields for use in in-baskets.
However, these values are not persisted with the case unless they are assigned to the underlying case instance. For user steps such as the task flow steps created in Case Builder, Case Manager handles this for you. For the after-completion assignments that occur for the evaluate for fraud step, Case Manager automatically provides a mapping between the workflow data field generated from the case property and the underlying case property persisted with the case instance, as shown in Figure 15.
Figure 15. Mapping workflow fields to case properties
Note that Case Manager does this mapping automatically only for steps created within the Case Builder. If you create any steps in Process Designer that assign case properties and you want them persisted to the case, you must do this mapping yourself or you must assign the values directly to the case property associated with the case instance.
Managing case state
Milestones can be useful for tracking the progress of a case, triggering additional work activity, or administering timers and escalations. Unfortunately, the current version of IBM Case Manager does not inherently support the notion of a milestone that spans multiple tasks. The credit card solution uses a case property called dispute case state to provide this capability. This property tracks the current state of the case, and it can be used in much the same way as a milestone.
One important use of this property is to trigger automatic tasks. For example, a precondition being met is what triggers the evaluate for fraud task.
Dispute Case State = 'Fraud'
The dispute case state property is set to this value by the CSR or the dispute adviser when he clicks the Submit to Fraud response as he is reviewing a case. To see how this happens, refer to the review dispute item task in Process Designer, as shown in Figure 16. The route connector between review dispute and initiate fraud investigation is selected. It is a conditional route, dependent on the dispute adviser providing the submit to fraud response.
Figure 16. Conditional routing in Process Designer
The initiate fraud investigation step is an assign step. Its implementation is shown in Figure 17, which shows the review dispute item task and the initiate fraud investigation step selected.
Figure 17. Manipulating case states in Process Designer
There are two things to accomplish in this step. First, you want to request
a letter be sent to inform the customer that his case is going to fraud.
Do this by setting the fraud letter request property to
which triggers an instance of the generate letter automatic task.
Second, the case is being sent to the fraud department for evaluation. Set
the dispute case state to
In each case, you persist the assignment by assigning directly to the underlying case property instance on the case folder.
F_CaseFolder.CCDM_DisputeCaseState = "Fraud"
Note the use of the
F_CaseFolder prefix and the property's
CCDM_DisputeCaseState. The value is persisted
with the case, and the fraud task is initiated.
Maintaining a one-touch case policy
Efficiently managing credit card disputes is critical to customer satisfaction and retention. To improve efficiency and to simplify the interface with the customer, banks insist on a one-touch approach to managing cases. This means that once a case is assigned to a dispute adviser, that adviser owns that case through to its completion. From a customer perspective, it is important that this one-touch ownership is maintained, regardless of how many people interact with the case behind the scenes.
The implementation of this in the credit cards solution makes extensive use of workgroups. Once a dispute adviser is assigned in the review dispute item task, future task instances work directly with that individual instead of the dispute adviser role.
To implement this:
- Create a case property called case owner.
- Create a workgroup called CaseOwner within each task that routes work to the dispute adviser.
- Use Process Designer to add an assignment to set the case owner, as
shown in Figure 18. The Case Owner is set at the end of
the review dispute item step within the review dispute item task. Note
the use of the
userid()function to accomplish this. The
userid()function returns the name of the user who is currently working on the step.
Figure 18. Setting the case owner property
Once the case owner is persisted, you can use it in other tasks. For example, consider the add document automatic task. This task is triggered when a document of type supporting document is checked into the system. A member of the data clerk team processes the document, and then the case owner is notified to review the document. The task flow is shown in Figure 19.
Figure 19. Setting the case owner workgroup
When this task was created in Case Builder, a workgroup called CaseOwner was created. At the beginning of this task flow, the value of the case owner property was assigned into the workgroup so that the work was routed into his personal in-basket. This ensures that the case owner sees and processes the new document directly.
The use of the case owner property in conjunction with workgroups is done throughout the solution to implement the one-touch ownership policy. Also, supervisors can search for cases using the case owner property to track workload on dispute advisers and to measure SLAs. Supervisors can even reassign work simply by resetting the case owner property from within the case details work page.
Working with the UI assets
Within the credit card solution, there are a number of places where the UI could be customized to meet the needs of an individual role. For the credit card solution, the CSR and dispute adviser work details pages are customized using an eForm. The work page itself was customized to provide more case information to a case worker before he starts work on individual item.
Customizing the work page
When the CSR selects an item from his in-basket, details of the case are presented in the case information widget on the right. The CSR can see documents in the case as well as historical information, as shown in Figure 20. In addition, he can use the widgets on the bottom of the page to quickly search for related cases by case ID or by customer name.
Figure 20. The work page for the Credit Card Dispute Management template
In addition to the widgets on the right and bottom of the page, custom styles may be applied to the page to give the page background a different look. To change the page style:
- Click Edit page in the upper-right corner of the page.
- Click Actions - Edit Space Settings in the top menu bar.
- Select a style from the list of available of styles.
- Click Save to save your changes.
- Click Finish Editing in the upper-right corner of the page.
- Repeat this for each page for which you want to use this style, because there is no support for setting the style at a space level.
A second customization you can see in the work page is the customized case ID. By default, case IDs take the form of:
<solution descriptor>_<case type name>_<unique numeric id>
So, a default ID for the manage dispute item case type would be
You may find it useful to create a shortened version of the case ID to help with presentation and searching. In the example, the case ID was shortened by eliminating the case type information. See the Related topics section for more information about customizing case IDs.
To provide the case information and case list functionality, the work page is customized with three widgets added to the page. The capability to list all cases for a given customer is provided by adding a case list widget to the bottom of the page and wiring it to the in-basket widget using a Script Adapter widget. It is then wired to the in-basket widget using a Script Adapter widget.
When a row is selected in the in-basket, the In-basket widget sends the customer name from the selected row as the payload to the Script Adapter widget. The Script Adapter widget then inserts the customer name into a query, then passes in an event to the case list widget, as shown in Figure 21.
Figure 21. Wiring the in-basket to the case list widget
The case information widget was added on the right and was wired to the in-basket widget. This wiring was achieved by editing the wiring on the in-basket widget. The example sends the selected row to the command widget, which is a hidden widget on every page that can broadcast events. We called a specific action: retrieve case info, which provides the case information (such as case identifier). The command widget then broadcasts this event. The case information widget receives and processes the event and populates itself.
Presenting a document in the UI
At any point in the processing of a dispute case, a case worker can add new content. When that occurs, a work item is sent to the dispute adviser so he can review the document and update the case as needed. Figure 22 shows the customized view the dispute adviser uses to review a new document.
Figure 22. The review new document work details page
This view is presented as part of the add document task. Remember that this task is instantiated whenever a new supporting document is added to the case. This new document is automatically presented in the dispute adviser's view, as shown in Figure 22.
To provide this capability, take advantage of the fact that for tasks that have a new document pre-condition, the initiating attachment is automatically populated with the new document. Complete the following steps:
- Open the task flow in Case Builder.
- Create an attachment called NewDocument.
- Save and close the solution.
- Open it in Process Designer and open the task flow.
- Under Workflow properties, set the NewDocument attachment to be the initiating attachment.
- Save and close in Process Designer.
- Open the Work Details page in the IBM Manager Client and edit the settings on the attachment widget to send the document to the viewer.
Customizing the work details page using an eForm
Within the credit cards template, an eForm is used to provide case workers with a consolidated view of the properties of the case. The details of where the information comes from are hidden, allowing the case worker to focus on the required work.
eForms can also be used to provide a stateful view of the properties of the case as the case moves through different steps and between workers. Figure 23 shows the UI for the CSR as he gathers the initial details about the case.
Figure 23. The CSR's work details page
Figure 23 shows a customized Work Details eForm page. The widget on the left is an eForm, which is replacing the case data widget. The CSR can enter details about the case. This is a static eForm. Everything is entered manually. However, this eForm could easily be extended to include logic that retrieves customer or transaction data from a database once some initial information is provided. A rules system could be running in the background that would use information the CSR entered and dynamically enable or disable fields or even add or remove fields to guide the CSR to gather the correct information for the case.
When the CSR completes work on this page, the eForm and its state is saved in a document. Figure 24 shows a view of the dispute adviser's customized work page.
Figure 24. Using an eForm in the dispute adviser's work details page
The dispute adviser gets a live view of the eForm on the left. All the information the CSR provided is preserved, and the dispute adviser can continue to modify and add to the form. In addition, the eForm has been saved as a document with the case. Case workers can open the document to get a read-only view of the dispute details. This document will always contain the most up-to-date information about the case.
The integration of this eForm into the case management solution is straightforward. Building this integration requires work in the eForms Designer, the IBM Case Manager Client, IBM Case Manager Builder, and Process Designer. Complete the following steps:
- Design the eForm in the eForms Designer tool, as shown in Figure 25. Cell names must match symbolic names of case
properties so that the data in the form is passed to those underlying
properties once the form is submitted. You can check this form into
the target object store so the solution can access it at runtime.
Figure 25. Designing the eForm in eForm Designer
- Go into the IBM Case Manager Client and customize the work details page. You can use the work details eForm page as the template. This page includes the eForm widget, which will eventually contain the eForm.
- Register the page with the name
Gather Customer Data.
- Open the review dispute item task in Case Builder. You can create an
attachment that stores the eForm document and add it as a parameter of
the steps where it will appear. Figure 26 shows it being
added to the initiate dispute step. You can also add it to the review
Figure 26. Creating an attachment to store the eForm document
- Assign the page layout for the initiate dispute step to be the custom
page you created, as shown in Figure 27.
Figure 27. Configuring the Custom Work Details page
- Save and close the solution.
- From within Process Designer, open the solution and the review dispute item task flow.
- Under Workflow Properties, click the Attachments tab.
- Set the value of the attachment to be the eForm that was checked into
the target object store, as shown in Figure 28.
Figure 28. Associating the eForm with the attachment
- Save your changes from Process Designer.
- Redeploy the solution from Case Builder to route work to the customized work details page and the eForm.
Solution templates are an important part of the IBM Case Manager Platform. They provide an accelerator for clients in building their own solutions using the platform. As part of the first release of IBM Case Manager, IBM has provided two sample templates to serve as learning tools and validation points for the platform. This tutorial introduced the Credit Card Dispute Management sample template, described the assets it contains, and provided tips on how particular assets within the template were built. After reading this tutorial, you should be more familiar with the notion of templates and have an understanding of how to use IBM Case Manager in conjunction with the other tools in the IBM FileNet P8 Platform to build a complete case management solution.
Mike Fannon updated this tutorial in March 2012. You can reach him at email@example.com.
- Learn about IBM Case Manager in the IBM Case Manager Information Center.
- Take a guided tour of IBM Case Manager.
- Learn about Case Manager Administration Client, which is the tool to used to manipulate templates and solutions.
- Access to documentation through the Publication Library.
- Get an overview of ECM Widgets.
- Read about an example of creating a solution with ECM widgets.
- Learn about IBM FileNet P8.
- See the new ECM Application Center to collaborate with other ECM customers and partners and gain access to pointers, resources, samples to help with solution development.
- See the ECM section on developerWorks to get the resources you need to advance your skills with IBM Enterprise Content Management products.