Plan requirement
| Subscription | Any plan |
| Access | Admin |
Custom fields are addressed by ID, not by name, which makes them cryptic to read and dangerous to copy between accounts.
Use one
- Find the field's ID in Admin Center, under ticket fields.
- Build the placeholder using that ID.
- Put it in the message.
- Test on a ticket where the field has a value, and on one where it does not.
The syntax
Four forms, depending on what the field is attached to.
{{ticket.ticket_field_<field_ID>}} |
A ticket field, by its numeric ID. Gives the stored value. |
{{ticket.ticket_field_option_title_<field_ID>}} |
The same drop-down, but the title people see. |
{{ticket.requester.custom_fields.<field_key>}} |
A field on the requester, by key. |
{{ticket.organization.custom_fields.<field_key>}} |
A field on their organisation, by key. |
So a ticket field with ID 360001234567 becomes {{ticket.ticket_field_360001234567}}, and a user field with the key order_number becomes {{ticket.requester.custom_fields.order_number}}.
For a lookup relationship field, add .id or .name to reach the record it points at: {{ticket.ticket_field_360001234567.name}}.
User and organisation fields have no option_title_ form. For a drop-down on one of those, add .title instead: {{ticket.requester.custom_fields.order_type.title}}.
Value or title
For a drop-down there are two forms: the value stored underneath, and the title shown to people. Customers should see the title; a system reading the message may want the value.
Sending the internal value to a customer produces a message containing something like cat_hw_laptop, which is the second most common placeholder mistake after empty values.
Sandbox IDs are not production IDs
The one worth writing on a wall. A field created in a sandbox has a different ID from the same field in production, so a trigger built and tested in a sandbox and then rebuilt by hand in production silently refers to nothing.
Symptom: it worked perfectly in testing and produces blanks live. Check every custom field placeholder after any move between environments.
Field keys
Some field types support a readable key alongside the numeric ID. Where available, prefer it. A configuration referring to order_number still makes sense in two years; one referring to a fifteen-digit number does not.
Comments
0 comments
Article is closed for comments.