Best Practices from Oracle Development's A‑Team

BPM 11g - Case Management In-Depth: Cases and Case Activities Part 1 - Activity Scope

Mark Foster

In the previous blog entry we looked at stakeholders and permissions, i.e. how we control interaction with the case and its artefacts.

In this entry we'll look at case activities, specifically how we decide their scope, in the next part we'll look at how these activities relate to the over-arching case and how we can effectively visualize the relationship between the case and its activities.

Case Activities

As mentioned in an earlier blog entry, case activities can be created from....

  • BPM processes
  • Human Tasks
  • Custom (Java Code)

It is pretty obvious that we would use custom case activities when either...

  • we already have existing code that we would like to form part of a case
  • we cannot provide the necessary functionality with a BPM process or simple Human Task

However, how do we determine what our BPM process as a case activity contains ? What level of granularity ?

Take the following simple BPM process....


...functionally it is identical to the following three processes executed in sequence...


...and even functionally identical to the following combination of Human Tasks and processes executed in sequence...


The reason I’ve highlighted this is that, as far as case activities are concerned, we could have...

  • only one case activity in the first example (the complete process)
  • three case activities in the second example (the three smaller processes)
  • five case activities in the last example (two small processes and 3 human tasks)

So which do we choose ?

I’d like to introduce a couple of terms which I hope will help us to understand the problem and the solution....

Stakeholder Interaction Point

Points within the lifecycle of the case where a stakeholder is required to be able to interact with the case either explicitly (i.e. doing something) or implicitly (i.e. case rules), e.g.

  • Choose the next or a different case activity
  • Replay a case activity
  • Delay the scheduled case activity
  • etc...

Note that here we are talking about stakeholders interacting at the level of the case, not routine workers interacting at the level of the human task, even if in practice these are the same individuals.

Unit of Case Work

A series of activities which can be performed without any required stakeholder or case rule interaction...

  • BPM process activities, including human tasks, relating to a whole process
  • Sections of Java code relating to a custom case activity

With these two concepts we can decide the granularity of our case activities. Let us look again at the three alternatives above with respect to “Stakeholder Interaction Points” and “Units of Case Work”....


... in this case all five BPMN activities form a “unit of case work” & can be performed without any stakeholder or case rules interaction.

We can increase the level of granularity if stakeholders need interaction points, be they manual (from a UI via the CM API) or automatic (via case rules)....


...and even further increase the granularity if required...



Further Business Considerations

In the above examples we have taken into consideration only the points at which stakeholders interact, we also need to consider the logical grouping of BPMN activities from a business perspective... i.e. within a single Unit of Case Work we group BPMN activities relating to the same business need.

As an example, if a request for documentation leads to a wait for that documentation to arrive followed by document review, and if the document does not arrive in a given time take escalation actions, it makes sense to put them all in a process together. This could be modelled as separate processes (case activties) where...

  • the request for documentation forms one activity
  • the document arriving etc.. forms the second activity and is triggered by the a case rule when the document is attached to the case

....but logically they belong as one process.


In this first part of "Cases & Case Activities" we have looked at the scope of case activities and the level to which they can be decomposed based on “stakeholder interaction points” & "units of case work".

I have heard from a few customers that they love the concept of case management but that they are too far down the road building a case management solution wholly with BPM to take advantage of the Case Management features now in PS6. My advice to them is: now is the time to think about how your BPM processes are designed, based on the principles above, so that they can easily be re-used as case activities if and when you move to a fully featured case management solution.

In the next part of "Cases & Case Activities" we will look at how activities fit within a case and how we can effectively visualize this.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha