> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oration.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Conditional attributes

> Show or limit a field only when another list attribute has a specific value. Use this to keep ticket forms short.

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:

| Part                           | Role                                          |
| ------------------------------ | --------------------------------------------- |
| **Dependent attribute**        | The field that is shown or limited            |
| **Controlling attribute**      | A **list** field whose value you watch        |
| **Controlling option**         | The list choice that unlocks the dependent    |
| **Allowed options** (optional) | For list dependents, which choices may appear |

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.

<Info>
  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.
</Info>

## 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

<Steps>
  <Step title="Create the controlling list">
    Add a list attribute such as **Product** with options `Phone`, `Laptop`, and `Accessory`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Add the condition">
    Create a condition:

    * Dependent: IMEI
    * Controlling: Product
    * Option: Phone
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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.