Ticket Numbering

Ticket numbering

A ticket's reference is the thing people read out on the phone, write on a form, quote in an email six months later and search for when they can't remember anything else. It's worth being something a person can actually say.

FreeITSM has always issued references like CKQ-418-73926 — three letters and eight digits, drawn at random. Nobody can guess how many tickets you have. Nobody can read one out either.

Tickets → Settings → Ticket numbering lets you choose something else.

Nothing you already have changes. Existing tickets keep the references they have, and every reference FreeITSM has ever issued goes on working — including in replies to emails sent years ago. Changing the format is a decision about future tickets. If you want the old ones brought into line as well, there's a separate tool further down the page.

---

The two styles

Random	CKQ-418-73926. Three letters, three digits, five digits. What FreeITSM has always done, and still the default, so upgrading changes nothing.
Counting up	TICKET-000001, TICKET-000002, … A shape you choose, and the order tells you which ticket came first.

Random has one genuine advantage: an outsider can't tell how many tickets you handle. If that matters to you, keep it. For most service desks, being able to say "that's incident two-four-one" down the phone matters more.

Everything below applies to Counting up. Choose Random and the rest of the screen disappears, because none of it applies.

---

What a number looks like

The format is a piece of text with tokens in it. Anything that isn't a token is kept exactly as you type it.

