Service Desk Workbench

Scope

The service desk is a keyboard-first workbench, not an admin table. This guide keeps the agent-facing workflow and removes private route and API detail.

The Service Desk (the relevant workflow) is the agent workspace. It is a keyboard-first, single-screen workbench — not an admin table.

Shareable URLs

Everything you’re looking at lives in the address bar:

• ticket= — the open ticket, by its number (INC-000048), so the URL you paste into chat works for anyone with permission to see the ticket. Sloppy spellings (inc-48, inc48) and legacy internal-id links (?ticket=123, used by older deep links) still resolve; the URL is normalized to the number form automatically. A number you can’t see (wrong tenant, no permission) shows an error and clears — it never blanks the desk.

• view= — the active queue tab (system key or saved-view id).

• q= — the header search text.

Reloading, opening in a fresh tab, or sending the URL to a colleague restores the same queue, search, and open ticket. Switching queue tabs adds a history entry (back/forward walks your tab trail); selecting tickets and typing in search update the URL in place without polluting history. The New ticket slide-over takes a history entry of its own, so the browser back button closes it instead of leaving the desk (Escape and ✕ still work).

Queues

The left rail shows saved-view tabs. Three are always present:

• My Tickets — open tickets assigned to you.
• Unassigned — open tickets with no assignee.
• All Open — every open ticket in the tenant.

Save view (tab bar) captures exactly what you are looking at — the active view’s filters plus your search text and any custom-field filter — as a new tab. Tick “Share with the whole team” to publish it (needs the shared-view permission; personal views are yours alone and invisible to other agents). Custom tabs show a trash icon while active; deleting a shared view also needs the shared-view permission. System tabs cannot be edited or deleted.

Columns (tab bar) picks which fields each queue row shows — priority, number, status, SLA chip, assignee, requester, updated/created age, and type. The title is always shown, and the MAJOR flag can never be hidden. Column choices are saved on the view itself (shared views push the layout to the whole team). System views use the stock layout — save the queue as your own view first to customize it.

Your organization’s custom ticket fields appear in the same menu under Custom fields, so a queue can show Cost Centre, Site, or whatever your admin has defined, right on the row. Three things to expect:

• A field that applies to the ticket but has not been filled in shows a dash (—).

• A field that cannot apply to that ticket — one set up for incidents only, shown in a queue that also holds changes — shows nothing at all. A dash there would suggest someone left it blank, when in fact the question was never asked of that ticket.

• A field your admin has retired keeps showing the values already recorded against it, with (retired) next to its name. You can remove such a column, but you cannot add a new one for a retired field.

Queues load 50 tickets at a time from the server. When a queue holds more, a Load more button appears under the list with a “Showing X of Y” count (the tab bar shows the same count); changing the view, filters, or search resets to the first page. Working a ticket (replying, transitioning, assigning) refreshes every page you have loaded, so your position in the queue is preserved. The same paging applies to the focus queues on the the relevant workflow and the relevant workflow shells.

Everything Load more fetches stays available for the rest of your session, but the list only ever displays one 50-row window of it on screen at a time — clicking Load more jumps you to the newest window. A long session that has clicked Load more many times shows a small Newer rows / Older rows bar above the list with a “Rows X–Y of Z loaded” count; use it to page back through everything you have already fetched without firing another request. This keeps the page responsive after hours of triage instead of quietly growing an unbounded row count in the background.

Sorting the queue

The sort selector (tab bar, beside Columns) chooses the order the queue comes back in. The ordering is applied by the server, so it holds across every page you load — not just the rows already on screen.

• Focus (recommended) — the default. A ranked order that weighs everything at once: major incidents, how close a ticket is to breaking its SLA promise (and how far past it already is), priority, whether it has been escalated, whether the customer carries extra weight, and how long it has been open. This is the order that answers “what should I pick up next” without you having to compare tickets yourself. It only runs one way — “least important first” is not a queue anybody works.

• Priority (highest first) — what the desk defaulted to before Focus existed, and still available. Worth knowing what it doesn’t say: it ranks a P1 raised ninety seconds ago against no commitment above a P4 that has already breached.

• SLA deadline (soonest first) — the triage order: whatever is closest to breaking its promise comes first. Tickets that have already missed a deadline lead the list, worst first, because an overdue commitment is the most urgent thing in the queue and not a settled one.

• Oldest first / Newest first — by when the ticket was raised.

• Recently updated — by last activity.

Two things about the SLA ordering worth knowing, because they are easy to misread:

• It ranks on the deadline you are currently racing. Before anyone replies, that is the response deadline; after the first reply, the resolution deadline. A ticket raised five minutes ago with an eight-minute response target therefore outranks one whose fix is due tomorrow — which is the whole point, and the opposite of what ordering by resolution date alone would do.

