As a transitional step, this site will temporarily be made Read-Only from July 8th until the new community launch. During this time, you can still search and read articles and discussions.

While the community is read-only, if you have questions or issues requiring TIBCO review/response, please access the new TIBCO Community and select "Ask A Question."

You will need to register or log in or register to engage in the new community.

Processes without Process. Part II: Anatomy of a Case Management application with TIBCO BPM

Last updated:
11:51am Nov 30, 2020

Introduction

The purpose of this page is to walk you through how a case-based application works on TIBCO BPM.

First off, clearly, you have to build some models in the tooling. So I would start with a case data model, then create some basic process micro-flows to do stuff like create cases, update data, and change states. Don’t worry – most of this is actually built for us by the tooling. You can just right-click the data model and choose to generate “Business Service” to get a case creation micro-flow or “Business Action” to get a case update micro-flow.

With a basic data model and actions in place – what do we now get – well – we log onto a user interface as a user and we can start managing our cases.

Here is a simple example of a case management app. How do we build the app? Well, that comes from template-based re-composable apps (UIs) that can be created with TIBCO ActiveMatrix BPM. Please read the dedicated section Processes without Process. Part III: Buiding Case Management UI applications with TIBCO ActiveMatrix BPM

Anatomy of a Case Application

Let's walk through how a case-based application works on TIBCO ActiveMatrix BPM.

So I log in to an app – let's see what we have. So this screen below is the case dashboard. It’s my GPS screen for the knowledge worker. In the middle, I can see the data – it's all the contextual data that is relevant to this case – or the business artifact I am managing. In this case, it is an incident on a railroad – where a station is closed and the rail company needs to manage and address the disruption to service. The data comes from the case data model we created in Business Studio – but with app dev, we can use templates to make it look however we like with simple HTML5 templates.

Next up we have a summary. This is like our GPS route summary, you can also think of it as the kind of rear-view mirror – it tells me where I am, where I have been and some key indicators I might need to take note of. For example, like SLAs or what type of case this is. The milestone trailer indicates my current state and the states I already competed.

Next is the contextual data panel. This is really important for these kinds of apps. It's where I can store and update unstructured data (such as comments/documents) with the case context. If I start small and create a simple app (for example by just deploying a data model and a few microflows) – my users can get straight into using the app because they always have these mechanisms to record their actions. Then when I look back at the system we can identify common patterns and automate those as their own automated or manual “Business Action” micro-flows.

But how do I run one of these actions?

So these buttons at the top – are the Business Actions. They are the snippets of process ,my user can run right now. It's how the user “drives” the case. The actions available are based on the current context (state/data etc) and my user's access rights. They can simply click action, the process will run and they will see relevant forms down in the content pane.

Now one of the really powerful features of this case-based approach is that users can start to link processes, work items, and even other cases to this case context.

So if my user determines that this incident is related to another at a different station – they can link the two and links will appear here – they can then navigate straight to that case's dashboard by simply clicking.

They can also see related tasks here – for example, if a customer calls for the status of their loan – the operator could simply bring up the loan dashboard, see the status – see a task is outstanding, and either explains to the customer what is required or perhaps even click to open it and complete the task right from here.

It is important to realize everything here is very decoupled – it is all held together just by references to the case context. That’s what makes it so agile – I can easily change any artifact – deploy it in isolation, upgrade, add, and still maintain links to the original case. This does raise some challenges around how these separate processes and cases talk to each other – how they communicate – but fortunately that is covered by TIBCO ActiveMatrix BPM's comprehensive event capabilities – its simple to fire events to other processes waiting on a context – that could be a case reference, or anything else you choose. For example, we can easily fire an event to say incident resolved – then any process related to this incident will wake up and act accordingly (as we defined in the process).

So we have seen the case dashboard and how we navigate between cases. But how do we get to this case dashboard? Well, there are several ways  - but let's start with a simple search.

As you can see here we can search the case data to find what we are interested in easily enough – we can also get to a case through a task, or even through an analytics dashboard. All we need is the case reference, so we can pretty much navigate to a case from any application that has the reference (social tools, analytics, other apps) – again this is all down to the case-based approach and the power of the AppDev UI capabilities in BPM 4.0.

Actions Drive Cases

Let's summarize what we have seen so far.

So we deploy a case model, + some actions. We have a case dashboard. As part of the case model, we configure states, and we associate the business actions with the case + states to make them available. Some good examples of states shown here…

It’s quite a shift in thinking from the traditional process. We are much more interested in states and actions vs processes and tasks.

 

Progressing the case through actions

The user then progresses the case through actions. We can have automated processes that run too – but generally, a caseworker will review the context and act using one of the actions displayed. They then interact with the action through forms displayed in the context pane.

Adhoc Tasks

Another aspect of this decoupled approach is the concept of an ad-hoc task. It's like any other activity in a process – but we can define that it occurs based on rules vs sequence. So rather than have an inflow we can define a rule that governs whether it is activated or enabled.

It can then run automatically or by a user selecting it. For example, in this incident scenario – we could determine that if the station is closed we need to arrange alternative transport for passengers from the preceding station. This Adhoc task could be a process that runs automatically – or we can make it available for a user to select and execute.

Here we can also see a visualization of these activities – in terms of what has happened, what’s running and what might run later – kind of a case plane.

Social, Documents and History

We already mentioned the value of social comments and documents stored in context with the case. History is also a vital tool to help a user understood what has happened already – the milestone view in the summary panel also provides a quick view of history, using previous states to indicate where we are.

Insight to action

Analytics can play a huge role for knowledge workers.

From analytics, a knowledge worker can get all sorts of new insights into case related data. The case data itself is easily accessible from the analytics tool (Spotfire) and of course, this can be tailored and customized by a business user all from the same tool. They can add additional data, and use this as a tool to gain new insight which can lead them to make better decisions to progress the case.

From the dashboard, it is easy to invoke actions such as re-prioritize a case or enter the case context to drive the allowed actions.

Summary

That gives you a quick test drive of the capabilities of this digitalized, case-based approach with ActiveMatrix BPM. The last thing to bear in mind is that this is not a new product. It’s all part of the core TIBCO BPM Suite.

The reason for not separating it out is simple. Digitalized processes span the whole spectrum of process based apps, from structured, unstructured, to content, rules, or sequence based logic. We rarely see applications that just focus on one area such as Case Management – and in fact, this kind of separation of case management has been a fundamental shortcoming in these solutions in the past – forcing customers to choose one approach or the other.

A true digital process platform needs to cover all these use cases in a single, enterprise-strength platform – and that’s what you get with TIBCO BPM.

Feedback (1)

Hey,

Thanks for the article above, it is quite informative.

We prepared a POC on one of the use cases using Case Management feature of BPM 4.1.

The POC was based on a customer query support with most of the features you had listed above.

I do have few questions though -

1) The case class had five different states, but it might be possible that case will start from 1st state, moved to 3rd state then end with 5th, i.e., skipping 2nd and 4th. But when we see the case history in Case Management app, it shows up all the 5 states on the top instead of only 3 as it traversed through 3 states not 5. Do you think its the right behaviour?

2) I was really not able to understand the purpose of Case Operations declaration in a Case Class. You have any pointers for it?

 

Regards

Dheeraj

kakwani 2:18am Sep. 02, 2016