Picklists & Dependent Values
Value sets defined once, shared across fields, and able to respond to one another, so every form, filter and report draws from the same list.
Illustrative UI only. Data and individuals shown are fictitious; any resemblance to real persons or data is coincidental.
One list, many fields
A named value set is stored once and referenced from any number of fields. Change the list in one place and every field that uses it follows. No more three slightly different copies of "industry".
Values that depend on values
A picklist can be controlled by a sibling field, offering only the options legal for the current selection, and clearing itself the moment the controlling value changes underneath it.
Codes and labels can differ
An option can carry a stored value and a displayed label, so the wording on screen can improve over time without breaking the codes your reports and integrations key on.
Reports speak the same language
The report and filter builders resolve the same value sets, so filtering on a picklist field offers the real options, not a free-text box hoping you spell it the same way.
Why we like this one
Picklists drift apart quietly. Two lists that both mean "industry", maintained by different people, disagreeing by one option, and suddenly a report undercounts a segment and nobody knows why. A shared, named set makes the list a single fact of the platform: forms offer it, filters resolve it, and changing it is one edit in one place instead of a hunt across every field that copied it.
Book a demo ➝