Subclass-based Case Creation with Unique Prefix in Pega Constellation

As enterprise applications scale, it's common to manage different types of work under a unified case architecture while still requiring distinct behavior for routing, reporting, or identifier conventions. Pega Constellation supports this need through subclass-based case instantiation — allowing developers to create work objects in specialized subclasses while retaining a centralized case design in the parent class.

Objective

Enable case creation in specialized subclasses (e.g., ORG-RM-Work-Request-STD, ORG-RM-Work-Request-FOC) with unique case ID prefixes, while keeping all core case design and logic centralized in the parent case type (ORG-RM-Work-Request).

Additionally, dynamically customize the Create menu in the left navigation with meaningful labels for each subclass.

Architecture Summary

• All case configuration (lifecycle, flows, views) resides in ORG-RM-Work-Request.
• Subclasses (STD, FOC, etc.) are created only for:
  • Defining unique case ID prefixes
  • Supporting class-based routing and reporting
• No separate Case Type rules exist for subclasses.
• Cases are instantiated in the child class, but behavior is governed by the parent case type.

Case ID Prefix Configuration

• In the Application rule, define prefixes:
  1. ORG-RM-Work-Request-STD → STD-
  2. ORG-RM-Work-Request-FOC → FOC-
• During case creation (via AddWork), Pega invokes GenerateID, which uses this prefix in the following order:
  1. From Application rule entry (highest priority)
  2. From .pyWorkIDPrefix (if set via pyDefault in subclass)
  3. Defaults to C-, W-, or T- depending on class hierarchy

The Challenge: Unclear Labels in Create Menu

When child classes are added to the Application rule:

• They automatically appear in the Create menu.
• But the label used is that of the parent case type (e.g., "Request")
• Not something intuitive like "Standard Request (STD)" or "Free of Charge Request (FOC)"

Options to Customize the Create Menu

Option 1: Customize D_pxAvailableCaseTypesForPortal Using a Wrapper Data Transform

How it works:

• Override logic that powers D_pxAvailableCaseTypesForPortal, which in turn uses the final activity pxPopulateAvailableCaseTypes.
• Create a wrapper Data Transform to update .pyLabel based on .pyClassName.

Pros:

• Minimal duplication — Application rule continues to manage case prefix.
• Clean label updates via a central rule.
• Reuses existing Constellation navigation pipeline.

Cons:

• pxPopulateAvailableCaseTypes is a final activity — subject to change in future versions.
• Needs careful maintenance and documentation.
• Not officially extensible — platform upgrade may break logic.

Option 2: Use D_pyCreateMenuAdditionalEntries (Recommended Extension Point)

How it works:

• Do NOT configure subclass entries in the Application rule.
• Extend pyPopulateCreateMenuAdditionalEntries in your app ruleset (invoked by D_pyCreateMenuAdditionalEntries).
• In subclass pyDefault Data Transform, set .pyWorkIDPrefix as needed.

Add entries to .pxResults[] with:

• .pyClassName = ORG-RM-Work-Request-FOC
• .pyLabel = Free of Charge (FOC)

You can store and delegate these entries using a Decision Table or Data Type for maintainability.

Pros:

• Fully supported and documented extension point.
• Allows dynamic, multilingual label configuration via Field Values.
• Clear separation of concerns and declarative configuration.

Cons:

• Logic is spread across:
  • pyDefault (for prefixes)
  • pyPopulateCreateMenuAdditionalEntries
  • Delegated table or data type
  • Application rule (for other cases)
• Slightly higher setup and documentation effort

Best Practices

• Use Option 2 if your application emphasizes upgrade-safe, low-code extensibility.
• Reserve Option 1 only for tightly controlled environments or quick prototype solutions.

🔧 Pro Tip: Document class-to-label mapping and prefix configurations in a shared design artifact or within your delegated data type.

Conclusion

Both options enable dynamic subclass-based case creation with unique prefixes and labels in Constellation. Your choice depends on:

• Desired upgrade compatibility
• Need for custom labeling logic
• Governance model for configuration vs. customization

Opt for declarative patterns when possible — they promote reusability, clarity, and future-proofing.