Select fields and relationships
Use the Demo Projects HQ task form to separate simple status choices from relationship fields that point at live project and contact records.
Choice fields split into two different jobs
Section titled “Choice fields split into two different jobs”The task form in Demo Projects HQ shows that not every choice field means the same thing. Some fields just choose from a fixed vocabulary like status or priority. Others point at a real related record such as a project or contact, which changes how the field should be designed and validated.
The task form mixes fixed choices with live lookups
Section titled “The task form mixes fixed choices with live lookups”task_add.ejs is useful because it puts both patterns in one place. Status and priority are fixed meaning sets, while project and assignee connect the task to live records the rest of the application already knows about.
Status and priority are closed vocabularies
Section titled “Status and priority are closed vocabularies”#task_status and #task_priority are not asking the user to discover outside data. They are asking the user to choose from a small set of meanings the system already defines, which is exactly what a plain select handles well.
Project is a relationship field, not just a dropdown
Section titled “Project is a relationship field, not just a dropdown”#task_project looks like one control, but its job is different from status or priority. It has to point at a real project record, which is why the form treats it as a required relationship and supports guided lookup instead of leaving the user with a long static list.
Assignee shows the editable relationship pattern
Section titled “Assignee shows the editable relationship pattern”#task_assignee is the related-record pattern in a more traditional select shape. The important part is not the control chrome. It is that the stored value still points at a contact id, and the form deliberately allows an Unassigned fallback instead of implying every task must have a contact.
Conclusion
Section titled “Conclusion”Choice fields become easier to maintain when you separate closed vocabularies from related-record selection. That distinction is what tells you whether a plain select is enough or whether the field needs a stronger data-driven pattern.