• Tickets with no SLA policy sit at the end of the list whichever way you sort. They are not “least urgent”; nothing is being measured on them. The row says so.

Your choice is part of the queue’s URL, so a link you send a colleague opens in the order you were reading it (see Shareable URLs). The CSV button exports in the same order — useful for handing someone a breach-risk list. The focus queues on the relevant workflow and the relevant workflow have the same selector.

Why a ticket is where it is

Under the sort selector’s chosen order, each queue row carries a short grey line explaining its own position — stated in the terms the queue is actually ordered by, and changing when you change the ordering:

Sorting by	The row says
Focus	“Overdue: resolution 2h past due · Major incident · P1”
Focus	“Response due in 40m · Escalated (stage 2) · P2”
Focus, unmeasured ticket	“No SLA policy · P3 · Open 6d”
Focus, clock stopped	“SLA paused · P2 · Open 3d”
SLA deadline	“2h to response breach”, “3h to resolution breach”
SLA deadline, already missed	“Response overdue by 3h”
SLA deadline, clock stopped	“SLA paused — ranked on its recorded deadline”
SLA deadline, no policy	“No SLA policy — sorted last”
Priority	“Priority P1”
Oldest / Newest	“Raised 4h ago — oldest first”
Recently updated	“Updated 30m ago”

The paused wording is deliberate rather than fussy: a paused ticket keeps the deadline it had when the clock stopped, and that deadline moves once the clock restarts, so the position you are looking at is a snapshot rather than a countdown.

Under Focus, the line names up to three of the things that put the ticket where it is, in the order they matter to you: the SLA commitment first, then anything exceptional about the ticket (major incident, escalated, and which stage), then its ordinary attributes (priority, customer weight, age). Two things are worth calling out:

• “Priority org (+60)” appears only when your administrators have given that customer extra weight, and it shows the number. A queue that quietly favoured one customer without saying so would be exactly the kind of hidden behaviour Beacon does not ship. Weight is set per organization in Manage → Organizations (0–100) and every change is audited.

• “No SLA policy” is a statement that nothing is being measured on this ticket, not that it is unimportant. Those tickets score zero on the biggest signal in the order, so they sit low — the line tells you why, so you can decide rather than assume.

Your team’s workload and breach risk

Insights → Workload (in the relevant workflow) is open to agents, not only to managers. You see it narrowed to the assignment groups you belong to: queue depth per group, open tickets per person, the aging heatmap, and the list of tickets closest to breaching. The page says so at the top — “Showing your teams only” — so a count there is never mistaken for a company-wide number.

Two consequences of that narrowing:

• If you are not a member of any assignment group, the page is empty. That is accurate rather than broken: you have no team’s workload to show. Ask your administrator to add you to your group.

• Untriaged tickets — the ones not yet routed to any group — are not counted there, because they are not any team’s work yet. Find those in the queue’s Unassigned tab, sorted by SLA deadline.

Service delivery managers keep the wider, tenant-wide view.

SLA chip

Every queue row and the workbench header carry an SLA chip driven by the SLA

• Green — on track: “Respond in 42m” while awaiting first response, then “Resolve by 16:30”.

• Amber — at risk: 75% of the SLA budget consumed; strong amber at 90%.

• Grey (paused) — “Paused (awaiting requester)”: the resolution clock is stopped while the ticket is on hold.

• Red — breached or past due (“Response breached”, “Resolution overdue”).

• Resolved/closed tickets show “SLA met” or “SLA breached” in the workbench header.

Click or tap the chip for the full explanation — this works the same on desktop and phone, since the old hover-only tooltip was unreachable on touch (F2.8). The popover shows:

• the SLA policy name bound to the ticket (falls back to “SLA policy” on queue rows, which don’t inline the name to avoid an N+1 per row — open the ticket for the named policy, or expand the popover there);

• the exact due timestamp for whichever target is currently live (response, then resolution);

• while paused, the pause reason (e.g. “Paused — awaiting requester”) and a plain-language recovery hint — what has to happen for the clock to resume (a requester reply, a vendor response, a linked change completing, or simply leaving hold, depending on the reason);

• a View SLA policy link to the policy’s row under Administration → SLA, shown only if your role can see SLA configuration (Incident Manager and Administrator by default — most agent roles don’t, the same way they can’t today; ask an SLA-scoped teammate or your admin if you need the underlying target/business-hours configuration explained).

Countdowns update every 30 seconds. Tickets without an SLA policy show no chip.

SLA clock history (Ops tab)

The workbench’s Ops tab carries an SLA clock history panel — the forensic record behind the chip, from :

• the policy that bound the deadline, with the “why this SLA” explanation;

