Problem Statement

In traditional UI-Kit applications, it was common to:

• Define a property at a common or higher class
• Source dropdown values from case-specific data pages in each case type’s section 

When moving to Constellation, this pattern often appears to require:

• Changing the property to a dropdown per case type, or
• Creating specialized properties at each class level

This raises the question:

Can we still achieve case-type-specific dropdown values in Constellation without specializing the property?

Example Case Hierarchy

Release (Grandparent)

  └── Feature (Parent)

        └── Story (Child)

All three are case types in the same application hierarchy.

Step 1: Define the Property Once

A property named:

.StarPerformer (Picklist / Text)

•  Defined only in the Release case type
• Inherited automatically by Feature and Story
• No specialization
• No view-specific logic

This property represents the selected employee.

Step 2: Create a Context-Driven Data Page

A parameterized Data Page is created to supply the dropdown values.

Data Page: D_StarPerformerOptions

Data Page Logic (Conceptual)

If Filter = "IT" → Return IT department employees

If Filter = "HR" → Return HR team employees

If Filter = "Sales" → Return Sales team members

The data page itself is generic - it has no awareness of case types.

Step 3: Introduce a Case Context Property

A property named: .Filter

•  Defined on the Release case type, or some where on more higher level as well
• Inherited by Feature and Story
• Used only to provide context to the Data Page

Step 4: Set Case-Type-Specific Defaults

In each case type’s pyDefault (or initialization logic):

This ensures:

•  The same property exists everywhere
• But its value automatically differs based on the case type

Step 5: Configure the View (Once)

The dropdown is rendered in all three case views with no changes.

View Configuration

•  Control: Dropdown
• Property: .StarPerformer
• Options source: D_FilteredEmployees
• Parameter mapping: Filter = .Filter

No conditional logic.

No case-specific overrides.

No specialized views.

Step 6: Directed Inheritance

For property, data page, and view reuse to work cleanly across Release → Feature → Story, the class hierarchy must use directed inheritance (child → parent → grandparent).

Runtime Behavior

When cases are created:

Despite:

•  One property
• One data page
• One view configuration

…the dropdown options differ correctly and automatically.

Demonstration

Case Structure

​

Release (Grand parent)

​​

Feature (Parent)

​​

Story (Child)

​​

DB Snapshot

​​

Why This Works in Constellation

This pattern aligns perfectly with Constellation principles:

In Constellation, allowed values are contextual, not structural.

Key Takeaways

•  No property specialization required
•  No case-specific dropdown configuration
•  Fully reusable and scalable
•  Works seamlessly across parent–child case hierarchies
•  Constellation-compliant and upgrade-safe

Conclusion

This implementation is a textbook example of the recommended Constellation approach for handling case-type-specific dropdown values.

It is the direct Constellation equivalent of the old UI-Kit pattern:

“Same property, different data sources per case type”

…implemented in a cleaner, more maintainable way.

Please share your thoughts, feelings, ideas on this topic

Happy exploration!!!

Regards

JC