Issue

When configuring a custom condition in the Pega Constellation™ custom Condition Builder, properties on two-level nested pages (for example, .Page1.Page2.BooleanProperty) cannot be selected. The second-level page (Page2) does not appear as a selectable option in the Condition Builder UI, making it impossible to define conditions that reference properties at that depth. 

This limitation is most encountered during upgrades from UI-Kit-based applications to Pega Constellation, where existing conditional logic relied on multi-level page references that were valid in the prior architecture. 

Symptoms and Impact

• When you create a custom condition, the property picker doesn't offer properties from pages nested two or more levels deep. 
• Users who upgrade applications from UI-kit to Constellation may hit this when they build complex conditions on nested page properties. 

Steps to reproduce

Step 1: Create the first-level page property (Page1) 

1. In Dev Studio, select Create > Data Model > Property. 
2. Enter the Label (for example, Page 1). In Apply to, select the case (work) class. 
3. Set Property type to Page, and select the Page class for Page1 (call it ClassA). 
4. Select Create and open, then Save. 

Step 2: Create the second-level page property (Page2) 

1. Select Create > Data Model > Property. 
2. In Apply to, select ClassA, the page class you chose for Page1. 
3. Enter the Label (for example, Page2). Set Property type to Page, and select the Page class for Page2 (call it ClassB). 
4. Select Save. 

Step 3: Create the Boolean property 

1. Select Create > Data Model > Property. 
2. In Apply to, select ClassB, the page class you chose for Page2. 
3. Enter the Label (for example, Boolean Property). Set Property type to True/False. 
4. Select Save. 

The full reference is then .Page1.Page2.BooleanProperty,resolved from the case class.

Step 4: Run the Condition Builder 

1. In a Constellation application on Pega Platform 25.1.2, open a view in App Studio. 
2. Add a field to the view and navigate to its visibility or other condition settings.   
3. Select "Custom condition" and open the Condition Builder. 
4. In the field selector, attempt to navigate to the field at two levels of page depth — for example,.Page1.Page2.BooleanProperty.  Result: Page2 is not available for selection within the Condition Builder.  

Root Cause

This is a known platform limitation in the Constellation custom Condition Builder. The data API that drives property population in the Condition Builder fetches and displays properties only up to one level of page nesting. Second-level (and deeper) embedded page properties are not surfaced by this API, so they cannot be selected through the builder UI.  

Solution

A product enhancement request has been logged to add support for multi-level nested page structures in the Constellation custom Condition Builder. This article will be updated when the fix becomes available. 

Workarounds 

Three workarounds have been validated. Each has trade-offs, documented below. 

Option 1 — Create a Mirror Property (Recommended) 

Create a new property at the top level of the case class that mirrors the value of the nested property. Populate this mirror property using a data transform (for example, in a pre-processing data transform or an appropriate lifecycle step). Reference the mirror property directly in the custom Condition Builder. 

Trade-offs: Introduces an additional property to maintain. Requires synchronization logic to keep the mirror property current whenever the nested property changes. 

This approach avoids the two-level nesting constraint entirely and works consistently across views, tables, and update-type forms. 

Option 2 — Edit the View JSON Directly 

For update-type views, the required condition can be added by editing the view's JSON configuration directly. This bypasses the Condition Builder UI and allows the two-level nested path to be written as a raw condition expression. 

Trade-offs: Subsequent changes to the table or view through App Studio may require manual re-editing of the JSON, as the visual editor does not natively support round-tripping conditions written at this depth. This approach increases maintenance complexity for table display configurations. 

Option 3 — Use a When Rule 

A When rule can be used in place of a custom condition to evaluate the nested page property. When rules support deeper property references and can express .Page1.Page2.BooleanProperty is true logic. 

Trade-offs: In the scenario confirmed during case investigation, using a When rule triggered a screen refresh on each field tab-out, which degraded the user experience. This trade-off may or may not be acceptable depending on the specific use case and form behavior requirements.

References

Defining Conditions in the Condition Builder  

Configuring page, page group, and page list properties