Plan requirement
| Subscription | Any plan |
| Access | Admin |
Custom fields work in triggers, automations and views just like standard ones, with two behaviours to check first.
Use one in a rule
- Open the trigger, automation or view you are building.
- Add a condition and find your field in the list. Custom fields appear under their display name.
- Choose the operator and the value.
- Save and test on a real ticket.
Which operators you get depends on the type
| Drop-down | Is, Is not, Present, Not present |
| Multi-select | Includes, Does not include, Present, Not present |
| Text, multi-line, number, decimal | Present, Not present, and only in triggers |
| Date | Is, Is not, Before, After, Is within the previous, Is within the next, Changed, and more |
| Checkbox | Is checked, Is unchecked |
Read the third row twice, because it is the one that changes designs. A text field cannot be matched on its content: there is no "contains". All a rule can ask is whether something was typed. If you need to route on what a customer wrote, that has to be a drop-down, or a tag, or triage.
Checkboxes have their own catch: for automations and views the checkbox has to add a tag when ticked. Without that tag it does not appear as an option at all, which reads like a bug and is a setting 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.
Comments
0 comments
Article is closed for comments.