Understanding Microjourneys in Pega: Case vs Data Type Modeling

When designing applications in Pega, one of the most common questions architects face is:

• What exactly is a Microjourney®?

• Does every Microjourney always result in a Case Type?

• Or can it sometimes just be about managing data?

• Can multiple Microjourneys combine into one case, or can one Microjourney split into many cases?

Let’s explore these questions step by step.

What Is a Microjourney?

A Microjourney is a unit of work that delivers a meaningful business outcome to a customer or user. It’s the building block of the Pega Express™ delivery approach.

But here’s the key insight: not every Microjourney has to be modeled as a Case Type. Depending on the business outcome, a Microjourney can lead to:

• A single case

• Multiple cases (main + subcases)

• Many Microjourneys feeding into one case

• Or even just a data type, if no workflow orchestration is required

When a Microjourney Results in a Case

A Microjourney should be modeled as a Case Type (or multiple Case Types) when the business outcome requires work orchestration — meaning there are tasks to be routed, approvals to be captured, SLAs to be enforced, or multiple parties/systems to be coordinated. If the outcome involves a lifecycle of work that must be tracked from start to finish, then a Case Type is the right design choice.

One Microjourney → One Case Type

• Example: Leave Request Microjourney → Leave Request Case

• Straightforward, single lifecycle.

One Microjourney → Multiple Case Types

• Example: Employee Onboarding Microjourney may involve:

  • Onboarding Case (main)

  • IT Setup (subcase)

  • Payroll Setup (subcase)

  • Compliance Check (subcase)

• Together, these cases deliver the single outcome: “Employee is fully onboarded.”

Multiple Microjourneys → One Case Type

• Example: Update Address and Update Contact Info Microjourneys → handled inside a single Profile Update Case.

• Different journeys, but the same lifecycle container.

When a Microjourney Results in a Data Type (Not a Case)

A Microjourney should be modeled as a Data Type when the business outcome is about capturing, storing, or referencing information rather than orchestrating work. If no approvals, routing, or lifecycle tracking are needed, then a Data Type is sufficient.

Examples

• Maintain Employee Skills Catalog → EmployeeSkills Data Type

• Maintain Country Holiday Calendar → HolidayCalendar Data Type

• Maintain Product Catalog → ProductCatalog Data Type

Here, the Microjourney analysis shows that the business outcome is data availability, not workflow.

Case vs Data Type — How to Decide?

• Case Type → Use when the Microjourney involves work orchestration (approvals, SLAs, routing, multiple parties).

• Data Type → Use when the Microjourney is about reference data management or supporting information that other cases consume.

Conclusion

A Microjourney is flexible. It doesn’t always equal a Case Type.

• Sometimes it’s one case, sometimes many cases, and sometimes just data.

• The role of the LSA is to analyze the business outcome and decide the right modeling approach.

By starting with the question “What is a Microjourney all about?” and then analyzing its outcome, you ensure your Pega design is lean, efficient, and business outcome driven.