- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
A dropdown turns an open question into a closed one — that is its value and its risk, and nothing complains at the moment you get it wrong.
How to create a dropdown in a form without ruining the data behind it
Adding a dropdown to a form takes a moment: choose the field type, type the options, save. The decisions inside that moment determine whether the answers are usable six months later, and they are easy to get wrong because nothing complains at the time.
A dropdown converts an open question into a closed one. That is its whole value — a closed answer can be filtered, counted, and used to route an enquiry — and it is also its whole risk, because an option list that does not match reality forces people into the nearest wrong answer.
The four decisions that matter
| Decision | Get it right by | Cost of getting it wrong |
|---|---|---|
| Whether it should be a dropdown at all | Using it only when the answers are genuinely a fixed set | Respondents forced into an answer that is not true |
| The option list | Covering the real range, in the respondent’s language | Everything lands in one bucket and tells you nothing |
| Stored value versus displayed label | Keeping the stored value stable and machine-friendly | Renaming a label silently breaks every rule that referenced it |
| What the answer triggers | Deciding the routing before writing the options | A field that collects information nobody uses |
The third row is the one that causes damage quietly. Many builders store exactly what is displayed, so changing “Roof repair” to “Roof repairs” creates a new value; automations matching the old string stop firing, historical records no longer group with new ones, and nothing reports an error. Where the tool allows a separate stored value, set it deliberately and never change it. Where it does not, treat every label as permanent once the form is live.
Writing the option list
- Cover the range, then stop. Long lists are scrolled, not read. If there are more than about a dozen options, the question is probably two questions, or it should be a search field instead.
- Use the respondent’s words. Internal service names and product codes are meaningless to the person filling in the form, and they guess.
- Make the options mutually exclusive. If two could both apply, either allow multiple selection or redesign the question.
- Order them by likelihood, not alphabetically — except for genuinely alphabetical sets such as countries, where people scan for a known string.
- Include the honest escape. “Something else” with an optional text box captures what your list missed, and reading those answers is how the list improves.
- Do not use a placeholder as an option. “Please select” must not be a submittable value; that belongs to required-field validation.
The escape option deserves emphasis. A list without one produces data that looks tidy and is partly fictional, because respondents pick the closest available answer rather than abandoning the form. Reviewing the free-text entries every few months takes minutes and keeps the list honest.
Dropdowns that drive behaviour
A dropdown becomes far more valuable when its answer changes what happens next. The typical uses are branching the form, routing the record, and setting the classification a person will act on.
For branching, the answer selects the path — the design discipline for that is skip logic and branching paths, and the specific caution is that a rule referencing an option label breaks when the label changes. For routing, the answer should set a field or tag the intake layer reads, as described in routing and suppression, rather than being interpreted by whoever opens the record. And where the answer contributes to whether a lead is worth immediate attention, it is one of the observable criteria classifying leads on evidence is built on.
Where a dropdown decides which service is being booked, it also decides which calendar, duration and owner apply, which is why the option list and the booking configuration have to be designed together — see a calendar clients can book into.
How it behaves for the person filling it in
Native dropdowns render as the operating system’s own picker on a phone, which is usually a better experience than a custom component and always more reliable. Custom styled dropdowns look consistent across devices and are the ones that break: keyboard navigation, screen readers, and the phone’s own scroll wheel are all easy to lose.
For short lists, consider radio buttons instead. Two or three options displayed as buttons are faster than opening a picker, and on a long form that difference accumulates — relevant when a form is split across steps, as splitting a form across steps describes. Check the rendering on a phone before publishing, since form fields are among the elements most affected by the reordering in how a phone stacks your columns; a dropdown whose options open below the fold is functional and feels broken.
Maintaining the list over time
Option lists rot. Services change, products are retired, and the list on the form is the last place anyone thinks to update. Two habits keep it honest.
First, when an option is retired, stop offering it but keep the value valid for historical records. Deleting it outright can strip the value from existing contacts or leave them pointing at nothing. Second, keep a copy of the option list and what each value triggers somewhere outside the builder — the same reasoning as a durable record outside the platform — because it is documentation nobody else will write. That copy is also what protects you when a form is duplicated into another account, where option lists and the automations referencing them are a common casualty of what moves and what breaks on import.
Finally, look at the distribution occasionally. If almost every submission selects the same option, the question is not discriminating and either the list or the question is wrong. If one option correlates with much better outcomes, that is a routing rule waiting to be written, and the way to see it is to break your conversion figures down by the field, in the manner measuring conversion by stage describes. That is when a dropdown stops being a form element and starts being useful, and a qualifying quiz is the fuller version of the same idea.
Frequently Asked Questions
When should a form field be a dropdown rather than free text?
When the answers are genuinely a fixed set that you will filter, count or route on. A dropdown converts an open question into a closed one, which is its value and its risk: if the list does not match reality, people choose the nearest wrong answer rather than abandoning the form.
Why does renaming a dropdown option break automations?
Because many builders store exactly what is displayed, so changing the label creates a new value. Rules matching the old string stop firing and historical records no longer group with new ones, with no error reported. Set a separate stored value where the tool allows it, and treat labels as permanent once a form is live.
How many options should a dropdown have?
Few enough to be read rather than scrolled — beyond roughly a dozen, the question is probably two questions or should be a search field. Order them by likelihood rather than alphabetically, except for genuinely alphabetical sets like countries.
Should there be an ‘other’ option?
Almost always, with an optional text box. A list without an escape produces data that looks tidy and is partly fictional, because respondents pick the closest available answer. Reading those free-text entries every few months is how the list improves.
Are custom-styled dropdowns better than native ones?
Usually not. A native dropdown renders as the phone’s own picker, which is more reliable and generally a better experience. Custom components look consistent across devices and are the ones that lose keyboard navigation, screen reader support and the phone’s scroll behaviour.
What should happen when an option is retired?
Stop offering it, but keep the value valid for historical records. Deleting it outright can strip the value from existing contacts or leave them pointing at nothing. Keep the option list and what each value triggers documented outside the builder.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.