Issue  

In a Pega Constellation™ UI screen, when records are added to an Embedded page list through a modal dialog, pxCreateDateTime for every existing row is overwritten with the timestamp of the most recently added record. 

Symptoms and Impact  

Every row in the Embedded list displays the same pxCreateDateTime — the value from the last record added. Originally correct timestamps for earlier entries are lost. No error message is shown. The impact is silent data inaccuracy: audit trails, sort orders, and any logic driven by creation time will produce incorrect results. 

Steps to reproduce  

1. Create a Constellation view that displays an Embedded page list in a table. Include a pxCreateDateTime column. 
   1. Configure the Embedded list's Add action to open a modal dialog.
   2. In the modal, include only the user-input fields (for example, a text area for comments). Do not include pxCreateDateTime. 
2. At runtime, open the view and add a first record via the modal. Note the pxCreateDateTime displayed in the table. 
3. Add a second record via the modal.  Result: The pxCreateDateTime for the first record now matches the timestamp of the second record. 
4. Add additional records and confirm that all rows reflect only the most recent submission timestamp. 

Root Cause   

This is expected platform behavior. 

Constellation syncs page list data using pageInstructions sent in the DX API refresh request. When pxCreateDateTime is absent from the modal view, the property is not included in the pageInstructions payload. On each refresh call, the platform defaults pxCreateDateTime to the current date and time for every row in the list because no existing value is carried in the payload to preserve. 

The property is present and correct only when explicitly included in the view so that its value is serialized into the pageInstructions on submission. 

Note: This behavior occurs in unsaved (in-memory) page list state during a session. Performing a full case save between additions preserves each row's pxCreateDateTime correctly, confirming the mechanism is pageInstructions-scoping rather than a persistence bug. 

 Solution  

Local Change (Workaround) 

Add pxCreateDateTime to the modal view used to add or edit Embedded list records and configure it as read-only. 

1. In App Studio or Dev Studio open the modal view (the Add/Edit view for the Embedded data type) . 
2. Add the pxCreateDateTime field to the view layout. 
3. Set the field's Edit mode to Read-only. 
4. Optionally, apply a Visibility condition (for example, a "Not when" rule) to hide the field from the end user while keeping it present in the underlying view structure. 
   1. With the field hidden, pxCreateDateTime is still serialized into the pageInstructions payload on submission.
   2. Each row then retains its original creation timestamp when subsequent records are added. 
5. Save and test by adding multiple records and confirming that each row retains its original pxCreateDateTime. 

Alternative: If a modal-based approach is not required, implement a post-processing data transform at the flow action level to explicitly set pxCreateDateTime for the current row on each submission. 

References

Managing operations on Data Records 

Configuring CRUD data endpoints with Constellation DX API 

Data Reference and Embedded Data save failures in Constellation '24 due to CRUD limitations