Token	Becomes
{######}	the number, padded to as many digits as you write hashes
{YYYY}	four-digit year
{YY}	two-digit year
{MM}	two-digit month
{DD}	two-digit day
{TYPE}	a short code for the ticket type — Incident gives INC
{COMPANY}	the company's ticket code

So INC-{YYYY}-{#####} produces INC-2026-00042, and {TYPE}{YY}{MM}-{####} produces INC2608-0042.

A live preview under the box shows the next few numbers as you type. Nobody should have to create a real ticket to find out what a format does.

The digits are a floor, not a ceiling

This is the question everyone asks, so it's worth answering plainly: you cannot run out.

{######} means at least six digits. Ticket 999,999 is TICKET-999999; ticket 1,000,000 is TICKET-1000000. It gets one character longer and carries on. There's no wrap-around, no error, and no ticket that can't be created.

Pick a width because you like how it looks, not because you're trying to guess how many tickets you'll ever have.

What isn't allowed

• No spaces. A reference with a space in it gets broken across a line in an email subject and mangled by half the systems it passes through.
• No square brackets. FreeITSM tags outgoing email subjects with [SDREF:…], and a bracket inside the number would break that tag.
• At most 50 characters, checked against the longest number the format could produce.
• At least one {#} token, or every ticket would get the same reference.

The screen tells you which rule you've broken, and refuses to save until it's fixed.

---

Start counting from

Useful when you're moving from another system and want to carry on where it left off rather than starting again at 1. Set it to 5000 and your first FreeITSM ticket is number 5000.

It's a starting point, not a floor that's re-applied later — once a counter is running it just counts.

---

Count separately for

This decides how many sequences you have running at once.

One sequence for everything	One run of numbers, shared. This is the default and it's what most people want.
Each ticket type	Incidents and service requests get their own runs, so you have INC-000001 and REQ-000001 at the same time. This is how most large service desks do it.
Each company	Each client company counts from 1. Only meaningful on a multi-company install.

⚠️ If you count separately, the format has to say which is which. Counting per ticket type while the format says nothing about the type would give an incident and a service request the same number — two sequences both starting at 1, both rendering as TICKET-000001. So choosing per-type counting requires {TYPE} in the format, and per-company requires {COMPANY}. The screen refuses to save otherwise, rather than letting you find out later.

A caveat about per-type counting

A ticket only has a type once somebody gives it one. Tickets arriving by email or through the portal don't have a type until an analyst sets it, so {TYPE} has nothing to render for them and they're numbered without a type code.

If most of your tickets arrive by email, per-type counting will not do what you're hoping. It suits desks where tickets are raised by analysts choosing a type as they go.

---

Start again

Whether counters reset. Never (the default) just keeps counting. Every year and every month start again from your chosen starting number.

⚠️ Only useful if the year or month is part of the number. Resetting every year while the format is TICKET-{#####} means next January's first ticket wants TICKET-00001 — which already exists. Combine a reset with INC-{YYYY}-{#####} or similar, so each year's numbers are distinct by construction.

A reset isn't a scheduled job that runs at midnight on the 31st of December. Each period simply is a different counter, so nothing has to notice the date changing and nothing can fail to run.

---

Multi-company installs

On an install serving several client companies, the obvious question is: if a person at company A emails in and gets TICKET-000001, does the next person at company B also get TICKET-000001?

With the default setting, no. One sequence is shared, so company B's first ticket is TICKET-000002. The numbers interleave by arrival time, and no two tickets ever share a reference.

That's not a quirk — it's a requirement. A ticket reference has to be unique across the whole install, because when somebody replies to an email, the subject carries [SDREF:TICKET-000001] and nothing else. There is no company name in a subject line. If two companies both held TICKET-000001, that reply could be delivered onto the wrong customer's ticket.

If you want each company counting from 1, choose Count separately for → Each company. The format must then include {COMPANY}, so you get ACME-000001 and BETA-000001 — each company counting independently, and still unmistakable from each other.

Ticket codes

{COMPANY} renders a short ticket code belonging to the company, set on the company itself under System → Companies.

Leave it empty and FreeITSM works one out from the name — the first three letters, so Acme Ltd gives ACM. The company dialog tells you which one you'd get before you save, so it's never a surprise afterwards.

⚠️ A derived code is a convenience, not a guarantee. Acme Ltd and Acme Group both come out as ACM, and two companies with the same code means two companies producing the same ticket numbers. The company list shows a Ticket code column (whenever there's more than one company) with derived codes dimmed and any clash marked, and choosing per-company counting on the numbering screen refuses to save until every company has a code unmistakably its own — naming the companies that clash, so you know which one to fix.

Codes are tidied up as they're saved: letters and digits only, upper case, up to 12 characters. Type ed-moz 99! and it's stored as EDMOZ99.

---

Renumbering existing tickets

Below a dividing line, under its own heading, sits Renumber existing tickets. It rewrites the reference on every ticket you already have into the scheme above, oldest first.

This is a migration tool, not housekeeping. It's for the situation where you moved to FreeITSM last month, everything is on the old random references, and you'd like the whole estate to look consistent before anybody gets attached to the numbers. It is not something to run because you fancy a change.

There's a whole page on whether you should: Changing your ticket number format. The short version is that not renumbering is usually the right answer.

What makes it safe

Every number a ticket has ever had is remembered, and goes on resolving to that ticket for ever. A customer replying to a two-year-old email quoting the old reference still lands on the right ticket. This is exactly the mechanism that already makes merging tickets safe.

A retired number is also never given to a different ticket. It stays permanently spoken for, because handing it on would mean an old email thread silently arriving on somebody else's ticket — which is worse than not matching at all.

Each ticket also keeps its own dates. A ticket raised in 2024 renumbered under INC-{YYYY}-{#####} comes out as INC-2024-…, not stamped with this year.

Running it

1. Choose your format above and Save it. The tool works from the saved settings, not from what's currently typed on screen.
2. Click Preview. This runs the entire job and writes nothing at all, then shows you how many tickets would change, how many already match, the first few and last few conversions, and what the next new ticket would be numbered afterwards.
3. Renumber stays switched off until you've run that preview. Once you have, it turns on.
4. Confirm the warning. It says plainly what will happen and that it can't be undone.

The whole job runs as one operation: either every ticket is renumbered or none is. A half-renumbered estate would have two schemes in it and a counter matching neither.

When it refuses

Rather than half-finish, it stops before writing anything and tells you why:

• The style is still Random. Renumbering into a random scheme is meaningless, so choose Counting up and save first.
• The format is invalid — the same rules as above.
• Two tickets would get the same number. This is the one that catches the cases nobody predicted: a {TYPE} that renders empty because that ticket type was deleted years ago, for instance. The job checks what it's actually about to write, not just whether the settings looked reasonable.
• A number is already spoken for by a ticket that retired it in an earlier renumber.

In every case nothing has been changed, and the message names the number involved.

---

Permission

Ticket numbering is its own permission under System → Roles: Choose how ticket numbers are made, and renumber existing tickets. It's marked sensitive, because renumbering rewrites the reference on every ticket in the system.

Filling in and reading ticket numbers is ordinary ticket access. This right is only about deciding the shape and running the migration.

---

See also

• Changing your ticket number format — the considerations if you've been running for a while
• Ticket numbering — Developer Guide — how it works underneath
• Merging tickets — the same "old reference keeps resolving" mechanism
• Multi-Tenancy — companies, routing and what's shared
• Mailbox Authentication — how replies are matched back to tickets