Plan requirement
| Subscription | Any plan |
| Access | Admin |
Yes. Build the placeholder and put it in the trigger's message. The detail that trips people is that ticket fields are addressed by a numeric ID while user and organisation fields are addressed by a key.
The exact forms
| Custom ticket field | {{ticket.ticket_field_<field ID number>}} |
| Its drop-down title | {{ticket.ticket_field_option_title_<field ID number>}} |
| Custom user field | {{ticket.requester.custom_fields.<field_key>}} |
| Custom organisation field | {{ticket.organization.custom_fields.<field_key>}} |
For a drop-down, use the title form or add .title, otherwise the customer receives the stored value, something like cat_hw_laptop. The .id suffix is a different thing: it returns the ID of the target record in a lookup relationship field.
The two things that go wrong
The field is empty. The placeholder resolves to nothing and the sentence goes out anyway, missing a word. Write around it, or use a Liquid conditional so the sentence only appears when there is a value.
The ID came from another environment. A rule built in a sandbox and rebuilt by hand in production refers to a field ID that does not exist there, and produces blanks silently. Field keys travel better than numeric IDs for exactly this reason.
So test twice: one ticket with the field filled in, one without. The second is the one your customers will meet, and it is the one nobody checks.
Comments
0 comments
Article is closed for comments.