Case hierarchy and relationships

Case relationship decisions build on one another. First determine whether related work benefits from independent Case management. Then establish how related Cases are created, what information they require, how progress is coordinated, where dependencies exist, when information should be provided through hierarchy or reference, and how duplicate work should be identified.

As the Tour Booking design becomes more detailed, Elena begins describing related work that contributes to the overall booking outcome in different ways. Some work can remain within the Tour Booking Case and progress as part of the booking journey. Other work may benefit from being managed as a separate Case Type with its own participants, timing, visibility, progression, reporting, security requirements, or outcome.

Experienced Solution Designers listen for signals that help determine whether independent Case management would create value. Different participants, separate timing requirements, independent progression, reporting needs, security boundaries, reuse opportunities, and explicit dependencies can all indicate that a related Case Type should be evaluated. The goal is to determine how the work can be managed most effectively while continuing to support the broader business outcome.

As Elena describes the booking operation in more detail, several relationship signals begin to emerge. Guardian consent introduces different participants, its own progression, and a dependency that affects whether the booking can continue. Equipment preparation may support multiple bookings rather than a single Tour Booking journey. Duplicate requests introduce the need to identify existing work before creating new work.

These observations do not determine the design by themselves. Instead, they provide signals that help the Solution Designer evaluate whether related work should remain within the Tour Booking Case or be represented through a related Case Type. The next step is to determine which signals justify independent Case management and which are better addressed within the Parent Case.

Evaluate the initial interpretation

To evaluate the initial interpretation, consider the following questions:

• What outcome does the related work deliver?
• Can the work start, progress, and resolve independently or in parallel?
• Does it involve different participants or ownership?
• Does it follow a different timing or reporting need?
• Could the Case Type be reused from another Parent or initiated separately?
• What must the Parent Case know before it can continue?

The relationship signals identified in Elena's account now need to be evaluated. Some signals indicate that related work deserves closer attention, although they do not automatically mean that a separate Case Type is required.

The Solution Designer's task is to determine whether the work remains clearer as part of the Tour Booking Case or whether it benefits from being managed separately while continuing to contribute to the overall booking outcome. The decision depends on the nature of the work and the value created by managing it independently rather than on how much work is involved.

For example, a substantial area of work can remain within the Parent Case when it follows the same outcome, progression, participants, and management model. Conversely, a relatively small piece of work may justify separate Case management if it introduces distinct responsibilities, dependencies, security requirements, reuse opportunities, or operational visibility needs.

Use the following design signals to evaluate whether related work is best represented within the Parent Case or as a Child Case:

Elena's examples illustrate why Child Case decisions require evaluation rather than rules. Guardian consent introduces different participants, dependencies, and visibility needs. Equipment preparation raises questions about reuse and shared operational work across multiple bookings. These signals help the Solution Designer determine whether the work remains clearer within the Tour Booking Case or benefits from separate Case management.

The strongest Child Case candidates usually combine several design signals that point toward the same conclusion. The goal is not to maximize the number of Child Cases. The goal is to represent the business clearly while keeping the overall Tour Booking outcome understandable.

Once the need for a Child Case has been established, the focus shifts from Case boundaries to Case coordination.

A Child Case contributes to the Parent outcome through a defined relationship. The design needs to make clear when the Child Case begins, what information it needs from the Parent, what progress remains visible, what outcomes the Parent depends upon, and how exceptions affect the broader business transaction.

These decisions determine how independently managed work remains connected to the overall outcome.

Place the Create Case Step where enough information is available and the related work should begin. In Tour Booking, it can create a Guardian Consent Case for each participant who requires consent. Each Child Case progresses independently while its status and outcome remain visible to the Parent.

The following figure shows how a Parent Tour Booking Case creates and coordinates Guardian Consent Child Cases while retaining visibility into their status and outcomes:

Use the following questions to establish how the Parent and Child Cases will operate together:

Elena's Guardian Consent example illustrates several of these relationship decisions. The booking may require one consent request or several, depending on the participants involved. Each consent Case requires information from the Tour Booking Case, progresses independently, and produces an outcome that may affect whether the booking can continue.

The relationship design therefore extends beyond creating the Child Case. It also establishes what information is shared, what progress remains visible to the Parent, which outcomes matter, and how the Parent responds when the Child does not complete as expected.

