The response to our previous article on Data Objects and field types has been overwhelmingly positive, with developers appreciating the practical guidance on when to use Data Reference, Embedded Data, and Query fields. However, conversations with the community reveal that many still struggle with a fundamental question: "Which data model option should I choose for my specific scenario?"

This challenge isn't about lacking technical knowledge—it's about adapting to a completely different way of thinking. In Traditional UI development, we often started with the interface we wanted to build and worked backward to the data model. We'd design sections, add fields, and then worry about where the data came from. Constellation requires us to flip this approach entirely.

New mental model

The key to mastering Constellation lies in embracing a new mental model that follows this sequence:

Business Outcome → Data Model Option → UI Control/Component

This represents a fundamental shift from Traditional UI, where the typical flow was:

UI Requirements → UI Implementation -> Data Structure

In Constellation, we must train ourselves to think differently. Instead of asking "What UI component do I need?" We should start with "What business outcome am I trying to achieve?"

The three-step approach

Step 1: Define Your Business Outcome Before touching any configuration, clearly articulate what the user needs to accomplish:

• Are they selecting from existing standardized data?
• Are they capturing unique information specific to this case?
• Do they need to view related information for context?
• Are they making decisions based on external data?

Step 2: Choose Your Data Model option Based on your business outcome, select the appropriate data field type:

• User Reference: When working with operator or user records
• Case Reference: When referring to other case instances
• Data Reference: When selecting from standardized data (internal or external)
• Embedded Data: When capturing case-specific information
• Query: When displaying contextual read-only information

Step 3: Select UI Control/Component Only after defining the business outcome and data model should you consider which UI control best supports the user experience you want to achieve.

Data Model: Embedded Data vs Data Reference

When it comes to step 2 above, these can be two of the most difficult items to master when starting your Constellation journey.

To help, we’ve provided a visual representation below.

Add a data reference to allow selection of items from a list. This can be a single record or multiple (in this example it is multiple)

Add an embedded data field to allow entry of one or more items. In this example, it is a list of records, allowing multiple.

Add an embedded data field to allow entry of one or more items. This can be combined with data references to allow selection of one or more items from a list.

This is a simplified example, but a good starting point. Now that you understand this, you can move on to the nuances of the full data model and the UI options that come with it.

Constellation Cheat Sheet

To help internalize this new mental model, here's a comprehensive reference guide that maps business scenarios to data model options and their available UI controls:

This cheat sheet serves as your decision tree. Start with the business outcome, identify the appropriate data model option, then choose from the available UI controls that best serve your UX goals.

Practical application

Let's apply this mindset to typical development scenarios:

Scenario 1: Product selection

• Traditional UI thinking: "I need a dropdown for product selection"
• Constellation thinking:
  • Business Outcome: User must select from approved products to ensure consistency
  • Data Model: Data Reference (standardized data selection)
  • UI Control: Autocomplete, Dropdown, or Table based on UX needs

Scenario 2: Customer information gathering

• Traditional UI thinking: "I need form fields for customer data"
• Constellation thinking:
  • Business Outcome: Capture unique customer details for this specific case
  • Data Model: Embedded Data (case-specific information)
  • UI Control: Form with appropriate field types

Scenario 3: Shipping rates display

• Traditional UI thinking: "I need to display shipping options"
• Constellation thinking:
  • Business Outcome: Show contextual pricing information to inform user decisions
  • Data Model: Query (read-only contextual data)
  • UI Control: Table or List display

Conclusion

Mastering Constellation isn't just about learning new technical configurations—it's about rewiring how we approach application design. By starting with business outcomes rather than UI requirements, we create more intuitive, maintainable, and effective applications.

The cheat sheet provided serves as your compass during this transition. Use it to guide your decisions until this new mental model becomes instinctive. Remember: in Constellation, the business outcome always comes first, the data model follows, and the UI components serve the experience you want to create.

As you continue your Constellation journey, embrace this mindset shift. Your applications—and your users—will benefit from this more thoughtful, outcome-driven approach to development.

Constellation 101 series

Enjoyed this article? See more similar articles in Constellation 101 series.