Conversation
Coforge DPA
IN
Last activity: 5 Jan 2026 13:56 EST
Optimizing Common Property Design in Pega Constellation
We have a common status property (eg..) defined in the enterprise (common) class. In the traditional UI Kit, the dropdown options for this property vary by case type: we keep the property at the common class, and in each specialized case type’s section we source the options from a case-specific data page.
In Constellation, however, implementing this pattern typically requires changing the property to a dropdown control and wiring it to case-specific data pages within each specialized class. Is there a way to achieve case-type-specific dropdown values in Constellation without creating specialized properties at the class layer?
Novitates
IN
@SatishKumarUdamala I have created a post with working example for your question. Please check and let us know if you have any further questions.
Case-Type-Specific Dropdown Values in Constellation Using a Single Property
Thanks
JC
Coforge DPA
IN
@JayachandraSiddipeta The detailed approach mentioned works when the property is of a dropdown for different case types. In our scenario, the property is used as a dropdown in few case types and text input in other case types. Any ideas for a solution in this scenario?
Novitates
IN
@SatishKumarUdamalaIf you property has to show different dropdown options for different case types, you may want to normalize the property definition (on the top level) to be consistent across all the case types. Your property type will still be Text but the control to be used should be pxDropDown and content should be loaded using Data page depending upon the context.
Now your latest comment points to something different where i am curious to know about the business requirement. You cannot by default show a property which is defined as a picklist on the top level to render as a Text Input in the subclass case type view. Because in the Display As dropdown provided on the view, you will not see a Text type control for a property which is defined as Picklist on top level.
Provided you follow this aggressive approach,
- You have to write a custom component of type Field and subtype as Picklist and then render it as TextInput.
- Create a view with the same name as the parent view and render this picklist property with your custom control.
- The you should see your property rendered as Text Input rather as picklist and user can enter any text in it.
The above approach to my best knowledge should work. But i am still skeptical on the business requirement where it forces me to change the field rendering of this sort.
@SatishKumarUdamalaIf you property has to show different dropdown options for different case types, you may want to normalize the property definition (on the top level) to be consistent across all the case types. Your property type will still be Text but the control to be used should be pxDropDown and content should be loaded using Data page depending upon the context.
Now your latest comment points to something different where i am curious to know about the business requirement. You cannot by default show a property which is defined as a picklist on the top level to render as a Text Input in the subclass case type view. Because in the Display As dropdown provided on the view, you will not see a Text type control for a property which is defined as Picklist on top level.
Provided you follow this aggressive approach,
- You have to write a custom component of type Field and subtype as Picklist and then render it as TextInput.
- Create a view with the same name as the parent view and render this picklist property with your custom control.
- The you should see your property rendered as Text Input rather as picklist and user can enter any text in it.
The above approach to my best knowledge should work. But i am still skeptical on the business requirement where it forces me to change the field rendering of this sort.
You may want to share your business requirement more in detail.
Regards
JC