Using custom fields in triggers and views

Custom fields work in triggers, automations and views just like standard ones, with two behaviours worth knowing first.

Custom fields work in triggers, automations and views just like standard ones, with two behaviours worth knowing first.

Use one in a rule

1. Open the trigger, automation or view you are building.
2. Add a condition and find your field in the list. Custom fields appear under their display name.
3. Choose the operator and the value.
4. Save and test on a real ticket.

Which operators you get depends on the type

A drop-down offers is and is not. A text field offers contains, which is powerful and dangerous: "contains 100" also matches 1100. A date field offers before and after, which is what makes date fields useful in automations.

Checkboxes are a special case. They add a tag when ticked, and many people find it easier to build the rule on that tag than on the field.

The value is a tag underneath

Drop-down and checkbox values carry tags, and rules can be built either on the field value or on the tag. Both work. Building on the tag survives a field being renamed; building on the field is easier to read. Pick one convention and keep to it, because mixing them is how a configuration becomes unreadable.

Blank is a value

A condition checking that a field "is not" a particular value also matches tickets where the field is empty, which is rarely what people mean. Where it matters, add a second condition requiring the field to be present.

See also

• Building conditions: all, any, and the trap in between
• What tags are and what you use them for
• Reporting on custom fields