The key ingredients of an ACM case - the Hotel Booking Case in terms of adaptive case management image3

The key ingredients of an ACM case – the Hotel Booking Case in terms of adaptive case management

In a recent post I have introduced the key concepts in Adaptive Case Management (ACM). In the article you are reading now, I want to show an example of a specific case. This example should provide some clarity on exactly how the core aspects of a case are specified and how these provide the foundation for the case as it will be managed  by the ACM engine of choice (for example Oracle BPM Suite 11g).image

The example I use – inspired by the surroundings of the Oracle Fusion Middleware Partner Community event on Malta (February 2014) – is a hotel. The scope of the case is the booking and stay of a guest or party of guests. The case starts with the potential guest enquiring after prices and availability. It can conclude in several ways – ranging from the guest having had a pleasant stay to either cancellation, no show or even no booking at all.

This article does not yet discuss the implementation of the case. It introduces the key components that should be produced during design phase of the case and that provide the ingredients for implementing the case as an ACM process.

note: I am not striving for a complete case definition. I am sure many hotels would use different, more extensive case definitions. This article’s objective is only to provide an example to demonstrate the various constituents of an ACM case definition.


The milestones identified in my fictitious hotel case are:

  1. Booking made: possibly based upon the quote provided to the guest, a booking has been made
  2. Booking cancelled
  3. Cancellation deadline passed: a guest can cancel a booking up 24 hours before the arrival data; when that deadline has passed, the booking enters a new phase: the hotel starts making preparations and the guest has to pay now – even upon no-show or (late) cancellation; note: this is a special milestone, one that is brought about by passing of the time rather than by an event in the case
  4. Guest Checked-in
  5. Check-out performed
  6. No-show declared
  7. Guest Complaint received
  8. Guest Complaint handled
  9. Case Closed

Not all of these milestones will have to be reached in a case instance. In fact, several are mutually exclusive. Some may be revokable: even when the milestone has been reached, the case stakeholders can be decide that on second thoughts it is not reached after all (for example: after no-show was declared, the guest arrives or after the guest complaint as declared taken care of, the guest persists with the complaint).


Various stakeholders can be associated with the case. Whether they will have direct to an automated system that orchestrates the case is not yet determined. However, each stakeholder may directly or indirectly influence the case. Some of these stakeholders are internal (from the viewpoint of the hotel) while others are considered external. Not all stakeholders listed have to be involved with every instance of the case.

  • sales department (handling quotes and accepting bookings)
  • reception desk (handling all interaction with guests during their stay)
  • customer care team (dealing with complaints, guest surveys and follow ups)
  • general  hotel staff (anyone working at the hotel and potentially in contact with the guests)

External stakeholders:

  • guest (the representative of a party of one or more that are part of a booking)
  • guest party member
  • travel agent (mediating between the guest and the hotel in making the booking)

Associated with each stakeholders are permissions: what can they do to the case? This involves the activities the stakeholders can initiate, the data they can see and manipulate and other case related operations they can perform.

Data & Documents

Associated with each case is data. In fact, the whole notion of a case is based upon some core data elements that identify the essence of a case. Typically, documents are associated with a case as well – providing additional evidence, supporting data, communication trail etc. Some data is stored as part of the case – the case payload or the state of the case. Other data is stored apart from the case and associated with it through references from the case data. The case payload is ideally kept small and limited to the data that is required to identify the case, evaluate the rules that determine when milestones are reaches and when activities are available or should be withdrawn. The payload also has to contain the references to the case data stored external from the case.

Case Payload

Data stored in the payload of the case itself includes:

  • booking number
  • guest name
  • arrival date
  • date of departure
  • party size
  • assigned room number(s)

External Case Data