• every pause of the resolution clock: its hold reason, who stopped and restarted it, the exact span, and the business minutes it credited (an open pause shows its live figure). Pauses recorded before provenance tracking honestly read “not recorded (before provenance tracking)” — the product never invents an authority it doesn’t have;

• a badge totalling the credited minutes (which is exactly how far the resolution deadline has moved);

• every recorded breach (target vs. elapsed business minutes, when);

• every correction — if a breach flag was ever changed after the fact, the panel shows old → new and the recorded reason. Flags are never silently edited.

The same pause/resume/breach moments also appear on the ticket timeline the portal timeline too — the clock’s honesty is not desk-only.

Raising a ticket

New ticket opens a slide-over. If your tenant has ticket templates set up for the type you picked, a Start from a template selector appears at the top: choosing one prefills the title, description, impact, urgency, category, assignment group, and any custom-field defaults.

Category is on the form, under impact and urgency. Open it, type to filter if the tree is large, and pick — categories are shown with their full ancestry (Hardware › Laptop), so you can search for either end of it. Leaving it unset is allowed; you or whoever picks the ticket up can classify it later from the workbench.

A template is a starting point, never a lock — every prefilled field stays editable, and you can change any of them before creating the ticket. That includes the category: a template’s category is shown in the Category field like any other, not applied behind your back. Clear detaches the template: what you can see on the form is kept (nothing you have typed is thrown away), and only the group carried in behind the scenes is dropped. Templates for other ticket types are never offered, and retired templates are hidden.

Nothing you type here is lost. The new-ticket form autosaves to your browser (per tenant) as you fill it in — including the person you picked to raise it on behalf of. Close the slide-over, get pulled into an incident, reload, or have your session expire, and reopening New ticket offers Resume draft / Discard. Nothing is ever restored silently, and the draft is cleared the moment the ticket is created.

Priority caps don’t apply to you

