Skip to main content

Designing the case hierarchy


2 Tasks

10 mins

Visible to: All users
Advanced Pega Platform 8.3.1 English
This content is now archived and is no longer updated. Progress is not calculated. Pega Cloud instances are disabled, and badges are no longer awarded. Click here to continue your progress in the latest version.


Front Stage has analyzed their requirements regarding hosting outdoor events, also known as weather prep, as well as the need to issue requests to different hotels to have a block of rooms reserved for that event. Weather monitoring is included in the price of an event. Hotel booking and parking are offered as optional services at additional charges.

Analyze the key requirements for this application . The key requirements to consider are:

Processes – The weather prep, hotel rooms request, and parking services functionality must be able to execute independently .

Extensibility – It must be possible to extend the booking application to support different types of venues.

Reporting – Reports for events should be defined that display revenue, cost, and profit (profit by event type)

Data – Facilities users must not be able to see financial information.

UI – Customer quotation, event manager review, and hotel booking screens.

Review any viable alternative designs listing the pros and cons of each to produce a recommendation on the most appropriate case structure for the application. Make a list of questions to ask Front Stage. This may help produce a design that satisfies the current requirements and accommodate future requirements with minimal refactoring.

Detailed Tasks

1 Solution detail

An Event case with subcases is preferred because it:

  • Fully satisfies the application locking requirements
  • Make it easier to satisfy the UI requirement
  • Helps make the application more accommodating to future requirements because subcases offer more specialization options

2 Alternative approaches

Single Case with subprocesses (subflows)

A single Event Case does not satisfy the processes requirements due to locking issues. The extensibility and reporting requirements are easily satisfied, and the UI requirement may be satisfied with independent data objects tracking each hotel. However, extra work is required to update the status of each hotel.

The data requirement could be satisfied by obfuscating the data for the facilities users, but this is not an optimum solution for securing data.

The processes requirement, however, could not be fully satisfied due to case locking since this prevents two users from updating the cases at the same time. Optimistic locking could be implemented in order to remedy the problem, but this may not be an optimum solution since it may detract from the user experience during case processing. This problem may be exacerbated if additional services are added.

Single Case with child cases (subcases)

A viable alternative is an Event top level case with subcases for services (currently Weather, Hotel, and Parking). Modifying the default locking scheme to lock subcases independently of their parent would solve the locking problem and allow parallel processing without interruption. This also lends extensibility of the design as it may be easy to handle additional services. Consider handling the coordination of the subcase resolution with the main case using this solution. Hotel subcases should complete prior to the event starting, and the Parking case is active during the actual event and possibly after. Also consider the effect of adding additional services in the future.

Multiple cases (with subflows/processes)

An alternative to the single top level event case is having a separate quote case provide the initial quote. If approved, a peer Event case is created. This provides the possibility of only creating an event case if the event is approved by the customer and executives.

Conditionally creating top level case (with subflows/processes)

Another alternative is providing a quote to the customer on the first screen using the New harness. If the customer approves the quote, a top level case is created and is routed for approval. If the quote is not approved, the quote dies and is never persisted.

Pros/cons of each approach

Design Pros Cons
Single case with subprocesses
  • Simple Design
  • Fewer cases
  • No data replication or propagation
  • Simpler reporting
  • Locking is an issue
  • Larger BLOBs
  • All data visible to case
  • UI requirement for hotels is more challenging
  • Specialization options limited
Single case with child cases
  • No locking issues with reconfigured locking
  • Selected data propagation copies only required data to subcases
  • Finer grained reporting by case
  • More options on cases and subflows
  • UI requirement for hotels easy to implement
  • Extensible
  • Can leverage dependency management
  • More options for specialization
  • More cases created to process an event (more records in database)
  • Coordination of child cases with top-level case more complicated
Multiple cases
  • Finer grained reporting of quote versus event cases
  • More cases created to process an event (more records in database)
Conditionally creating top level case
  • Case created only when Event approved by customer
  • Fewer cases
  • No record of rejected quotes

Available in the following mission:

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice