Dynamic Display of Dependent Tables with Default Row Creation not persisted

User Experience
, ,
1

Use Case:
In Pega Constellation 25.1, we have a requirement involving a primary Load table displayed on a single screen. The Load table contains a dropdown column named Type. The Type dropdown includes values such as Charger, Appliances, Motors, etc.

For each Type value, there is a corresponding table (e.g., Charger table, Appliances table, Motors table) defined at the same class level as the Load table.

Key UI behavior:

  • New rows in the Load table are added via a modal dialog (Load table modal).

  • On the modal screen, when a user selects a value in the Type dropdown of a Load row and submits the modal screen, the corresponding table should:

    • Become visible dynamically below the Load table

    • Display with a blank first row, ready for user input

    • Appear on the same screen without navigation

We have already implemented visibility conditions on each of the respective tables, and this part is working correctly. When a value is selected in the Type dropdown, its corresponding table becomes visible as expected.

Issue Observed

The problem arises with adding a blank first row to the respective table when it becomes visible.

  • We attempted to insert a blank row by adding data to one of the columns of the corresponding table using a post-Data Transform configured on the Load table modal flow action.

  • In the Tracer, we can see that the row is being added successfully at runtime.

  • However:

    • The newly added row is not visible in the UI

    • The data has not persisted on the clipboard

    • As a result, the table appears empty despite the Data Transform execution

Requesting your expert opinion on this issue.

2

This may require a deeper look at your configuration, it could possibly be a bug or misconfiguration. Have you raised an incident with Pega Support? (if so please share the INC, so I can delve a little deeper).

Generic Advice

  1. There have been some issues with combining Form Refresh Settings, Visibility Conditions and When Rules in the past. Though its noted it’s fixed in ‘25.1
    1. Some of this is limitations of Form Refresh Settings and some a bug.
  2. Using Customer Conditions will trigger client side, which might solve the issue
  3. Using a Declare Expression can trigger a server call, which might solve the issue
    1. We had a lot of success with this in ‘24 for embedded data, before “modal as action” was introduced in ‘25. RuleNotFoundException for Agent activity | Support Center
      1. image
        image779×1114 121 KB
  4. Configuration of the Embedded Data field (list/table)?
    1. image
      image1738×746 55.5 KB
      1. Is it embedded data? In some of our past discussions, we have seen the use of a Query field type (e.g. not editable)
      2. Is it editable? I have seen attempts by others to make an Embedded Data table ‘not editable’ and then try to programmatically add records with Form Refresh settings. The fact you say the user can’t add records and then try to do this with Form Refresh Settings is conflicting logic, that I think the DX API’s backing Constellation would block as all actions are performed by the user.
1 Like
3

Hi Marc,
Thank you for your quick response.
We are using editable embedded data only, we already have visibility condition on tables. As per your suggestion we had tried adding custom conditions as well. But it didn’t work. Our page structure has few levels of nested page-lists that might be the issue.

The issue is in tracer we can see that data is getting added but in clipboard it’s not persistent and in Ui also its not getting visible.

Today we connected with Di and displayed her the issue. She suggested to raise an SR ticket. We will share the ticket number after creation.

4

Hello @RAHULK0923

Appreciate the time you’ve taken to explain your scenario in detail.

While going through your description, the first question that came to mind was around the actual business requirement, as the current write-up is largely focused on the technical implementation rather than the underlying need.

:receipt: Simplifying the Business Requirement

If I interpret your requirement in simple business terms, it would be something like:

“When a user selects a type (e.g., Charger, Appliance, Motor), the system should automatically display a corresponding section where the user can immediately start entering details for that selected type.”

Alternative Approach (Illustrated with a Different Use Case)

To explain this more clearly, let me take a similar real-world example using Vehicles and Spare Parts.

Scenario

A user needs to:

  • Add multiple vehicles
  • For each vehicle, capture a list of spare parts

Proposed Design