Your tenant may cap how urgent a requester’s own portal report can be (see That cap never applies to a ticket you raise, including one you log on someone else’s behalf from a phone call or a walk-up — you are doing triage, and the impact and urgency you set are taken as they are.

When you open a ticket the cap did apply to, its timeline says what the requester reported and what was applied instead. If you agree with them, re-save the same impact and urgency on the ticket: the priority is re-derived without the cap, the timeline records that you confirmed it, and the requester’s portal note about “an agent will confirm the final urgency” disappears. You don’t have to change a value to something else and back.

Workbench

Selecting a ticket opens it in the right pane without a page reload.

The summary line

Directly under the ticket title, one line says who it is for, what was promised, and what to do next:

“Next:” is a shortcut, not a new control. It picks the one action that matters most right now and takes you straight to the button that was already there — acknowledging, focusing the reply box, resolving, assigning. It follows a fixed order, first match wins:

1. The ticket was merged into another → Open the surviving ticket. Nothing you do here counts; the real record is elsewhere.

2. An incident nobody has responded to yet → Acknowledge.

3. An SLA deadline breached or due within four hours → Respond — response due in 45m / Resolve — resolution overdue 2h.

4. Nobody owns it → Assign to Sam Suggested (suggested) when Beacon has a suggestion (the same one the Suggested triage panel shows, with the same evidence), otherwise plain Assign.

5. On hold → Waiting: waiting on customer since 12 Aug 09:14. This one is information, not a button: the next move is not yours.

6. Resolved → Awaiting closure. Also information.

7. Otherwise → the first thing you can legally do, named exactly as its button in the action bar names it.

If the line says something you disagree with, ignore it — every action it points at is still on screen where it always was.

The four tabs

The body is grouped into four tabs so a ticket opens on what you need rather than on twenty stacked sections:

Tab	What is on it
Activity	The conversation, the timeline, and attachments. The default, because it is the right tab for every ticket.
Context	Custom fields (or the request’s own form), the requester’s history, and their devices.
Related	Knowledge articles, known errors, linked tickets, affected services, and the major incident it belongs to.
Ops	Escalation handoff, tasks, time entries, watchers.

Above the tabs, and always visible whichever one is open: the merged-away banner, the summary fields, the description, and Suggested triage.

Things worth knowing:

• The reply box never moves. The composer is pinned below the tabs and is available on all four — you never have to change tabs to reply.

• A tab keeps its place. Open Ops, go back to Activity, return to Ops: everything is as you left it, and nothing reloads.

• A number on a tab means there is something there — open tasks on Ops, linked tickets on Related. No number means nothing is behind it.

• The tab is in the URL (&pane_tab=ops), so a link you send opens on the tab you were reading.

• A ticket escalated to you opens on Ops, on the handoff brief it was handed to you with. You can switch away and it stays switched; and a link that names a tab always wins.

• A long description is folded to four lines with a Show more — so a pasted log does not push the whole ticket off the screen. The full text is still there, and browser find still finds it.

From the pane, core actions are at most two interactions away:

• Reply / internal note — the composer toggles between a public reply (the requester sees it) and an internal note (agents only).

• An internal draft never becomes a public reply in one click. The tabs still switch freely — previewing what a public reply would look like costs nothing — but if any of the text on screen was written while the composer was on Internal note, pressing Send (or ⌘-Enter) on the Public reply tab opens a type-to-confirm dialog first. It names the requester who will see the text and asks you to type , because a public reply reaches them immediately and cannot be unsent. Text composed on the Public tab from the start, and anything sent as an internal note, never sees the dialog — internal is the direction that is always safe. The check survives a reload: the internal origin of the text is stored with the autosaved draft.

• Your reply is drafted as you write it — the composer autosaves to your browser per ticket, carrying the public/internal choice with the text so a half-written internal note can never come back armed as a public reply. Come back to the ticket after a reload, a session expiry, or a trip through another queue and the composer offers Resume draft / Discard above the tabs. The draft clears when the note posts — and deliberately survives a post that fails, which is exactly when you would least want to retype it. the snippet list, keep typing to filter it (it matches the title, the category, and the body), then pick one with the mouse, or with ↑/↓ and Enter. The snippet body replaces the the relevant workflow you typed and leaves the rest of your draft alone, so you can drop one into the middle of a reply you have already started. Nothing is sent automatically — you edit and send as usual, and you are still the author of what the requester reads. Escape closes the list.

• Transition — the status control offers only legal next states; resolving prompts for a resolution code chosen from your tenant’s vocabulary (fixed, workaround, cannot reproduce, duplicate, known error, no fault out of the box — each with a hint) plus optional resolution notes that feed KB promotion and problem analysis. The code is required and is not pre-selected: pick one, or the dialog tells you so next to the field instead of failing after read, so a guess is worse than a moment’s thought. (An administrator can turn the requirement off for the whole tenant in the relevant workflow → Resolution codes; the same rule then relaxes everywhere.) Marking a service request fulfilled asks for the same thing.

• Assign — pick a group and/or an agent.

• Acknowledge — stops the response clock without changing status.

• Merge — fold this ticket into another one as a duplicate (see below).

Edit-in-place fields (title, impact, urgency) save on blur. The timeline shows the full history.

Classifying a ticket

Category sits in the summary grid beside impact and urgency. Click it, and pick — two clicks, and the ticket is classified. If the tree is long, type in the box at the top of the list to filter it; the filter matches the whole path, so laptop, hardware, or hardware laptop all find Hardware › Laptop. ↑/↓ and Enter work if you would rather not leave the keyboard. Clear the category at the foot of the list removes a classification that should never have been made.

This is your decision and it is recorded as yours. It does not depend on Beacon’s suggestion in any way: the control is there when there is no suggestion, when the suggestion is wrong, and when your tenant has Beacon’s classification switched off entirely. Where a suggestion is offered, the Suggested triage panel below still has its own one-click Apply — that is a shortcut to the same field, not a different way of setting it.

Categories are shown with their full ancestry so there is no ambiguity between two leaves of the same name. A category an administrator has retired is not offered for a new classification, but a ticket already carrying one keeps it, marked retired, rather than appearing unclassified.

You need tickets.update to change a category. With only tickets.view you see what the ticket is classified as, and no control.

Watchers, linked tickets, and time

Three panels sit between the description and the timeline. Each shows you what you have access to and says so plainly when you don’t, rather than looking empty:

• Watchers — people who get the same notifications as the assignee without being the assignee or the requester. Add opens the person picker: type a name or email and pick the person from your Portal directory — a watcher is a verified identity Beacon can actually notify, not a free-typed address. People already watching are greyed out, and Watch this ticket myself adds you in one click. Removing is one click. Needs the watcher permission to change; anyone who can see the ticket can see the list.

• Linked tickets — typed relationships: relates to, duplicates, blocks, caused by, parent of. Link asks for the relationship, then searches for the other ticket by number or title. Links read correctly from both ends — if another ticket blocks this one, this panel says “Blocks (inbound)” rather than pretending the direction is reversed. Clicking a linked ticket opens it.

• Time logged — Log time records minutes against the ticket, with an optional note and a billable flag. The panel header shows the running total. This is what feeds the time report; before it existed nothing in the product could record effort. Minutes must be a whole number greater than zero.

Merging a duplicate

When the ticket you are looking at is a copy of another one, Merge folds it into the ticket that survives. Search for the survivor by number or title — only tickets of the same type are offered, because merge is same-type only.

Merging moves this ticket’s notes, attachments, logged time, watchers, and links onto the survivor, then closes this one as a duplicate and leaves a link pointing at the survivor. Because that is not practically reversible, you have to type this ticket’s number to confirm. The toast afterwards tells you exactly what moved.

Opening a merged-away ticket later shows a banner at the top of the pane naming the survivor, with a button to jump to it — you will never silently work a ticket that is no longer the record of truth. Merge is not offered on a ticket that is already closed, cancelled, or merged, nor on changes and problems (their approval-bearing lifecycles have no honest short path to closure).

Requester context panel

Under the description, Requester context tells you who you’re dealing with before you start work:

• N other open — a chip counting this person’s open tickets other than the one you’re reading. It turns amber above one: that is your cue that you’re looking at a repeat contact, and possibly a problem record rather than another incident.

• Their other tickets — newest activity first, paged. Click any row to jump straight to it; the desk URL follows, so back returns you here.

• Organization badges — plus a blue badge for any SLA, Escalation or Major incident policy that belongs to their organization specifically. If you see one, this requester is not on the tenant default and the clock or escalation path you’re assuming may be wrong. Tenant-wide policies are deliberately not listed — they apply to everybody and tell you nothing about this person.

• Their configuration items — the assets their tickets keep touching, most troublesome first, with a count of their open tickets against each. Click through to the CI in the CMDB.

Read the panel honestly, because it is written to be honest with you:

• “Their configuration items are hidden — ask your admin for the ‘View configuration items’ permission to see them” means the section is withheld from your role. It does not mean they own no equipment.

• “This ticket doesn’t identify a requester” means the ticket names nobody at all — different from “no other tickets from this requester”, which means we know who they are and this is their only one.

• If more CIs exist than fit, the panel says how many it withheld rather than quietly truncating.

The panel shows only what you are allowed to see. If your account is restricted to certain organizations, the counts describe that slice — they are not tenant-wide totals you can’t drill into.

Note the CI list reflects assets this person has raised tickets about, not a register of what they own — Beacon has no asset-ownership field today.

Device panel

Below the requester context, Device shows the requester’s managed device(s) — resolved live from the tenant’s device bridge (Intune, Cadres Relay, Jamf, Nexthink) and from any device CI already linked to the ticket — with a health snapshot: OS and version, compliance state, and when the device last checked in. Portal-reported tickets usually arrive with this evidence already attached: within seconds of submission Beacon looks the requester up, posts a Device evidence attached timeline event, and links the device’s CI when the CMDB knows it. If the requester has several devices, the panel says so and lists them all rather than guessing which one the ticket is about — you pick.

If you hold devices.execute, each device carries one-click remediations. The set is fixed — it is defined in Beacon’s code, not in tenant settings, and nothing on this surface can run a free-form script or command:

Action	What it does	Why it’s on the list
Restart device	Reboots the machine (Intune rebootNow, Relay win_reboot).	The single most effective L1 remediation. Disruptive — the requester loses unsaved work, so this one makes you type the device name to confirm. Tell them first.
Restart print spooler	Restarts the Windows Spooler service — the service name is fixed in code.	Restart, never stop: nothing is left down. Free-form service names are deliberately not accepted.
Flush DNS cache	Clears the resolver cache.	Self-healing state — it rebuilds on the next lookup. Fixes stale-record connectivity complaints.
Clear temp files	Empties the OS/user temp directories.	Reclaims disk, clears corrupt transient files; applications rebuild what they need.
Clear print queue	Purges stuck print jobs.	Queued documents are discarded and must be reprinted — say so in your reply.
Collect disk usage report	Read-only report of what is eating the disk.	Evidence for “my machine is full/slow” without changing anything.
Check Microsoft 365 connectivity	Read-only probe of the well-known M365 endpoints from the device.	Separates “Outlook is down” from “this device can’t reach Microsoft”.

Anything not on that list — stopping services, killing processes, resetting browser/Outlook profiles, arbitrary scripts — is deliberately excluded from one-click use: those either leave something down, destroy user data, or take free-form input, and belong in journeys where approval and consent steps exist. If you need one, use the journey catalog or escalate.

Every dispatch asks you to confirm and states the impact; the dispatch and its outcome (succeeded / failed / timed out / refused by the provider) post to the ticket timeline and the audit log with your name on them. A greyed-out action means no connected provider can perform it for this tenant — the button tells you that up front instead of failing after you click. If you don’t hold devices.execute, the panel shows the devices but not the buttons.

Chat conversation panel

Tickets that arrived through Microsoft Teams show a Chat conversation panel: who reported it, the recent transcript (inbound left, outbound right, with an expander for the full history), and an Identity unverified warning when the reporter could not be matched to a directory user — verify who you’re dealing with before acting on their behalf. You never need to ask a chat requester to repeat themselves; the exchange is already on the ticket.

Your public replies on a chat ticket are pushed proactively into the same Teams thread (with email as the automatic fallback when the thread is no longer reachable), so the requester hears back where they asked. Internal notes never leave the desk.

Working in place on /ops and /engineering

L2 and L3 operators never have to leave their shell to work a ticket. Clicking a row in the Open incidents queue on the relevant workflow or the Escalated to me / My queue list on the relevant workflow opens the full workbench pane inside the shell: the queue collapses to a rail on the left and the same detail pane the desk uses appears on the right. Everything above works identically there — reply, internal note, transitions with resolution codes, assign, acknowledge, edit-in-place fields, KB/KEDB suggestions, major-incident tooling, and — when the ticket has linked CIs — a service impact panel (affected services + open work from the CMDB service map). Actions refresh the queue rail in place, so a resolved incident drops out of an open-only queue without losing your position.

While working:

• Next / prev — the ▲/▼ buttons in the queue header, or j / k (also ↑ / ↓), step through the loaded queue and wrap at the ends. A “3 of 12” readout keeps you oriented; keystrokes typed into the composer or any form field are never intercepted.

• Close (✕) — returns to the plain list and the shell’s overview cards.

• Open in Desk — an explicit secondary link for when you want the full desk (saved views, bulk actions); it is never the default click.

The selection is addressable on the shell’s own URL — the relevant workflow or the relevant workflow reloads to the same in-place workbench, with the same number normalization and legacy-id compatibility as the relevant workflow (see “Shareable URLs”).

Escalating a ticket (the handoff bundle)

Escalation moves a ticket up its escalation policy’s stages — to another group, the current on-call person, a named subject, or a paging channel. Beacon does not let it move the ticket without moving the context, because a ticket that arrives at L2 with no history just gets diagnosed twice.

The Escalation handoff panel sits in the detail pane directly under the

When you escalate, the Escalate button opens a dialog with three things:

• Tried steps — a checklist chosen automatically from the ticket’s category. Beacon looks for a checklist configured for that exact category, then for its parent, and finally falls back to the tenant default, so a “Printers” ticket gets the printer list if there is one and the hardware list otherwise. Tick what you did; each ticked step takes an optional one-line result (“new cartridge, still jams”). Anything you leave unticked is recorded as not done — silence is never read as a claim that you did it. If your tenant has no checklist configured, you are simply not shown one.

• A handoff note — required. Say what you tried, what you found, and what you think the next tier should look at. This is enforced by the server, not just the form: a blank or whitespace-only note is rejected and the ticket does not move, nobody is notified, and no channel is paged. Beacon does not grade the note’s quality, only that you wrote one.

• Diagnostics — if the device bridge captured device evidence for this ticket at intake, it is attached automatically. Nothing is re-run against the requester’s machine at escalation time; you get exactly what was already known. Most tickets have no device evidence, and the dialog says so plainly and escalates normally.

If the ticket cannot be escalated — no escalation policy applies, it is already at the final stage, or it is closed — the Escalate button is disabled and tells you which, rather than accepting the click and failing afterwards.

When you receive an escalated ticket, the same panel is the first thing under the device evidence: who handed it over and when, what they wrote, the tried-steps checklist as they answered it (with a completed count), and the device diagnostics as they stood at that moment. A ticket escalated more than once keeps the whole trail, newest first — L1→L2 and L2→L3 are both readable.

Handoffs are permanent records. Editing or deleting a checklist template later never rewrites what an agent already claimed to have tried, and later device evidence never rewrites the diagnostics an earlier handoff was judged on.

Escalating requires the Escalate tickets permission (escalation.trigger), which service desk agents, L2 and L3 hold by default. Reading a handoff needs only the ability to see the ticket — receiving a handoff never requires the right to make one.

Breaking a ticket into tasks

Any ticket can be broken into tasks — pieces of work that can be assigned to a different group or person and completed independently. The panel sits in the detail pane of every practice, and each one names them in its own language: Subtasks on an incident, Fulfilment steps on a service request, Implementation steps on a change, Investigation strands on a problem.

Type into “Add a step…” and press Enter. That is the whole capture flow — it is deliberately one line of typing, because on a major-incident bridge call nobody is going to fill in a form.

The five task states

State	Use it when
Open	Not started.
In progress	Somebody is working it.
Blocked	You genuinely cannot finish it. A reason is required.
Done	Finished.
Skipped	It turned out not to be needed. A reason is required.

Blocked still blocks the ticket. That is the point of it. If you are stuck waiting on a vendor, mark the task blocked and say so — do not mark it done. The whole feature exists so that “resolved” means resolved.

Why you cannot resolve, fulfil, review or verify yet

If a ticket still has unfinished tasks marked “blocks resolution”, Beacon will refuse to move it to the status where the practice claims the work is done — verified for problems. The action button stays available on purpose: pressing it shows you exactly which tasks are in the way and who owns each one, so you can act rather than guess.

Nobody bypasses this. It applies to automations and integrations as well as people — a journey that tries to fulfil a request with unfinished work fails and hands the ticket to a human. There is no admin override, because a control an administrator can quietly switch off is not a control.

The way out is to skip the task with a reason. Skipping is legitimate and expected — work often turns out to be unnecessary. It is recorded on the ticket timeline and in the audit log with your name and your reason, and it needs the “manage ticket tasks” permission, which is deliberately a higher bar than simply completing your own step. What you cannot do is make an unfinished task disappear silently.

You can also untick “blocks resolution” on a task that was never meant to gate anything — a scratch note to yourself, say. Do that rather than inventing a reason to skip it.

Cancelled and closed tickets

Cancelling a request or abandoning a problem is never blocked — abandoning work in flight is legitimate. When a ticket reaches a terminal status with tasks still open, Beacon skips them automatically with the reason “{number} was cancelled” so they do not sit in anyone’s queue forever. Reopening the ticket does not bring them back: a reopen is new work, and reviving a checklist somebody abandoned would be a worse surprise than an empty one.

Ordering, and changes in particular

Drag tasks to reorder them. On changes only, implementation steps run in order: you cannot start or complete step 3 while step 2 is unfinished, because an implementation plan is a runbook. You can still mark a later step blocked or skipped out of order, so a stuck step never makes a later step’s honest status unreachable.

Deleting

A task can only be deleted while it is still Open. Anything you have started, blocked, completed or skipped is part of the ticket’s record — skip it with a reason instead.

Merging

When you merge a duplicate, its tasks move to the surviving ticket and are appended after that ticket’s own. The work was not finished and was not abandoned; it now belongs to the survivor.

Command palette & global search

Press Cmd/Ctrl-K for the command palette. It searches everything you’re permitted to see, not just tickets: tickets, changes, problems, knowledge articles and configuration items, in one ranked list with each result labelled by what it is. Pick a result and you land in the workspace that owns it — a change opens the change register, a CI opens the CMDB, an article opens the knowledge library, a ticket opens here.

INC-000048), by title or description, and by requester name or email. Everything else matches on its own text: a change or problem on title and description, a CI on its name and description, an article on its title and body. The palette searches the server across all queues, not just the rows currently loaded, and works from the Manage console too, deep-linking back into the desk. Quick actions (declare major, approve changes, calendar, …) stay at the top of the list.

