Ticket Types For New Tickets

🧾 A type for every new ticket

When nobody chooses a type, FreeITSM can give a new ticket one: a default type, and rules checked before it that look at how the ticket arrived and what it says. Emails, portal requests, web chats, monitoring alerts and the rest are typed the moment they become tickets.

Shipped in 4.8.0 (#230, asked for by @duongtuanan). The developer guide is A type for every new ticket - Developer Guide.

---

1. 🧭 Where it is

Tickets → Settings → Ticket types, under the list of types: Type for new tickets. It needs the same permission as the Ticket types tab.

Nothing changes on upgrade: the default is None and there are no rules, so tickets arrive exactly as before until you set something.

2. 🔢 How a new ticket's type is decided

1. A type somebody chose always wins. An analyst picking one on the New ticket form, a requester choosing one in the portal, a service catalogue form or a Workflow step that names one, a REST API call that sends one - the rules are never asked.
2. Otherwise the rules, top to bottom. The first rule that matches decides.
3. Otherwise the default type.
4. Otherwise no type, as before.

The ticket's history says where its type came from - for example "Service Request (set by the rule "Requests mailbox")" or "Incident (the default type for new tickets)". Anyone who can edit the ticket can change the type afterwards, as always.

3. 🧩 Rules

Press Add beside Rules. A rule has a name, the type to give, and when it applies. Fill in any of these; leave the rest empty to ignore them:

Part	Matches when the new ticket...
Arrived by	came in by one of the ticked ways: Email, Self-service portal, New ticket form (analysts), REST API, Web chat, Messaging (WhatsApp, Teams, Slack...), Service catalogue form, Workflow, Phone system (3CX), Monitoring alert (Zabbix, domains), From a project or task
Mailbox	arrived at (or will be answered from) one of the ticked mailboxes
Origin	has one of the ticked origins (Tickets → Settings → Ticket origins)
Department	has one of the ticked departments when it is created
Company	belongs to one of the ticked companies - shared rules on a multi-company install only
Subject contains	has any of the words or phrases, one per line, anywhere in its subject, in any case
Requester's email domain	was raised by someone at one of the domains, one per line - example.com also matches mail.example.com

Every part you fill in must match; ticking several boxes in one part means any of them. So Arrived by: Email and Mailbox: requests@ means "emails to requests@", and Mailbox: requests@, access@ means "either mailbox". A rule must have at least one part filled in - for every ticket, set the default instead.

Use the arrows to put the rules in order; a rule can be switched Off without deleting it.

Examples

Rule	Type
Arrived by Email and Mailbox requests@	Service Request
Arrived by Monitoring alert	Incident
Arrived by Email, Subject contains new starter / leaver	Service Request
Requester's email domain supplier.co.uk	Question
Arrived by Web chat	Question

Good to know

• Emailed tickets usually have no department when they arrive - that is set later during triage. So for email, use Arrived by, Mailbox, Origin, Subject and Requester's domain; Department helps portal and analyst-created tickets.
• A portal ticket has no origin, and an analyst's ticket only has one when it is picked. Arrived by is the reliable way to tell channels apart.
• A rule whose type a company cannot use - a type it has hidden, or that has been made inactive - is passed over, and the next rule or the default decides.

4. 🧪 Try it

Try it, at the bottom of the section, describes a new ticket - how it arrived, its mailbox, origin, department, subject and requester - and tells you which type it would get and which rule gave it. Nothing is created. It uses exactly the same rules as real tickets.

5. 🏢 Several companies

On a multi-company install, in the shared (default company) settings you manage the shared rules and the shared default. They apply to every company.

Switch to a company and the section manages that company's own rules and default:

• Its rules are checked first; the shared rules follow them, listed underneath so you can see what happens when none of its own match.
• Its default can use the shared default (the starting point), be None, or be a type of its own.

A company's own types are only ever given to its own tickets. A ticket that has not been routed to a company yet (triage) can only be given a shared type.

6. 🔁 Changing the type later: Workflow

Rules decide the type a ticket starts with. To change it later in its life - when a ticket moves to a team, or its priority changes - use the Workflow action Set ticket type (Workflows). The type must be one the ticket's company uses. The ticket number stays as it is, and a category that belongs to another type is cleared, as on screen.

7. 🔢 Why the type is decided when the ticket is made

If your ticket numbers carry the type - {TYPE} in the format, or a separate counter for each type (Ticket numbering) - the number is made when the ticket is created. Deciding the type at that moment means a service request gets a request number, not an incident one. A type changed later, by hand or by Workflow, keeps the number it already has.

Related pages

• Ticket categories - what a ticket is about, beside what kind it is
• Ticket numbering
• Workflows
• A type for every new ticket - Developer Guide