Associated with the case, but stored externally (perhaps in a database) are data such as:

  • the personal details of all party members (note: even though the guests may have stayed in the hotel before, we will store a ‘snapshot’ of these details for each case, to record the immutable state of these details at the start of the case
  • details of the use of hotel services including restaurants, minibar, movies, spa, tennis courts, bars; for each at least a transaction number, the time and the total cost is recorded


For this case of the hotel booking, documents that have been identified include communication (letters, emails, telephone transcripts?) with the guest or travel agent, a copy of the guest’s passport, any bill linked to the room number and signed by the guest, the final bill as made available to the guest.


The case activities describe the “atomic units of action” in the case. A case activity can be a very simple operation or it can represent a complex process. Activities can refer to human actions or to automated process or to a combination of the two.

Many activities in a case are not always available for execution. Only when certain milestones are reached in the case or specific conditions are met, will the activity be applicable. Activities can be withdrawn: when  they are no longer relevant, they should not be presented to stakeholders. Generic activities can always be instigated throughout the life time of the case [instance], though not necessarily by all stakeholders.

Activities are frequently associated with one or more stakeholders (indirectly, via roles and permissions). Stakeholders play a role in an activity; they initiate the activity or play another role.

Other attributes of case activities include whether they are required, can be repeated and are triggered automatically. Of course at some point we have to specify what exactly the actions are that make up the activity – from simple human task to complex BPMN process.

This table contains a number of activities that have been identified for the hotel booking case. The Pre-condition is a first, crude attempt at describing the rules for activating the activity. The same applies to the Triggered Milestone column that is a first stab at the rules for reaching the case milestones.

Pre-conditionGeneric?ActivityTriggered MilestoneStakeholder
YesProvide FeedbackGuest, Travel Agent
YesMake EnquiryGuest, Travel Agent
YesFile complaintM7Guest, Travel Agent
YesAdd commentAll internal stakeholders
YesAdd documentAll internal stakeholders
Not M2, M5NoRequest Price/AvailabilityGuest, Travel Agent
Provide QuoteSales Department
Make BookingM1Guest, Travel Agent
M1, Not M2, Not M3, M5Cancel BookingM2Guest, Travel Agent
M1Update BookingGuest, Travel Agent
M1Book shuttleGuest, Travel Agent
M3Assign a (new)Room & PrepareReception Desk
Not M2Check InM4Reception Desk
M4Review BillGuest, Reception Desk, Sales Department
M4, not M5Room ServiceGuest
M4Check OutM5Reception Desk
M3, not M4Declare No ShowM6Reception Desk
M5Guest SurveyGuest
M4Rate GuestAll internal stakeholders
Follow up customer careM8Customer Care Team
M2 or M8 or (M4 and not M7)Close CaseM9Customer Care Team, Sales Department

Some of these activities are very simple – such as add document or review bill – whereas others represent multi step processes – such as check in and check out. These latter activities are themselves expressed through a BPMN process. The activity ‘Follow up customer care’ that is executed for guests who have filed a complaint and with a random sampling from all satisfied guests – is one that itself represents a case – a subcase so to speak of this hotel booking case.


Rules are an important element aspect of a case. They embody the flow logic of the case. Rules determine when activities are available, both when they become available and when they are withdrawn. Automated activities are executed automatically when a rule decides to trigger them, so rules can drive part of the actual processing as well. Rules are defined in terms of milestones (that have been reached or not), other activities that have been executed and the data of the case.


Rules also determine when a milestone has been reached. Based on similar elements (other milestones, activities and the case data), a rule can trigger the completion of a milestone.

Rules are typically expressed in an IF..THEN format: IF <these conditions are met> THEN <make these things changed or happen>. If multiple rules are created with a similar set of conditions (using the same facts – case data, milestone status, activity status, events – checking for different values), they can conveniently presented in what is called a Decision Table. A very simple example of a Decision Table is shown here:

ConditionsRule 1Rule 2Rule 3
milestones reachedM3, not M4
activities performedcheck incheck out
case datacurrent timestamp > latest checkin time
event occurred
set milestoneM4M5
initiate activitydeclare no show
set case data
trigger custom event


An event in a case is an occurrence of an expected, predefined situation at a certain time and with an associated data context. Many events are generated by simply progressing through a case (instance): reaching a milestone, triggering an activity, completing or withdrawing an activity are all examples of events. Additionally, the definition of a case may include user defined events: events that are specific to the case. These events are explicitly raised, either by stakeholders, from rules or by external systems.

Events are important in a case for several reasons. The events are recorded to provide an audit trail of the case. Events trigger evaluation of the rules that in turn may lead to a  milestone to be declared reached, an activity to be triggered, case data to be manipulated an additional events to be published.

An example of a custom event for the Hotel Booking case could be “Guest has died” or “Technical issues in room”. And if you think about the various episodes of Fawlty Towers I am sure it will be easy to come up with additional events.

Stages or Phases

In many cases, we can discern different phases or stages. Activities may be associated with a specific phase, multiple phases or they can be un-related to phases. There can be a relationship between phases and milestones – but there need not necessarily be. Stages are not always included in a case instance.

In our current case of the hotel booking, several phases are easily identified:

  • acquisition – pre-booking
  • pre-stay – the booking has been made
  • stay – the period during which the guest is actually in the hotel
  • post-stay

Sub-cases or inter-case relationships

Cases can have relationships with one another. When a guest returns multiple times to the hotel, each stay results in a case instance [of the hotel booking case]. These instances are related because of the fact that the same guest is a stakeholder in each of them. At a higher level, the CRM department of the hotel could identify a Guest Case that bundles these case instances together – and perhaps itself involves activities such as send a congratulatory email on the guest’s birthday.

The same hotel booking case instances could also have relationships with other case instances for different reasons. All booking cases during Christmas could be considered bundled or even all cases that have overlap, involve participation in the same conference taking place at the hotel or all involve vegetarians.

When designing the case definitions, one challenge is to get the right the level (or granularity) of the case. Is it a case per guest – involving all stays throughout the life of the guest – or a case per booking and stay. Does my physician have a single case [file] on me as a patient, or is a new case opened for each ailment I come discussing with her. Or do both levels exist with some relationship between them. Acknowledging the various inter-case[-instance] relationships is important. When later on we discuss implementation, our tooling should help case workers with finding out about these relationships and provide functionality to leverage information from one case instance in another.


This article provides an example of how for a specific case – the hotel booking – the essential ingredients that determine the case and the way it is orchestrated could be defined. Once the basic definition of a case is available, in terms of milestones, stakeholders, data, events, activities and rules, we can start thinking about the implementation. In a next article, I will look at the use of Oracle BPM Suite 11g and its built in ACM engine to bring this case to life.


Prequel to this article: ACM: organizing the chaos and flexing rigid process structures through adaptive case management  –

Introduction to Adaptive Case Management, CMMN (the modeling notation standard for ACM) and the CMMN Web Modeler (not free) for visually designing cases –

The ACM Poster from the Masons of SOA (the MSOA team) – outlining all elements of CMMN and there mutual relationships – Also see Torsen Winterberg’s blog:

The CMMN draft specification at OMG (the object management group):

More background on what is/why and when Adaptive Case Management – Case Management: Contrasting Production vs. Adaptive:

One Response

  1. srikant February 9, 2015