The palette only ever searches record types your permissions let you read, and it says so: if you can see tickets but not the change register, the footer reads “Not searched — you do not have permission: Change” rather than quietly returning fewer results and letting you conclude the change does not exist.

The header search box does double duty: it filters the current queue as you type, and a “Results across all tickets” dropdown shows server-side matches from every queue — so a ticket outside your current view is always one click away.

Bulk actions

With the bulk permission, every queue row grows a checkbox. Selecting tickets opens the bulk bar with three verbs:

• Assign… — three ways to route the ticket, in one dialog:
• Assign to me — one click; you take it.

• Assign to a person — type a name or email; the picker searches your tenant’s Portal directory as you type and assigning is one click on the match. Two clicks end to end from an open ticket (Assign…, then the person). Every assignee picked this way is a verified directory identity — Beacon stores their Portal user id, so notifications and workload reporting can always reach the right human. If you don’t see the picker, you don’t hold directory.view; the control says so instead of failing.

• A group — pick an assignment group from the list. The picker and the suggested-assignee accept (Suggested triage panel) coexist: the suggestion is one click when it’s right, the picker is for when there is no suggestion or it’s wrong.

• Transition… — move every selected ticket to a new status. Pending asks for a hold reason, resolve asks for a resolution code (required, and stamped on every ticket in the batch — Run stays disabled until you pick one), and an optional reason lands on each ticket’s timeline.