Govern Agent-supported Case selection and initiation

Once the relationship design is established, the next consideration is how related work begins. In many situations, the Parent Case creates the required Child Case directly. In other situations, an Agent may participate in identifying when approved related work should be initiated.

An Agent may evaluate available Case context and select or start related work from a set of authorized Case Types. This provides another way for governed related work to begin. The approved Case Types, relationship design, outcomes, ownership model, and dependency requirements remain established through Case Design. The Agent participates within those boundaries rather than defining them.

Applied to Elena's account, an Agent reviewing booking information may identify that additional operational work is required. Where the permitted Case Types and initiation conditions have been defined, the Agent can initiate the appropriate related Case and provide the information needed to begin the work. Tour Booking still requires a clear relationship to that Case, visibility into the information or outcome it depends upon, and an agreed response to the outcome that is returned.

Decide how the Child uses Parent information

Creating a Child Case establishes the relationship. The next design decision is determining how information is shared between the Parent and Child.

Some information is needed only when the Child Case begins. Other information may continue to change while both Cases remain active. The relationship design should make clear which information represents the starting context for the Child and which information should remain aligned as the Parent Case changes.

Use data propagation when the Child requires a copy of selected Parent information when the Child Case is created. Use a data reference when the Child should continue to use information that may change after the relationship has been established. Data propagation creates a snapshot at the point of creation. Data references allow the Child to continue using information that remains current in the source Case.

For Guardian Consent, participant identity and booking reference information may be propagated when the Child Case is created. Information that should continue to reflect booking changes may remain referenced.

Evaluate the relationship design

• When should the related work begin?
• What information does the Child need when it is created?
• Should that information remain fixed or continue to reflect changes in the Parent?
• What progress or outcomes must remain visible to the Parent?
• Which Child outcomes affect the Parent's progression?
• How should the Parent respond when Child work completes, fails, is canceled, or remains incomplete?

A Parent Case may depend on information, status changes, or outcomes produced by related Cases. When that dependency affects progression, the design should make it clear what the Parent is waiting for and what allows work to continue.

In Elena's Tour Booking scenario, Guardian Consent Cases can progress independently after they are created. Before the tour can proceed, however, the required consent outcomes must be known. The booking therefore depends on work being completed outside the Parent Case.

Use the following options to represent these dependencies clearly:

Dependencies should be defined from the business outcome the Parent requires. Begin with what the Parent needs in order to continue. The required information, status, outcome, or event defines the dependency and helps determine how that dependency should be represented in the design.

For Guardian Consent, the Parent may need to wait until all required consent Cases reach an accepted outcome. A weather review may introduce a different dependency, where progression depends on a specific date or time rather than another Case outcome.

These decisions make dependencies visible to stakeholders and help ensure that related Cases coordinate in a way that reflects the business accurately.

Evaluate the dependency

To evaluate the dependency, consider the following questions:

• Is the Parent waiting for one Child Case or all Child Cases of a defined type?
• Which Child status or resolved outcome allows the Parent to continue?
• Should the Wait Step consider the current Child status or only a later status change?
• Will the required Child Cases exist before the Parent reaches the Wait Step?
• Can an authorized user cancel the wait and continue?
• What visibility do users need while the Parent waits?

Parent-Child relationships are one way to connect related work. They are appropriate when one Case creates, coordinates, or depends on work that contributes to its broader outcome.

Not every Case relationship requires hierarchy. Sometimes a Case needs information from another independently managed Case. In other situations, the solution needs to identify whether the same work already exists before creating a new Case.

The following sections examine these non-hierarchical Case relationships.

Access information without creating hierarchy

A Case may need information from another Case without creating, owning, coordinating, or depending on that work as part of its own outcome. In these situations, the design focus shifts from managing related work to obtaining information from work that is already being managed elsewhere.

A Case reference data relationship allows one Case Type to request information from another Case Type without creating a Parent-Child relationship.

In Elena's Tour Booking scenario, a booking may need information from an Equipment Preparation Case that supports the same departure. The booking needs to understand whether equipment is ready, although it does not create, own, or manage that work.

