Skip to main content

Designing the case hierarchy

3 Tasks

1 hr 30 mins

Visible to: All users
Advanced Pega Platform '23 English


Metro Delivery Company (MDC) is a B2B company whose core business is delivering same-day Intracity shipments originating from registered business partners to their destination.

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


  1. Business partner registration to enable business partners to register with MDC.
  2. Truck vendor registration for partnerships with MDC to provide trucks for shipping.
  3. Delivery requests to enable business partners to request trucks to ship goods.
  4. Truck requests to accommodate the goods of business partners.
  5. Invoices to business partners to receive payments for registration, delivery service, and vendor payment.

Extensibilitythese processes must be built to support extensibility to moving services.

ReportingReports on the number of products delivered by partner; profit reports need to be available.

Security Data must be secured between the city managers and accountants.

Review all viable design options and list the pros and cons of each to produce a recommendation for the most appropriate case structure for the application.

The following table provides the credentials you need to log in to the Delivery Service application. However, this challenge is mainly meant for evaluating the design options, and there are no specific implementation tasks. 

Role User name Password
Admin admin@deliveryservice rules

You must initiate your own Pega instance to complete this Challenge.

Initialization may take up to 5 minutes so please be patient.

Detailed Tasks

1 Identify design options

Single case with subprocesses (subflows)

A single Delivery Request case cannot fulfil the process requirements due to case locking issues, which prevent multiple users from updating the case simultaneously. Although the extensibility and reporting requirements are easily met, and the User Interface (UI) requirement may be satisfied with independent data objects tracking each request, updating the status of each request requires extra work. Optimistic locking can solve the problem, but it may not be optimal as it could detract from the user experience during case processing.

Single case with child cases (subcases)

Another alternative is a Delivery Request top-level case with multiple instances of Truck Request subcases (depending on capacity). Each Truck Request can initiate an Invoice case. Modifying the default locking scheme to lock subcases independently of their parent solves the locking problem and allows parallel processing without interruption.

A hierarchical child case is not best practice because delivery requests are initiated by either a gold, silver, or bronze partner, the leftover capacity on a truck cannot be utilized because one truck request cannot be a child of another delivery request case initiated by a different partner.

Multiple cases (with subflows/processes)

A viable alternative is to create multiple top-level cases for delivery requests, truck requests, and invoice generation. Partner registration and vendor registration can be separate cases initiated by using a web embed from the MDC website. A delivery request case can initiate multiple instances of truck request cases depending on the capacity of the shipment. Each truck request can initiate an invoice.

Circumstanced top-level case (with subflows/processes)

A third alternative is to provide delivery partners with a self-service request feature, by using a web embed channel in the delivery request case circumstance. When the delivery partner places an order from the Place Order stage, it moves to Freight Fulfillment to place the truck request. This requires an additional screen to capture delivery partner details on the case and could be a security constraint too.

As such, this is not a suitable design.

2 Evaluate design options

Pros and cons of each design option

Design Pros Cons
Single case with subprocesses (subflows)
  • Simple design
  • Fewer cases/case types
  • No data replication or propagation
  • Simpler reporting
  • Locking is an issue
  • Larger BLOBs
  • All data visible to case
  • UI is more challenging
  • Specialization options are limited
  • Processes are tightly coupled
Single case with child cases (subcases)
  • No locking issues with reconfigured locking.
  • Selected data propagation copies only required data to subcases.
  • Higher level of detail in reporting by case
  • Can make use of dependency management if wanted.
  • More cases created to process a delivery request (more records in database).
  • Coordination of child cases with top-level case is more complicated.
  • Sharing of data between cases potentially required.
  • Cannot achieve requirement when truck capacity is left over.
Multiple cases (with subflows/processes)
  • More detailed reporting on cases
  • Each case has flexibility to define its own workflow.
  • Easy for future extensions
  • No locking issues with reconfigured locking
  • Selected data propagation copies only
  • More options for specialization
  • More cases created to process a delivery request (more records in database)
Circumstanced top-level case (with subflows/processes)
  • Self-service request capability provided to the delivery partner.
  • Fewer cases. No need to associate two top-level cases with each other for the same delivery request.
  • Unauthenticated login, no record of customer.
  • Need to build separate screens.
  • Locking issues.

3 Recommend the best design option

A delivery case with subcases is preferred because:

  • MDC has multiple departments: Truck Management, Delivery Services, and a Finance Department. Creating different applications with cases for each application provides modularity and the applications can be run independently.
  • Delivery request and truck request cases promote reusability and extensibility.
  • Individual processes for different departments/LOBs can be established, making routing and approvals easy.
  • Using web embeds for partner and vendor enrolments as separate cases.
  • Application locking requirements should be considered.
  • Each case offers more specialization options, making the application more accommodating of future requirements.

Confirm your work


Available in the following mission:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

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