• Add note… — one note on every selected ticket, internal by default; a public reply notifies each requester exactly like a single reply would. The audience is chosen with the same two tabs as the single-ticket composer — Internal note (lock icon, amber surface) and Public reply (blue surface) — and the dialog states its audience in words underneath: “Internal only — recorded on each ticket’s timeline and never shown to requesters”, or “Customer-facing — this is sent to the requester of all N selected tickets and cannot be unsent.”

Every action is applied per ticket: a ticket that can’t make the move (an illegal transition, a ticket outside your organization scope) fails on its own without blocking the rest. The bar reports “N failed — details” with the exact per-ticket errors, and keeps just the failed tickets selected so a retry targets exactly them. Every bulk touch is written to the audit log per ticket.

Selecting more than 10 tickets requires typing CONFIRM. Clicking Apply on a batch of 11 or more opens a confirmation step naming the count and asking you to type before it runs — the same type-to-confirm pattern used for deleting a record, just gated on the size of the batch rather than on the verb. At 10 selected tickets or fewer, Apply still runs immediately with no extra step. This is a guardrail against an accidental mass mutation (a slip of the mouse, or a “select all on this page” click on a large page), not a new approval workflow — nothing about who can run the action changes.

Every public bulk reply requires type-to-confirm, whatever the count. Count is not the only axis of impact: a public reply leaves the building. It is emailed to the requester on every selected ticket and can never be unsent, so a public bulk reply to three tickets is gated exactly like a bulk change to three hundred. The phrase names the real audience — you type REPLY 3 for three tickets, REPLY 40 for forty — so the number of people about to hear from you has to pass through your fingers before it passes through their inbox. Internal bulk notes keep the plain count > 10 rule.

