Skip to main content
Conditional attributes hide extra questions until they matter. A common pattern: Product = Phone shows an IMEI field; Product = Laptop shows a serial number instead. Conditions live on the ticket type, next to attributes, at Settings → Contact Center → Tickets → Ticket Types → [type].

​
How a condition works

A condition has four parts: The dependent is visible when at least one matching condition fires. If you add two conditions on the same dependent (Phone or Tablet → show IMEI), either controlling value is enough.
Conditions are a form experience, not a security boundary. APIs and automations can still write a dependent field. Use them to keep humans from filling the wrong thing, not to hide secrets.

​
Rules

  • The controlling attribute must be a list.
  • The controlling option must belong to that list.
  • Dependent and controlling attributes must be on the same ticket type.
  • You can nest conditions: a dependent can itself be the controller for another field.
  • Changing the controlling value on a ticket clears dependents that are no longer visible, so you do not keep an IMEI after the product is switched to Laptop.

​
Show a field when a list value is selected

1

Create the controlling list

Add a list attribute such as Product with options Phone, Laptop, and Accessory.
2

Create the dependent field

Add IMEI as text (or whichever format you need). You can leave it hidden by default; the condition will reveal it.
3

Add the condition

Create a condition:
  • Dependent: IMEI
  • Controlling: Product
  • Option: Phone
4

Try it on a ticket

Create a ticket of this type. IMEI stays hidden until Product is Phone. Switch Product to Laptop and IMEI clears.

​
Limit which options a dependent list shows

Sometimes the dependent is also a list, and you only want a subset of its options. Example: Product = Phone → Device model may only be iPhone or Pixel, not MacBook. After the condition exists, attach allowed options to it. Those options must belong to the dependent list.
  • If a condition has no allowed-option rows, the dependent is only shown or hidden. All of its options remain available.
  • If a condition has allowed-option rows, the picker shows only those options while the condition matches.

​
Editing and deleting

  • Delete a condition when the pairing is no longer true. Tickets keep whatever values they already stored.
  • Remove an allowed option from a condition to stop offering it on new forms. Historical tickets can still hold the old value.
  • Archiving a list option that conditions depend on will break those conditions until you update them. Archive options only after you have moved or removed the conditions.

​
Design tips

  • Put the controlling list above dependents on the form (lower sort order) so people answer it first.
  • Avoid deep chains. Two levels (product → model → IMEI) is usually enough.
  • Do not use conditions as the only way to hide sensitive data. Use teammate-only visibility or a back-office type instead.