Zendesk Conditional Fields
Zendesk conditional fields show a field only when it's relevant. It sounds cosmetic. It's the difference between a form people complete and a form people abandon.
The problem Zendesk conditional fields solve
A ticket form that asks everything is a form that gets half-answered. Your hardware customer sees the software version field and types "n/a". Your software customer sees the serial number field and types "n/a". Now every ticket has two useless values and your reporting is built on sand.
Conditional fields fix this by tying visibility to a selection. Pick "Hardware" and the serial number appears. Pick "Software" and the version field appears instead. The customer only ever sees questions that apply to them, and the answers you get back are worth something.
The second-order effect is the one people miss. Shorter forms get completed, completed forms mean fewer back-and-forth clarification emails, and fewer clarification emails means faster resolution. The gain is not in the form, it's three steps downstream.
How the conditions work
Conditions are configured per ticket form, not globally. That matters: the same field can be conditional on one form and always visible on another, which is usually what you want.
The structure is straightforward. Pick a driving field and a value, then list the fields that should appear when that value is selected. You can also mark a conditionally shown field as required, so it is only mandatory when it is actually relevant.
Not every field type can drive a condition. Drop-downs and checkboxes are the usual candidates, because they have a fixed, enumerable set of values, whereas a free-text field has nothing to match on. Check the current Zendesk documentation for the exact list of supported types on your plan, and note that conditional fields have historically been tied to particular tiers.
Nesting works to a point. A drop-down reveals a second drop-down, which reveals a third field. Do it twice and it feels smart. Do it four times and you have built a decision tree that nobody, including you, can debug in six months.
Agents and end users are separate
This is the part that catches people out, and it's deliberate rather than a quirk.
You configure one set of conditions for what end users see in the help centre or web form, and a separate set for what agents see in the ticket interface. They do not have to match, and usually they should not.
Customers get the short version: the three questions that determine what happens next. Agents get more, because agents need the internal categorisation fields that would mean nothing to a customer. Build the end-user rules to minimise effort and the agent rules to maximise data quality.
One consequence worth planning for: a field hidden from end users still exists on the ticket and can still be set by a trigger or a macro. Hidden isn't the same as absent. If a field must never hold customer-supplied data, hiding it on the form isn't the control you're looking for.
Where it breaks
A sane way to build one
Start on paper. Write the questions in the order a competent human would ask them, and note which answers make which follow-up questions relevant. That sketch is your condition set.
Then build the end-user side first and test it as an end user, in an incognito window, on a phone. Forms that behave beautifully on a wide monitor sometimes reveal fields below the fold on mobile and the whole flow falls apart.
Add the agent conditions after, and check them by taking a real ticket through a category change. Two rounds of testing, one hour, and you avoid the version of this that quietly collects bad data for a year.
Frequently asked questions
Are conditional fields the same as dependent fields?
Same idea, different wording. Zendesk dependent fields and Zendesk form conditions both describe showing a field only when an earlier answer makes it relevant.
Do Zendesk conditional fields work on every plan?
Availability has historically depended on your tier, and the feature has moved between an app and native admin configuration over time. Check the current Zendesk docs for what your plan includes.
Can a text field drive a conditional field?
Generally no. Conditions need a fixed set of values to match against, so drop-downs and checkboxes are the usual drivers. Check the supported list in the current documentation.
Do conditional fields apply to tickets created by email?
No. Email, API and trigger-created tickets never pass through the form, so the conditions never run and conditionally required fields stay empty.
Can agents and end users see different conditional rules?
Yes, and they're configured separately. Keep the end-user rules short and the agent rules thorough.
Does hiding a field make it secure?
No. A hidden field still exists on the ticket and can be set by triggers, macros or the API. Use field permissions for anything that genuinely needs restricting.
Better answers, fewer repeat tickets
Forms that ask the right question cut the follow-ups. For the ones that arrive anyway, Ticket Merger folds them into the original.
Start free trial14-day free trial. No credit card required.