Deleting a ticket (administrators)

Beacon never destroys a ticket. Deleting hides it: removes it from every queue, saved view, search, export and report, while the ticket itself — number, status, timeline, attachments, tasks, audit trail — stays exactly as it was. puts it back unchanged.

There is no button for this in the desk yet — deletion is currently an API claims otherwise; the desk pane shows no delete action, and the deleted-ticket list has no page. A desk surface is tracked as follow-up work.

Only a Beacon Administrator can do either. tickets.delete and tickets.restore are administrator-only permissions and cannot be added to a custom role — importantly, agents, L2, L3 and incident managers hold every other ticket permission and do not hold these.

To find something you deleted, use (the deleted-ticket list, gated on tickets.restore). It is scoped like the live queue, so an organization-restricted administrator sees only their own organizations’ rows.

Things worth knowing before you use it:

• A deleted ticket disappears from your service numbers too — SLA compliance, MTTR, CSAT, XLA, workload and the compliance view all stop counting it. That is deliberate (a number about work nobody can open is not a number), but it means deleting a ticket changes a report a customer may have already seen.

• Nothing is lost, and nothing is cleaned up later. There is no automatic hard delete and no retention timer: a deleted ticket stays restorable indefinitely until an administrator restores it.

• The history says so permanently. Deleting and restoring both write an audit entry and a timeline event — the record shows the ticket was hidden and when, which is what explains a gap in an export somebody ran in between.

