Gorgias Ticket Fields & Custom Fields Explained
Ticket fields are the structured data layer underneath your Gorgias inbox — the dropdowns and toggles that turn a messy conversation into something you can filter, route, and report on. Instead of guessing from a subject line whether a message is a return, a where-is-my-order (WISMO) question, or a subscription change, a well-set field tells you at a glance, and it tells your automations too. This guide walks through the difference between Gorgias' built-in managed fields and your own custom ones, where ticket fields end and customer fields begin, how each surfaces for agents, and — the part the angle really cares about — how Rules and Flows key off them. It stays honest about where the native feature runs out of road.
Ticket fields vs custom fields vs customer fields
The first thing to untangle is vocabulary, because Gorgias uses three related terms that people mix up. A ticket field is a property attached to a single conversation — it describes this ticket. Some ticket fields ship with Gorgias (the "managed" ones); others you create yourself, which is what most people mean by "custom fields." So "custom ticket field" is just a ticket field you built rather than one Gorgias pre-installed.
A customer field is different in scope. Per Gorgias' customer fields documentation, a customer field is a property that lives on the shopper's profile and follows them from ticket to ticket. If a ticket field answers "what is this conversation about?", a customer field answers "who is this person, across every conversation?" — think VIP status, loyalty tier, or a preferred contact note. The two are complementary: one is per-conversation, one is per-person.
The built-in managed fields you get for free
Gorgias doesn't start you from a blank slate. Out of the box, it creates three managed, ecommerce-specific ticket fields designed to capture the data most stores actually want:
- Contact Reason — why the customer reached out (return, WISMO, refund, product question, subscription change).
- Resolution — how the ticket was ultimately closed out.
- Product — which product the conversation was about.
These three are the backbone of most Gorgias analytics, because once agents fill them in consistently, your reporting can finally answer "what percentage of our volume is returns?" or "which product drives the most WISMO?" You can edit or archive the managed fields like any other, but they exist precisely so a new store gets useful, structured data on day one without designing a taxonomy first.
Where ticket fields live and how agents fill them
To create and manage ticket fields, open the Helpdesk menu → Workflows → Fields and tags → Ticket fields, per the Manage Gorgias ticket fields documentation. From there you build fields of four types: Dropdown (single-select, and it can nest up to five levels deep for taxonomies like Return → Wrong size → Exchange), Number, Text (up to 2,000 characters of free-form notes), and Yes/No.
Each field carries a visibility rule. You can make it always optional, always required (which forces an agent to populate it before they can close the ticket — the mechanism that keeps your data clean), or conditionally visible, where the field only appears when the ticket meets conditions you set. Conditional visibility is how you keep the sidebar uncluttered: a "Return reason" field only shows up on tickets already tagged as returns. Gorgias lets you stack up to 70 conditions on conditionally visible fields.
In the agent view, all of this shows up in the right-hand sidebar of the ticket, alongside tags and the customer's details.
Note two practical limits worth knowing before you design a big taxonomy. You can have a maximum of 25 active ticket fields at a time, and you can hold a maximum of four active customer fields. Fields can't be deleted — only archived — and archiving preserves the values on existing tickets, so if you unarchive later, the history comes back. One more gotcha: ticket fields are unsupported on the Gorgias mobile app, so a required field can only be completed from a desktop browser.
How Rules key off ticket fields
This is where fields stop being passive data and start driving automation. In Gorgias, Rules can use ticket fields in both directions, which is the detail most guides gloss over.
Ticket fields as a condition (trigger). A Rule can fire because a field has a certain value. Per Gorgias' Use Ticket Fields in Rules documentation, "you might create a rule that assigns tickets with the Contact Reason: Refund request ticket field to a specific team or agent." So a refund lands with your finance-savvy agents; a WISMO ticket routes to a fulfillment specialist — all off the field value.
Ticket fields as an action. A Rule can also set a field for you. The docs note you can "create a Rule that automatically sets Ticket Fields based on a series of conditions," which "can help standardize the Ticket Fields used on each ticket." In practice: a Rule detects a Shopify order-status keyword, and it stamps Contact Reason: WISMO so your reporting stays consistent even when agents forget.
There is one hard constraint, and it's the most important line in the whole docs page: "Only Ticket Fields created in Gorgias can be used in Rules." Fields pushed in from an external system or API won't work as Rule conditions or actions — if you want automation to key off a field, it has to be a native Gorgias ticket field. Customer fields, meanwhile, are usable across Views, Rules, Macros, and Search, so a VIP customer field can drive routing the same way. Once a Rule has routed the ticket, a well-built Macro can insert the field-aware reply.
Fields in Flows and the AI Agent
Rules are deterministic if-this-then-that logic; Flows are the conversational, self-service side of Gorgias, running in Chat, the Help Center, and the Contact Form. Flows and the Gorgias AI Agent can read context and take actions, and Gorgias' own AI Agent is billed per automated resolution rather than per activity — worth flagging because it changes the cost model as volume grows.
Two honest caveats here. First, the richest self-service actions — automated order tracking, cancellations, returns — lean on your Shopify (or ecommerce platform) connection to actually fetch and mutate order data; fields describe the ticket, but they don't call your store's API by themselves. Second, the AI Agent and advanced automation sit on Gorgias' higher tiers, so exact capability depends on your plan — always confirm against the current Gorgias pricing breakdown rather than assuming.
A quick decision table: which field type for which job
| You want to capture… | Use | Why |
|---|---|---|
| Why the customer wrote in (return, WISMO, refund) | Managed Contact Reason ticket field | Feeds analytics + Rule routing out of the box |
| A structured return reason with sub-options | Dropdown ticket field (nested) | Nesting up to 5 levels keeps taxonomy tidy |
| A free-text internal note about this ticket | Text ticket field (2,000 chars) | Not searchable-structured, but flexible |
| Whether this ticket needs a manager review | Yes/No ticket field | Cheap flag a Rule can trigger on |
| VIP / loyalty tier that follows the shopper | Customer field | Persists ticket-to-ticket on the profile |
| A field that must be set before closing | Any ticket field set to always required | Enforces clean data at close |
The honest limits — and where an AI layer picks up
Gorgias' fields engine is genuinely strong: it's structured, it's enforceable at close, it drives Rules in both directions, and the three managed fields give ecommerce teams a sensible starting taxonomy for free. For organizing and routing, it does the job.
But notice what a field is: it's a label, not an answer. A ticket field can tell you "this is a WISMO question" — it cannot go and find where the order actually is, read the tracking status, and write the reply that resolves it. A required field enforces that someone categorizes the ticket at close; it doesn't stop that categorization from being wrong when an agent picks the nearest dropdown in a hurry. And the "only Gorgias-created fields work in Rules" constraint means any data living outside Gorgias — in your OMS, your 3PL, your subscription platform — can't drive native automation until you've mirrored it into a Gorgias field.
This is the seam where an AI agent layer fits, and it's worth being clear-eyed about it. The broader category of AI agents for customer service exists to do the reasoning-and-fetching work a static field can't. Macha is one such layer: it runs on top of the Gorgias you already use through a live native connector — it does not replace your help desk, your fields, or your Rules. Connected to Gorgias, Macha reads the same ticket fields you've set (so it knows a ticket is a WISMO or a refund the moment it opens), then does the part a field can't: it looks up the real order or subscription status through a custom tool that turns your store or OMS API into something the agent can call, drafts or posts a grounded reply, and can even suggest the correct field value so your taxonomy stays honest. The Macha–Gorgias integration is built for exactly this division of labor.
One genuine, honest contrast on cost: Gorgias' own AI Agent bills per automated resolution, while Macha's credits are consumed per AI action — a lookup, a draft, a field update each count as an action regardless of whether the ticket "resolves" — which is a different economic model worth weighing for your volume (see the pricing breakdown). Neither is universally cheaper; they price different things.
The clean split: keep Gorgias' ticket and customer fields as the source of truth for how tickets are categorized and who the customer is, and layer an agent on top for the part a field can't do — actually reading the data and writing the answer.
FAQ
Where do I create ticket fields in Gorgias? Open the Helpdesk menu → Workflows → Fields and tags → Ticket fields. You'll find the three managed ecommerce fields (Contact Reason, Resolution, Product) already there, plus the option to create your own custom fields of type Dropdown, Number, Text, or Yes/No.
What's the difference between ticket fields and customer fields? A ticket field describes a single conversation and lives on that ticket; a customer field describes the shopper and follows them from ticket to ticket on their profile. Ticket fields cap at 25 active; customer fields cap at four active. Customer fields are set under Settings → Ticket & Customer data → Customer Fields.
Can I use ticket fields to trigger Rules? Yes — ticket fields work in Rules both as a condition (a Rule fires when a field has a value, e.g. routing "Contact Reason: Refund request" to a team) and as an action (a Rule auto-sets a field to standardize data). The one constraint: only ticket fields created in Gorgias can be used in Rules.
How many ticket fields can I have, and can I delete them? You can have up to 25 active ticket fields at a time. You can't delete a field, only archive it — and archiving preserves any values already saved on tickets, so unarchiving restores the history. Ticket fields are also unsupported on the Gorgias mobile app.
Can I add AI to Gorgias fields without replacing Gorgias? Yes. An AI agent layer like Macha connects to Gorgias as a native connector and runs on top of your existing fields, Rules, and Macros — it doesn't replace them. It reads the fields you've set, fetches real order data via custom tools, drafts grounded replies, and can suggest the right field value, while Gorgias stays the system of record for categorization.
Ready to let your fields do more than sit in a sidebar? Start a free trial of Macha and connect it to your Gorgias in minutes.
Add AI agents to your Gorgias
Macha resolves tickets end to end on Gorgias — no migration, no code.
Zendesk
Freshdesk
Gorgias
Front
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

