Issue

Sharing application-based rulesets across applications leads to unpredictable behavior. 

Symptoms and Impact

When an application-based ruleset is added to more than one application in the application stack (for example, ruleset XXX present in both ABC and PQR), the following symptoms may occur: 

• Rule resolution picks the rule from the top application's ruleset, silently ignoring any overrides defined in the base application. 

• Customizations or overrides made in the base application are bypassed, causing the application to behave unexpectedly. 

• Changes made to the shared ruleset for one application inadvertently affect behavior in another application. 

• Maintenance complexity increases as the shared ruleset becomes difficult to align with individual application requirements. 

Steps to Reproduce

1. Open App Studio or Dev Studio and navigate to your application stack. 

2. Identify a ruleset (e.g., XXX) that is listed in a base application (e.g., ABC). 

3. Add that same ruleset XXX to the top application (e.g., PQR) as well. 

4. Create a rule override in the base application (ABC) within ruleset XXX. 

5. Run the application — observe that the override is not applied; the rule from the top application version of the ruleset is resolved instead. 

Root Cause

Application-based rulesets are designed for use within a single application. When the same ruleset is added to multiple applications in the stack, Pega's rule resolution engine applies standard precedence rules: the rule found in the highest application in the stack is returned first, and any version of the same rule in a lower (base) application is never evaluated. This means overrides configured at the base layer are silently bypassed, producing unpredictable behavior.

Solution

There is no product-level fix for this behavior — it is by design. The recommended resolution is to refactor the shared ruleset into a dedicated application layer: 

1. Identify all rules in the shared ruleset that are common across applications. 

2. Create a new, standalone application (organizational or enterprise layer) to house the shared ruleset. 

3. Add this new application as a built-on application in the stack of each implementation application that requires the shared logic. 

4. Remove the shared ruleset from the individual top-level application definitions. 

5. Validate the application stack using Guardrail compliance and the Validation Tool before promoting higher environments. 

This approach aligns with Pega's Situational Layer Cake and Modular Architecture best practices, ensuring rules are resolved predictably, and each application can safely override shared logic at the correct layer.

References

Best Practice for Test Ruleset Strategy Across Multiple Pega Applications

Governing Shared Components, Rulesets, and Dependencies in Pega Infinity 

Shared Ruleset — Pega Documentation

Rulesets — Pega Documentation

Rule Resolution — Pega Documentation 

Duplicating the Application Rule — Pega Blueprint

Rulesets — Pega Academy