1. Primary Table

Create an embedded table, for example: “Vehicle Spare Parts”

Columns:

  • Vehicle Type
  • Number of Spare Parts (derived)
  • Action (Edit/Delete)

An OOTB “Add Vehicle” button that opens a modal dialog.

2. Modal Dialog Behavior

When the user clicks Add Vehicle:

  • A modal dialog is displayed
  • It contains a dropdown: Vehicle Type (Two Wheeler, Three Wheeler, Four Wheeler, etc.)

Once the user selects a Vehicle Type:

  • A nested table (Spare Parts) is displayed within the same modal
  • This table should be ready with a blank row for input, allowing the user to start entering details immediately

Data Model (Illustrative)

Org-App-Work-CaseRequest
    └── Vehicle (PageList)
            └── SpareParts (PageList)

Behavior Mapping

  • Each Vehicle entry contains its own list of Spare Parts
  • Based on the selected Vehicle Type, you can conditionally render the relevant nested table
  • To ensure a blank row is available immediately, you can trigger initialization logic (e.g., using a refresh mechanism like pyRefreshData) when the type is selected
  • According to the type selected you can show the appropriate embedded table with conditions.
  • Configure the nested table in inline edit mode so users can enter data directly within the modal

User Flow

  1. User clicks Add Vehicle
  2. Selects Vehicle Type
  3. Related Spare Parts table appears with a pre-created blank row
  4. User enters multiple spare parts
  5. Clicks Submit
  6. Modal closes and the vehicle entry is added to the main table

The Number of Spare Parts can be auto-derived (e.g., using a declarative approach)

Edit Capability

  • At any point, the user can click Edit on a vehicle row
  • The same modal opens with existing data
  • User can update Vehicle Type or modify Spare Parts

Key Idea

Instead of managing multiple separate tables at the same level, a hierarchical structure (parent + nested list) simplifies both:

  • UI behavior
  • Data handling

You can match-up the above implementation with your requirement and let us know if this interpretation aligns with what you’re trying to achieve. If your requirement is slightly different, happy to refine the approach further.

Regards

JC

3 Likes
5

HI JC, thank you for quick and detailed response.

Actually, that is the only issue. Our requirement is such that the below tables need to be in the same level (in respect to your example, Vehicle and spare parts needs to be in same hierarcy).

Also, in our actual requirement, the page structure is a bit more complex and have 3 to 4 level nested Page-Lists structure. So, we cannot change the structure. Something like below screenshot:

image
image419×745 49.5 KB

6

@RAHULK0923 You can have any number of levels of embedded lists with constellation where there is not restriction of adding embedded data using modal/inline editing/repeating view depending on how you want to display.

You just have to sit with business and derive how you want the show the data in an optimal way utilizing the grouping feature in the tables

Regards

JC

7

INC-D17379 created for this issue

8

Thanks, I can see you received more details from Pega’s Global Client Support. This is a bug for 25.1.2 :frowning:, fixed in 25.1.3 :slight_smile: (BUG-982260)

As suspected client-side custom conditions would solve this (even as temporary work around).

Will let you continue with the options provided to you for more immediate fixes on the ticket but wanted to share here for anyone who comes across this issue, for their reference.

1 Like
9

HI Marc. thank you for the information. Previously we tried with custom conditions but that didn’t resolve the issue. May be i am missing some configuration step, in our next connect can we take a deeper look on this configuration?

Thank you.

10

@RAHULK0923 Maybe you can try to setup and trace the pyRefreshData DT for each of your embedded classes.

The beauty of pyRefreshData DT is that, you will get the latest data for the case in this DT which executes as the last step before the response from server is sent to the UI.

So, if you want to modify any UI behaviour based on certain custom conditions or when conditions, this is the place where you can control the UI by modifying the caseInfo.content.

Hope this helps you to find a workaround until we get a fix from Pega.

Regards

JC

3 Likes