Understanding Embedded Data Record-Level Conditions

[TessPorter]

Hello!

I’m working on adding an embedded data property (list type) to a view within one of our workflows. I’ve successfully added the property to the view, configured the displayed columns, and set up the appropriate view for add/edit actions. However, I’m running into issues correctly implementing the record-level conditions that control when the Edit and Delete actions are visible.

Regardless of how I configure the custom condition builder, the Edit and Delete actions either always appear or never appear. The conditions don’t seem to evaluate at the individual record level as expected.

To illustrate the issue with a simplified example (not my exact use case): imagine a column named Year where a row might contain the value 2026. If I configure the condition so the Edit/Delete actions only display when Year = 2026, I would expect those actions to appear for that row. Instead, even when the value matches, the actions remain hidden.

Is there something specific about how record-level conditions evaluate embedded list data or reference row values that I might be overlooking? Any guidance or recommended approach would be greatly appreciated.

My team and I are building our application in Pega 24.2 with Constellation.

Thank you!

[JayachandraSiddipeta]

Hi @TessPorter

I verified this behavior in Pega Platform 24.2, 25.1.1, and 25.1.2, and the configuration works as expected when the conditions are defined in the correct context.

Below is a brief explanation of how conditions work for Embedded Tables in Constellation. Same applies to Repeating rows as well.

---

1. Table-Level Conditions

The Allow conditions for Add, Edit, Delete, and Reorder actions are evaluated from the case (work) context.

This means any condition written here is evaluated against the entire table, not against an individual row.

For example, suppose you create a When rule in the case class like this:

@IsInPageList("TST", ".AssetTag", .EquipmentDetails)

and configure it under Allow Editing.

At runtime, Pega evaluates whether any record in the table satisfies the condition.

• If at least one record matches, editing will be enabled for all rows in the table.
• If no record matches, editing will be disabled for all rows.

So these conditions effectively act as table-level controls, not record-level controls.

---

2. Record-Level Conditions

If the requirement is to control Edit/Delete visibility per row, the condition must be written in the data object’s class (the class of the embedded page).

For example, if the embedded list class contains a property .AssetTag, you could define a When rule in that data class:

.AssetTag == “TST”

When this rule is applied to Allow Editing/Delete, Pega evaluates the condition for each record individually.

As a result:

• Only rows that satisfy the condition will show Edit/Delete
• Other rows will not show those actions

---

3. When Both Conditions Exist

If you configure both:

• Table-level condition (case class and can also access data class fields as well)
• Record-level condition (data class)

Then the record-level condition takes precedence for the individual row, while the table-level condition acts as a broader gate.

---

Additional Recommendation

Whenever you implement conditional behavior such as Add/Edit/Delete/Reorder visibility, it is generally better to use When rules instead of inline Custom Condition Builder expressions.

Benefits include:

• Better readability
• Improved reusability
• Easier maintenance
• Ability to implement more advanced logic

This approach also reduces long-term development and troubleshooting overhead.

Below are few snapshots from my execution in 24.2

Only Conditions in action

Both conditions and record level conditions in action

View Configuration

Hope this helps

Regards

JC