Best Practices for Field Dependency Conditions with Picklist Values (CRM)
Overview
Field dependencies in the Dazos CRM allow you to show or hide content fields based on the value selected in a picklist field (such as Admitting to LOC). While conditions can technically contain multiple picklist values, following the best practices outlined in this article will help ensure consistent, reliable behavior.
When to Use This Guide
Refer to this guide if you are:
Setting up or editing field dependency conditions for a picklist field
Experiencing inconsistent show/hide behavior for content fields after selecting a picklist value
Working with picklist values that have similar or overlapping names (e.g., MH PHP and Adol MH PHP)
The Core Issue: Grouping Similar Values in One Condition
Field dependency conditions support multiple picklist values within a single condition. However, when two or more values share very similar names, the CRM may not evaluate them consistently when grouped together.
For example, grouping MH PHP and Adol MH PHP in the same condition can cause conflicts because their names are so similar. This may result in the wrong content field being shown or hidden, or both fields remaining visible regardless of the selected value.
Recommended Best Practice: One Value Per Condition
To ensure reliable and predictable behavior, place each picklist value in its own individual condition. This allows the CRM to evaluate each condition independently, rather than comparing multiple values simultaneously.
Instead of creating one condition like this:
Condition 1: Admitting to LOC = MH PHP or Adol MH PHP → Show Yellow Flag Content A
Create separate conditions like this:
Condition 1: Admitting to LOC = MH PHP → Show Yellow Flag Content A
Condition 2: Admitting to LOC = Adol MH PHP → Show Yellow Flag Content B
Why This Matters
Separating values into individual conditions provides several important benefits:
Consistent evaluation: Each condition is assessed on its own, reducing the risk of similar values interfering with one another.
Easier troubleshooting: Individual conditions make it simpler to identify and fix logic errors.
Future-proofing: As more picklist values are added over time, individual conditions are less susceptible to edge cases related to caching, indexing, or workflow execution order.
Tips & Notes
⚠️ Warning: Grouping similarly named picklist values (e.g., values where one name is a substring of another) in the same condition is a known source of inconsistent behavior. Always separate these into their own conditions.
💡 Tip: After updating your field dependency conditions, clear your browser cache and test each picklist value individually to confirm the correct content fields are showing and hiding as expected.
✅ Best Practice: As a general rule, use one condition per picklist value for all field dependencies — even when the values are not similarly named. This keeps your configuration explicit, maintainable, and reliable.