Team Assignment and Escalation

👥 Assigning tickets to a team, and escalation

Planned / in active development. Nothing on this page has shipped yet. Started after discussion #125. Last updated: 2026-09-10.

Legend: ✅ done  ·  🚧 in progress / next  ·  ⬜ not started  ·  🤔 not decided

---

Where this came from

Discussion #125, raised by Kraleemil, in two parts.

The first asked for structural 1st line / 2nd line escalation — a dedicated Escalate button that changes the ticket's state rather than just its assignee, SLA timers that shift once it crosses the threshold, technical fields that become mandatory, and a De-escalate that bounces it back to the service desk.

The follow-up asked for something narrower and, on reflection, more useful:

I thought about maybe having the possibility to assign a task to a team, it could be when escalating a ticket. Eg. the helpdesk team doesn't know who in infrastructure does x and y. And then infrastructure can dispatch the ticket from the team queue to a person.

That second one turned out to be the real gap, and it makes most of the first one fall out for free.

---

What FreeITSM does today

Worth stating plainly, because it explains the shape of the work.

• A ticket can be assigned to a person, and to a department. It cannot be assigned to a team — there is no team column on tickets at all.
• Teams already exist and already do two jobs: they group analysts, and department_teams controls which departments a team can see.
• There is no tier, line or escalation concept anywhere in the schema. The only thing called "escalation" is SLA breach notification.
• Teams are opt-in. A fresh install has none.

So today, escalating means changing who a ticket is assigned to — which is exactly what the discussion says is too thin.

---

What is being built now

🚧 Assign a ticket to a team

One new nullable column on tickets, pointing at the teams you already have.

Team and analyst are both optional, and independent. All four combinations mean something:

Team	Analyst	Means
—	—	Nobody has touched it
—	Dave	Dave picked it up directly
Infrastructure	—	Escalated, sitting in their queue
Infrastructure	Dave	Infrastructure owns it, Dave is doing it

The rules that keep the two honest:

• Assigning a person never sets or clears the team, and vice versa. No side-effect writes.
• Clearing the person leaves the team behind, so a ticket falls back into the queue rather than into the void when somebody goes on holiday.
• Team assignment is routing, not permission. It does not change who can see a ticket — that stays with the existing department/team visibility. Escalating a ticket must never hide it from someone who could see it a moment ago.

Four ways to set it, all going through the same code so the audit row, the notification and any workflow rule behave identically whichever you use:

• The reading pane — a Team field beside the analyst.
• The right-click menu — a Team submenu beside Assign to, so you can escalate straight from the list without opening the ticket. It carries a None entry to take a ticket back out of a queue, and only appears if your install actually has teams.
• In bulk — select a morning's worth and hand them over in one go. Bell notifications are suppressed for a bulk change, so a team does not get fifty rows in its bell.
• From a workflow — the Create a ticket action can name a team, so a rule can raise a follow-up straight into Infrastructure's queue rather than onto one named person who may be on leave.

🚧 A notification when something lands in your team

Every member of the team gets it on the bell panel.

Three useful behaviours come from the existing notification rules rather than anything new:

• You are never told about your own escalation, even if you are in the receiving team.
• A ticket bouncing between teams produces one entry that updates, not one per hop.
• A bulk reassignment does not spam everybody — bulk changes are suppressed and counted.

It appears in Preferences → Notifications like every other type, so anyone can turn it off.

🚧 Group the ticket folders by team

The folder panel already switches between Department and Analyst. Team becomes a third option, remembered per person like the other two.

"Unassigned" needs no new meaning: it already changes with the grouping — no department in one view, nobody working it in the other. In team view it means no team yet.

🚧 Escalate and De-escalate

A button that hands the ticket to another team, optionally takes the current person off it, records the move in the ticket's history and notifies the receiving team. De-escalate is the same in reverse.

Deliberately not a new state machine — see below.

🚧 Invisible if you do not use teams

A fresh install has no teams, so that is the default rather than an edge case. With no teams defined, none of this appears: no team picker on a ticket, no third folder option. Nothing to switch off, nothing new to learn, nothing changes.

The same rule the company switcher already follows — it renders nothing at all until a second company exists.

---

What is deliberately not in this release

⬜ SLA targets that change on escalation

Asked for in the original post, and the most expensive part.

SLA targets currently hang off priority and nothing else — response minutes, resolution minutes and a working-hours calendar, all on the priority record. Making them vary by team or tier means adding a second dimension to the SLA engine, which affects breach calculation, the warning notifications and the reporting built on top.

That deserves its own design rather than riding along at the end of this one. It is a real request and it is not being dismissed — it is being separated.

⬜ Mandatory fields once a ticket is escalated

Also from the original post. It depends on a per-team or per-tier field policy that does not exist yet, and it is worth seeing how teams get used in practice first.

🤔 A dedicated tier or line concept

The original post describes 1st line and 2nd line as a state the ticket is in, distinct from who has it.

The current thinking is that a separate tier axis would be a fourth thing overlapping department, team and status — and that in practice most service desks express the tier as the team. Service Desk and Escalation Team, or Service Desk and Infrastructure, already carry that meaning. Escalating is handing it to the next team along.

This is also what most ITSM tools do: assignment groups, with movement between them called escalation.

If that turns out to be too thin once teams are in use, a tier is easy to add on top. Adding it first, and finding teams already said the same thing, would be much harder to undo.

⬜ Default team from a form

Also raised in the follow-up: "a default recipient/team of tasks, like when x form is filled out then set recipient/team to y based on z."

Forms already carry their own What happens next actions, so adding "assign to team Y" becomes a small addition once a ticket can belong to a team. Sequenced after, not dropped.

⬜ Assigning tasks to a team

The follow-up says "assign a task to a team". This work covers tickets first. Tasks have their own assignee and their own Involved list, and deserve the same treatment — but doing tickets first keeps the first version small enough to get right.

---

See also

• Discussion #125 — the original request
• Tickets · Multi-Tenancy — Staff cross-company access
• Release notes — where this will appear once it ships