Custom Fields

What are custom fields?

Custom fields let you capture structured information on a ticket that There There does not track by default. A field has a name, a type, and the channels it applies to. Once you create one, it appears on every relevant ticket in the sidebar, whether or not anyone has filled it in yet.

Common uses are recording which framework a customer is on, which version they reported a bug against, or which parts of your product an issue touches.

Field types

There are three types.

Text accepts any short free-form value, such as a version number or an account reference.

Single select lets an agent pick one value from a list you define. Use it when the answer is one of a fixed set, like a customer tier.

Multi select works the same way but accepts several values at once, which suits things like affected areas of your product.

Creating a field

Go to Settings, then Custom fields, and choose Add field. Only workspace owners and admins can manage the definitions.

Give the field a name, pick a type, and for the two select types add the options agents will be able to choose from. Leave "Available on all channels" on unless the field only makes sense for some of them.

A workspace can hold up to 20 custom fields. The limit keeps the ticket sidebar readable.

Colours and icons on options

Each option of a select field can carry a colour, an icon, or both. Give "Urgent" a red fill and a flame, and it reads at a glance instead of as another line of text.

A single select field also has a "Show in list view" setting. Turn it on and the chosen value appears on the ticket in the list, under the summary, carrying whatever colour and icon you gave it. Only single selects offer this, because a row has space for one value rather than a run of them.

Scoping a field to channels

Turn off "Available on all channels" and pick the channels the field belongs to. A field scoped to your Sales channel will not appear on a ticket in Support, which keeps each inbox uncluttered.

Leaving the field on all channels also means it applies to channels you create later, so you do not have to revisit it every time your setup grows.

For a support bubble, a field configured on the bubble's linked email channel also shows on bubble conversations. Configure it once on the email channel and it covers both.

Filling fields in on a ticket

Custom fields sit in the ticket sidebar, underneath the standard properties like assignee and tags. Any agent who can work on a ticket can fill them in.

Text fields save when you click away or press Enter, and press Escape to discard what you typed. Select fields open a picker; a single select replaces the current value, a multi select toggles values on and off. Every change is recorded in the ticket timeline, so you can see who set what and when.

Once you have more than five fields on a ticket they move into their own collapsible "Custom fields" section, which stays open or closed the way you left it.

Setting a field automatically

Workflows can fill fields in for you with the "Set custom field" action. For example, a workflow triggered on new tickets, with a condition matching the word "Laravel" in the subject, can set Framework to Laravel without anyone touching it.

Unlike other action types, you can add several "Set custom field" actions to a single workflow, one per field.

If the field you choose is not available on the ticket's channel, the workflow records why in its log rather than storing a value nobody would see.

Filtering by a custom field

Open Filters above the ticket list and you will find a section for each select field, alongside Status, Channels and Tags. Tick the options you want.

Picking several options of one field widens the result, so "Billable is Yes or Maybe" returns both. Picking options across two different fields narrows it, so "Billable is Yes" plus "Plan is Pro" returns only tickets matching both. Tags behave the same way, so the filters read consistently.

Text fields are not offered here. There is nothing to tick on one.

Saving a view

Any filter you can set can be saved. Create a personal or a workspace view, pick the custom field options in the same way, and the view keeps them. A workspace view narrowing on "Billable is Yes" gives your whole team one click to the billable queue.

If somebody later deletes an option a view used, the view simply stops narrowing by it and keeps working with its remaining filters.

Asking There There

Ask There There can read and set custom fields. The values on the open ticket are part of what it sees, so you can ask what a ticket's fields say without leaving the conversation.

It can also find tickets by field, for example "show me the billable tickets", and fill fields in when you ask it to. Name the field and the option as you named them in Settings. If a name does not match, it tells you which ones exist.

Reporting on custom fields

Custom fields are available through the API, which is the route to take when you want to total something up. A common case is pulling every ticket flagged as billable together with its billable time, then summing the values on your side.

The Custom Fields API documents this, including how to look up the ids for a field and its options, how to filter, and how to ask for the values to come back with the list.

Bear in mind that a text field stores whatever the agent typed. If you plan to add values up, nothing stops somebody entering "about 3 hours", so it is worth agreeing a format with your team.

Reordering fields

Drag the handle on the left of any row in the settings list. The order you set there is the order the fields appear in on tickets, so put the ones you look at most near the top.

Renaming and removing

Renaming a field, or renaming one of its options, keeps every value already stored on your tickets.

The one thing that removes data is deleting. Removing an option clears that value from every ticket holding it, and deleting a field removes it everywhere. Both dialogs tell you how many tickets are affected before you confirm.

An option a workflow still sets cannot be removed. There There names the workflows and links to them, so you can decide what those workflows should do instead. This is deliberate: a workflow pointing at an option that no longer exists cannot tell "set this value" apart from "clear this field", and clearing was never what you asked it to do.

Deleting a whole field is allowed, and the dialog names the workflows that will start failing so the decision is yours. Their "Set custom field" action then fails on each run and records why in the workflow log, rather than There There quietly editing automation you wrote.

A field's type cannot be changed after it is created, because the values already stored would no longer make sense. Create a new field instead.