• Replies stop reattaching. An email or chat reply to a deleted ticket will not thread onto it; it lands as new intake. Restore first if you expect the conversation to continue.

• Deleting an already-deleted ticket, or restoring one that is not deleted, fails with a clear conflict rather than silently doing nothing.

When something can’t load

Beacon distinguishes “there is nothing here” from “we could not find out”, everywhere, and never lets the second borrow the wording of the first.

• A ticket, change, problem, article or CI that won’t open shows why, and a Retry — not a blank pane. Nothing has been changed; the request failed.

• The Assign dialog says “Couldn’t load assignment groups” with a retry when the group list fails. It will not tell you the tenant has no groups unless it actually asked and there were none.

• Known-error and knowledge suggestions say when the check failed. An absent banner means “no match”; it never means “we couldn’t look”.

• Major-incident child tickets report a failed roll-up instead of showing “None attached”, and the comms cadence shows cadence unknown rather than implying none is configured.

• Affected CIs and change collisions report a failed check. A change window with no collision warning means the check ran and found none — silence is never a failed check, because that would make a change look safer than it is.

• Custom-field filters and definitions say when they could not load, rather than looking like a tenant with no custom fields.

Everywhere this applies there is a Retry, so a transient failure costs you a click rather than a page reload.

Light / dark

The desk follows your system theme and can be toggled manually.

On a phone or tablet

The desk is a two-pane workbench on a laptop: queue on the left, the ticket you are working on the right. That split needs roughly a tablet’s width, so below it the two panes become a stack instead of being squeezed side by side:

• The queue fills the screen. Tap a ticket and the ticket fills the screen.

• A Back to queue bar sits at the top of the ticket, returning you to the queue in the same place, with the same filters. On a laptop both panes stay visible and there is no back bar, because you never left the queue.

• The URL still carries the ticket, so a link you copy from a phone opens the same ticket on a desktop and vice versa.

Everything you can do to a ticket on a laptop you can do on a phone — acknowledge, start work, put on hold, resolve, assign, merge, reply publicly, add an internal note. The queue tabs and the toolbar scroll sideways rather than dropping controls, and the search box takes its own full-width row.

Two things are deliberately desktop-only, because they need a keyboard: the ⌘K command palette button and the composer’s keyboard hints. The shortcuts themselves still work whenever a keyboard is attached.

guarantees (skip link, landmarks, focus on navigation) are documented in

Bulk selection across many tickets is best done on a larger screen — it still works on a phone, but selecting more than a handful of rows is what the desktop layout is for.