Placeholders for custom fields

Custom fields are addressed by ID, not by name, which makes them cryptic to read and dangerous to copy between accounts.

Custom fields are addressed by ID, not by name, which makes them cryptic to read and dangerous to copy between accounts.

Use one

1. Find the field's ID in Admin Center, under ticket fields.
2. Build the placeholder using that ID.
3. Put it in the message.
4. Test on a ticket where the field has a value, and on one where it does not.

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.

See also

• Finding the field key or field ID
• Deploying a configuration from one environment to another
• Why there is a blank line where my placeholder should be