The Equipment Preparation Case remains accountable for its own outcome and may support several bookings at the same time. Tour Booking simply uses the information needed to determine whether the customer's trip can proceed. This is different from a Parent-Child relationship because Tour Booking is not creating or controlling the Equipment Preparation Case.

Evaluate the relationship

To evaluate the relationship, consider the following questions:

• Does the Case need to manage the related work or only use information from it?
• Does the related Case have its own outcome, ownership, and lifecycle?
• Could the related Case support multiple Cases at the same time?
• Is the required information about another Case or about a business entity?
• Would a Parent-Child relationship create unnecessary ownership or dependency?
• What information must remain visible to support the business outcome?

Prevent duplicate Cases

Related Cases are not the only way Cases interact. The solution may also need to prevent the same work from being managed more than once. Before a new Case is created, the business should be able to identify when an existing Case already represents the same work. This helps avoid repeated effort, conflicting outcomes, and unnecessary operational activity.

Duplicate Case search begins with the business definition of the same work. A Search Duplicate Cases Step compares selected properties from the new Case with Cases already in the system.

Basic conditions identify values that must match. Weighted conditions contribute assigned values toward a matching threshold. Together, the conditions determine which existing Cases are shown as possible duplicates.

Elena may receive the same booking request through the website and the call center. Duplicate Case search can compare the lead customer, tour package, departure date, and party size, while weighted conditions help identify likely matches when contact details differ. A possible match gives the user a chance to decide whether this is separate work or a duplicate of an existing booking.

The following figure shows how duplicate Case detection compares a new booking request with existing Tour Booking Cases and routes a potential match for user review and resolution:

Define the duplicate test and response

To define the duplicate test and response, consider the following questions:

• What does the business consider to be the same booking request?
• Which property values must match as basic conditions?
• Which weighted conditions contribute to the matching threshold?
• How recent must the existing Case be?
• When are similar requests valid separate Cases?
• What should the user do when a possible duplicate is identified?

The user can confirm that the current Case is separate and continue it, resolve the current Case with Resolved-Duplicate status, or, where the solution requires it, continue work from the original Case.

By this point, the Tour Booking design includes both hierarchical and non-hierarchical Case relationships.

Some related work remains within the Parent Case. Some work is managed through Child Cases with their own lifecycle and outcome. Other relationships allow a Case to obtain information from independently managed work or prevent the same work from being created more than once.

Review the complete design as a connected model. Confirm that each relationship exists for a clear business reason and that the resulting Case architecture remains understandable to stakeholders.

Review the connected design

To review the connected design, consider the following questions:

• Does each Case Type represent a distinct business outcome?
• Does each Child Case create value through independent management?
• Is the Create Case Step positioned where the related work should begin?
• Are Parent and Child information needs represented appropriately?
• Are dependencies and waiting conditions clear and necessary?
• Is a Wait Step distinguished from an outstanding Assignment?
• Is a Case reference used only where hierarchy is not required?
• Does the duplicate search reflect the business definition of the same work?
• Where an Agent may select or start related work, are the approved Case Types and initiation conditions clear?
• Does Agent-supported initiation preserve the established Case relationships, outcomes, ownership, and dependencies?
• Are participant-confirmation requirements explicit where needed?

Case relationships help the Solution Designer determine how related work contributes to a broader business outcome.

Some work remains within the Parent Case. Other work benefits from independent Case management through Child Cases with their own lifecycle, participants, timing, and outcome. Parent and Child relationships require clear decisions about creation, information sharing, visibility, coordination, and dependency management.

Not every relationship requires hierarchy. A Case may reference information from another independently managed Case, and duplicate Case search helps ensure that the same work is not managed more than once.

Experienced Solution Designers evaluate the business value created by each relationship, make dependencies and outcomes explicit, and preserve enough design intent for stakeholder validation and Authoring.

The previous topics established the Tour Booking design: the business outcome, lifecycle, Workflow behavior, Work Orchestration, and Case relationships that support it.

Topic 5 shifts focus from design decisions to implementation awareness. You examine how Pega Blueprint™ represents those decisions, how they are translated into Pega Infinity™, what Blueprint import provides, and where reuse should occur at the Case, Rule, data, integration, or other asset level.

Check your knowledge with the following interaction.