I’m working on a Constellation UI scenario where a dropdown needs to display values from sibling elements inside .Questions().Fields(). The user should be able to add new questions and fields and immediately select them - without submitting the assignment.
Here’s the challenge:
Starting with Pega 24.1, data pages invoked from Constellation UI run in an atomic requestor context and do not have access to the case clipboard. This means the data page cannot directly reference case properties unless we pass them explicitly.
The dropdown source is a data page, but since there’s no case context, I serialize .Questions().Fields() into JSON using pyRefreshData and pass it as a parameter (RefFieldsJson). The data page deserializes this JSON and builds the dropdown options.
This fails during interactive refresh call. Why? Because RefFieldsJson is hidden and computed, not user-edited, so it’s excluded from the client-server payload. Pega ConstellationJS client only sends properties that are:
As a result, the data page loses context during submit, and the save operation breaks.
What I’ve considered
Forcing hidden properties into the payload (developing custom DX component) - rejected (risk of data inconsistency and unpredictable merges).
Saving data on every refresh - rejected (violates volatile data principle and risks overwriting in-flight edits).
Questions for the community
Why does the atomic context exclude case data even when the source is case-derived?
Are there best practices or patterns for passing dynamic context in Constellation UI without breaking its principles?
My thoughts on possible improvements
Native support for optimized JSON context passing: A declarative way to define structured JSON properties that Constellation automatically serializes and includes in refresh and submit payloads.
Optional case-context inheritance for data pages: A toggle for scenarios where the data source is inherently tied to the case.
Clearer documentation: Especially around property lifecycle during refresh and submit, and how pyRefreshData fits into this flow.
Has anyone faced this challenge? How did you solve it? Do you see better approaches or agree that platform-level enhancements are needed?
@Sergei Kart i’m unclear on why they need it all on one screen? Even the Questionnaires function has 2 different screens for this type of Fields + Question building.
Create fields
Group fields into questions
I’ve seen this kind of outcome built a few times, be good to get more details on what you are trying to achieve? Others have done this on Data, so the can do List Views and CRUD actions on data. Which, again, would have it in two different objects and not create the technical problem you are outlining (but still achieve the business need)
A partial answer, you can use embedded data as a picklist, this one is little known. What I am unsure of, and would need to test, is what happens if the embedded data is in the same form. I’ve only ever configured this when it was captured in a prior step, thus committed data. Given this is an OOTB control, it may well take it directly from the redux store / caseinfo.content api, so it might work for you.
Thanks for the detailed response - let me clarify my use case and why I was trying to keep everything on a single screen.
I have a list of questions stored in a Page List property. Each question is created via a modal dialog.
For each question, I can define a list of fields, also created via a modal and stored as an embedded Page List under that question.
For every field, I need to define visibility conditions. These conditions can depend on:
a field in the same question, or
a field in another question.
On the UI, the “source value” populated from the list of all defined fields (across all questions) is used in the visibility condition and selected from a drop-down that shows the available fields.
Regarding the feature you mentioned (Configuring a combo-box to select one option from a manually added list): I’m aware of it and have tried to use it, but I’m hitting a limitation with the context.
The combo-box source can only be configured within the context of the current data type / page. That means I can refer to properties on something like:
.Question(1).Field(1).AllFields()
but I cannot reference properties on:
.Question(2).Field(), i.e. a sibling question / field.
The context page configuration in Constellation doesn’t allow me to step outside the current context to other items in the Page List. So I can build a list of fields for the property located on the current field page in the current question, but not a combined list of fields across all questions.
You can see the same limitation if you follow the examples in the documentation or try to set this up in a test environment: the combo-box configuration is restricted to the current data context, not sibling pages in the list.
If there’s a pattern you’ve seen that bypasses this context restriction (while still allowing cross-question references), I’d be very interested to see it.
@Sergei Kart thanks for clarifying. No, i haven’t seen anyone implement this kind of overlapping embedded data in a single form. I’ve only seen this done as CRUD on data in different landing pages (which avoids the issue all together).
Hopefully someone else in the community can share their experience!
