HubSpot Ticket Properties

HubSpot ticket properties are the ticket. Everything else, routing, views, reporting and automation, is just reading them back to you.

Start free trial All guides

The HubSpot ticket properties you get before building anything

HubSpot ships a reasonable default set, and a surprising number of teams never look at it before inventing their own versions of the same fields.

Ticket name and description. Subject line and first message, essentially.

Pipeline and status. Where the ticket is in your process.

Ticket owner. The person accountable, which isn't always the person replying.

Priority. Present by default and, in most portals, meaningless by default.

Source. Which channel it arrived on. Underused and genuinely valuable.

Create date, last activity date, close date. The spine of every operational report you'll build.

Timing properties such as time to first agent reply and time to close, calculated for you.

Associations to contact, company, deal and conversation. Not properties in the strict sense, and worth more than most of them.

Before you create anything, sit with that list for ten minutes. Two thirds of the custom properties I see in real portals duplicate something already there.

The properties that drive routing

A routing rule can only read what the ticket already knows. That means the properties feeding your routing have to be set at creation, not by an agent five minutes later, or the rule fires against an empty field and sends everything to the same fallback team.

Two ways to populate them at creation:

From the form. A dropdown on your support form writes straight to a ticket property. Reliable, and every extra field on that form costs you completed submissions.

From the channel. Which inbox it hit, which chat widget, which product. No customer effort at all, and it's right every time.

Free-text properties are useless for routing. So are properties that only get filled in during triage, because by then a human has already made the routing decision the workflow was supposed to make.

The properties that drive reporting

Different job, different rules. Reporting properties can be set late, and often should be, because the person who knows what a ticket really was is the person who closed it.

The set worth having is small.

Category or topic. A single dropdown, ten to fifteen values, mandatory before close. This one property answers "what are we spending our time on", which is the question every support review starts with.

Resolution or outcome. Fixed, explained, escalated, no fault found, refunded. It tells you what kind of work you're doing, not just how much.

Product area if you have more than one product, and only then.

Note what isn't on that list. Nothing that duplicates a stage, nothing an agent has to think hard about, and nothing with forty options in it.

Property types, briefly

HubSpot gives you the usual set: single line text, multi line text, dropdown select, radio select, multiple checkboxes, single checkbox, number, date picker, plus calculation properties that derive a value from other fields.

Three practical rules.

Dropdowns beat text, always, for anything you'll filter or group by. Text turns into forty spellings of "billing" within a quarter.

Radio for four or fewer options, dropdown above that. Agents pick a visible option faster than one they have to open a menu to find.

Checkboxes plural means your report will lie unless you know how multi-value fields count. Use them deliberately.

Design that survives a year

HubSpot lets you create far more custom properties than any support team should, and that generosity is the trap. Every property is a question somebody has to answer, forever.

Set the internal name once. Labels can be edited freely and internal names are what integrations and exports depend on. Get them right before anything else connects.

Prefix your custom properties. Something short and consistent, so a year later you can tell what you built from what shipped with the platform.

Make properties required at close, not at create. Requiring fields on arrival slows the queue and produces guesses. Requiring them at close produces data.

Review the option lists quarterly. A category with an "other" bucket over about fifteen percent is telling you the list is wrong.

Do not delete a property to tidy up. You lose the history behind every report that used it. Take it off the forms and the record layout instead, and leave the data alone.

FAQ

Frequently asked questions

What are the default HubSpot ticket properties?

HubSpot default ticket properties cover pipeline, stage, priority, owner, source, create date and last activity. Everything else is a custom property, and HubSpot ticket fields is the same thing under the name people from other tools use.

How many custom HubSpot ticket properties should we create?

Fewer than you want to. Most teams run well on five to eight custom properties. If nobody has looked at a property in a report for six months, it's decoration.

Can ticket properties be set automatically?

Yes, from forms, from the channel a ticket arrived on, and from workflows on the tiers that include them. Automatic beats asking an agent every time.

What happens if I delete a ticket property?

You lose the values stored in it and the reports built on it break. Retire a property by removing it from forms and layouts rather than deleting it.

Should priority be set by the customer?

Almost never. Customer-set priority is uniformly high. Derive it from properties you trust, like plan tier, product area or channel.

One property no field can hold

"This is the same request as ticket 4412" isn't something an agent can type into a dropdown. Ticket Merger works that out for you on Zendesk and Freshdesk today, with HubSpot on the roadmap.

Start free trial

14-day free trial. No credit card required.

Published August 18, 2026