Designing your case management solution and application

Edit online
To design a case management solution, identify what user activities are needed to accomplish the main user goal. Decide what business-level activities and steps you need, and then group those activities and steps into a case. As you identify the content needed to complete those steps, decide who will work on the content and what does or does not need to happen to complete it.

One approach to designing a solution is to first identify the types of documents that people in your organization need to complete for some activity. For example, to resolve a credit card dispute claim, you might need a dispute form and customer to complete the form and a service representative to review that form. Next, you might need to initiate a fraud investigation if circumstances warrant such an activity. In that case, you might need a fraud investigator to review the claim.

Therefore, for a credit card dispute case, the solution must include these artifacts:
  • Dispute form
  • Fraud investigation form
Your solution must also include these roles:
  • Customer
  • Customer service representative
  • Fraud investigator

The following diagram shows the steps you might take when you try to identify the artifacts that you will need for a solution.

You can use Case Builder to help you think through the various document classes, roles, case types, activities, and so on that you need for a specific solution.

Flow diagram that shows the path a business analyst might go through when designing and creating a solution. Adding a solution Case types Roles in solutions Document classes Adding and reusing properties Adding activities Building new FileNet P8 processes to complete activities Designing views Testing your solution

A solution is a set of related business problems (or case types). For example, if you are designing a solution for the bank industry for a credit card dispute claim, you might first decide what case types are needed. An example of a credit card dispute case type is a processing a claim. For this case type, a customer claim for a credit card dispute is reported and processed.

For every business problem that you are trying to solve (case type), you have physical assets or documents (document classes) that you work with to complete the case, people who work those documents (roles), and activities that need to be completed to close the case. Properties help to define the details of the case types, document classes, roles, and activities.

A process describes how case workers must complete an activity, but an activity describes what needs to be done and why. For every activity, steps can be completed by the system or by the case worker. Activities can be run in parallel, they can be chained together, or they can even be skipped.

You can create a workflow process for an activity in Case Builder. You can also define an activity process map or a process definition by using Step Designer in Case Builder or by using IBM® FileNet® Process Designer, which is integrated into Case Builder at both the solution and activity level. You can modify workflow processes that are created for an activity in the Case Builder Step Designer in the IBM FileNet Process Designer. External process activities are created as reused activities in the Case Builder and should be implemented by using IBM Business Automation Workflow Process Designer or IBM FileNet Process Designer

Activities can be required or optional, and you can set the activities to start automatically or manually by a case worker. A case is completed when all required and currently running activities are completed. In addition, you can group activities so that they are mutually exclusive and only one activity in the group can be completed or all-inclusive and all activities in that group must be completed. You can also group activities inside of a container activity.

You can also associate business rules with your solution. Organizations might have rules for business operations, such as for pricing calculations, eligibility checks, validations, underwriting, and fraud detection. In your solution, you can create business rules that determine process routing or update case properties. In conjunction with other case management capabilities, business rules can be used in the following ways:

  • Intelligently assign priority to cases or assign case workers to activities
  • Automatically create and assign activities
  • Trigger fully automated actions that are based on external events, completion of other case activities, or expiration of activity deadlines
  • Apply rules to the key facts and information, and guide the responses that are based on that information
  • Simplify certain activities by automating the decision logic
  • Increase consistency by using decision rules across similar cases
You can also design your solution in other ways:
  • Decide what the case worker needs to do to complete his or her job and what fields are needed in the Case Client.
  • Evaluate the use case flow and extract the solution assets from it.

As you become familiar with designing solutions, you can identify the roles, document classes, and properties that can be used in more than one case type.

Tip: When multiple business analysts are collaboratively designing a solution, inform other users before you delete solution objects such as case types. If you delete a case type and commit the changes while another user is editing that case type, errors will be returned when that user saves and deploys the solution.

When you design and create a solution, you must decide what the solution locale is. The solution locale refers to the locale of display names, such as case properties, case types, activities, and other solution artifacts that you create with Case Builder. When you deploy the solution to a target environment for the first time, you must deploy the solution under the same locale to ensure that the display names are preserved.