Service Desk Workbench

Scope

How agents pick up, work, merge and escalate tickets in the keyboard-driven workbench.

The Service Desk is an operator lens over the shared ticket work record. Open Work → Tickets, then select an incident or service request. Legacy the relevant workflow, the relevant workflow, and the relevant workflow links remain supported.

Shareable URLs

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

• The path names the open ticket by its number (INC-000048), so a shared link opens the same record for anyone with permission to see it. Legacy ticket= query links normalize to the canonical path. Sloppy spellings (inc-48, inc48) and legacy internal-id links (?ticket=123, used by older deep links) still resolve; the URL is normalized automatically. A number that cannot be resolved retains its URL and shows a persistent error with Retry. An older ticket is never presented as the requested record.

• 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).

Working one record

The record header shows the complete title and number, status, requester, assigned person or group, customer organization when permitted, and the current SLA commitment. A group-only assignment is an owner; it is not “Unassigned”. Missing display names are described without exposing an identity key as a name. The next action remains alongside the commitment. With ticket-update permission, activate the title or its pencil to edit. Enter or leaving the editor saves; Escape cancels. The saved title remains the heading while editing, and a failed save keeps the draft and error available for correction or retry. Activity, Context, Related, and Operations retain their controls and input while switching tabs. Public replies and internal notes remain separate composer choices.

Opening or reloading a direct ticket, Change or Problem record places keyboard focus on its title once that record loads. You can then tab through the record without first traversing the queue. If you start typing, navigating or using a dialog while it loads, the page leaves your focus where you put it. Refreshes and tab changes within the same record do not move focus again.

Searchable picker options show the full name with any description below it, so long group names remain readable before selection.

Use Show queue to hide or restore the desktop queue rail. Hiding the rail keeps the queue mounted, including loaded pages, filters and ordering. On phones, the queue and selected record use the shared list/detail navigation. Operations and Engineering use this same ticket surface; sort and the escalated filter remain in the URL. The Operations CI rollup shows the server’s top 50 affected CIs and requires CMDB permission to open CI detail.

A failed refresh keeps the current record and reply draft visible, labels the failure, and blocks stale controls until Retry succeeds. Selecting another record immediately removes the old actionable record. Approval failure retains the service-request comment; use Check current status before choosing another decision. Fulfillment keeps its existing status-reconciliation flow when the outcome is uncertain. A failed status check never proves the decision failed.

Handoff requests opens requests awaiting acceptance, when permitted. These requests are not already assigned work; use the handoff briefing and explicit acceptance flow before taking ownership.

Incident command

On an incident, Declare major incident is available above long evidence to operators with the command permission. The declared or stood-down incident’s command surface stays in this location; opening Related is unnecessary. A failed command-state read shows Retry and does not offer declaration based on an assumed undeclared state.

Declare major incident expands its staffing and declaration form on the record. It does not declare until you choose Declare. Before that decision, inspect the named configured audience and, when you also have channel-read permission, paging readiness. The audience is a paginated routing preview, not proof of live Portal access or delivery. Paging readiness uses the incident customer’s governing policy and the tenant channel census; drills require channels explicitly opted into drill paging. Lack of channel-read permission makes that preview unavailable without removing an otherwise permitted declaration action.

During response, the communication deadline and evaluation time come from the server’s governing organization/tenant policy. Refresh reads current incident state. The public Post update form is inline while the response is active; there is no separate communication dialog. Its draft shows the frozen stakeholder audience from declaration plus current ticket watchers. Stand-down previews current matching stakeholder lists; changing a list after declaration can therefore change stand-down recipients without rewriting the update audience.

Posting an update records a public note and linked communication event, and opens the linked receipt on the record after confirmed success. For history, open Communication history and delivery, select an update, and use Check delivery status to inspect its associated notifications. Original notification creation counts and remaining rows are separate. In-app disabled, unread and read states are distinct; email/chat queued, blocked, deferred, skipped, sent and failed states describe their canonical channel record. “Sent” does not prove a person read the message. Missing or historical unlinked records do not prove that the submission failed.

An uncertain update submission keeps its draft and requires Check communication history before a deliberate retry. There is no automatic repeat; repeating can send a duplicate. While a command is pending, its form and dismissal controls are disabled. A failed stand-down remains in its confirmation dialog. Stand-down does not resolve the parent incident or satisfy its required PIR. When the current workflow allows resolution, its existing resolution-code and notes form appears inline after stand-down. The code remains unselected: record the actual outcome. Recoverable failure keeps those inputs. The PIR form opens inline after the server confirms resolution; it can also be expanded earlier where permitted. Submit the required summary, inspect the actual RCA link, then use the separate Close action. Closing before PIR remains refused. A drill PIR creates no live RCA problem. An existing permitted RCA link remains available when reopening the record.

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.

The CSV carries the SLA facts a breach-risk list needs, not just the ticket fields: the policy name, the response and resolution deadlines, the first response time, whether the clock is paused, how much of each budget is used, the assessment state the desk shows, and an outcome per target — missed, policy’s calendar never opens) or not_applicable (no policy). Filter the queue to breached tickets before exporting and every row names its own policy and deadline. The status column shows your tenant’s status label (what the queue displays) and status_key the internal key. Full column list:

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. A ticket whose policy has no working days shows a grey No due date: SLA calendar never opens chip — there is no due date to count down to, and Beacon will not invent one. Ask an administrator to fix the policy’s working days (Administration → SLA flags the policy).

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;

• the current first-response and resolution deadlines, in the recorded policy timezone with its date-specific offset. If that timezone is no longer available, Beacon labels UTC as a fallback. A missing deadline says that no deadline was recorded rather than calling it missed;

• 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.

• every rebind — when a priority change moved the ticket onto a different SLA policy, the panel names the old and new policy and targets, and states how long the ticket ran at the previous priority before the targets moved.

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

The current commitment appears before the escalation handoff in Ops. A handoff or accepted change of owner does not clear a recorded breach: keep the miss and the recovery commitment together until the service is actually restored and verified.

Raising or lowering a priority moves the SLA with it

Change a ticket’s impact or urgency and its priority may change; if the new priority resolves a different SLA policy, the commitment moves with it, from that moment. The clock is not restarted at zero and the elapsed time is not re-judged against the new target — the share of the budget already spent carries across. A P3 that has used half of a 24-hour target becomes a P1 that has used half of a 4-hour target, so it has two hours left, and a downgrade gives proportionate relief the same way. Two consequences worth knowing:

• A ticket that ran a long time at a low priority and is then raised can look healthy against its short new target. That is deliberate — nobody could have worked to a commitment that did not exist yet — and the timeline event says how long it ran at the old priority so the two numbers are read together.

• Nothing you do to the priority clears a breach that was already recorded. The miss was real against the commitment in force when it happened.

A priority change that lands on the same policy changes nothing and is not recorded. Neither is a priority change on a resolved, closed or cancelled ticket — there is no live commitment left to move. If a ticket is on hold when the priority changes, the hold continues uninterrupted; the history shows it as one continuous hold that spans the change.

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.

Open Who is this for? to find a requester by name or email. With directory access, Find the person searches after two characters. Select the named person to fill their contact details. If the directory lookup fails, Retry searches the same text without clearing your ticket title, description, or requester query. A loading message replaces choices until the current search finishes. Without directory access, use the available contact fields.

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.

A template’s title and description can contain placeholders such as {requester_name} or {today}; Beacon fills them in when you apply the template. If you have not chosen the requester yet, {requester_name} stays in the text as written and is listed under the form. Pick the person under Who is this for? and it fills in automatically; if you typed their name by hand instead, press Fill from requester. If you create the ticket with a placeholder still in it, Beacon asks you to confirm first.

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.

If the browser loses the create response, New ticket keeps the original ticket request and its known staged-attachment references. Choose Check current result first. Beacon reads the ticket-create receipt scoped to your current tenant and permissions; it will either show the created ticket and continue attachment recovery, or offer Retry original ticket only when no receipt exists. The retry uses the same request key and unchanged ticket details, so it cannot create a second parent ticket. File contents and upload tokens are never stored in this recovery record.

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 detail summary names the ticket’s Source. Machine-created tickets show both the producer identity and intake channel, such as rmm · machine_api. Use that exact identity when reconciling a monitoring alert with Manage → Ingest activity; do not infer the source from free text.

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 status move Beacon offers you on this ticket, 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). Choosing either tab moves focus into this ticket’s reply box so you can write immediately; it does not send anything.

• 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 Before sending, Beacon also saves an immutable recovery reference containing the exact text, audience, carryover confirmation and known upload IDs. If the response is lost, use Check current note; Beacon reads the original receipt and never posts a second note just because the result was uncertain. Retry original note appears only after the receipt read returns no visible result; the original may still complete, so retry reuses the same reference and exact original content. A confirmed moved note names its current ticket and requester. Review that destination before choosing Use this moved ticket and finish file recovery. The remaining files stay bound to the confirmed note while Beacon rechecks the current destination, including if another merge occurs during recovery.

• Escalate — on an active ticket, the action opens Ops and focuses the inline handoff rationale. It does not send a handoff. Review the named next team and checklist, then use the form’s Escalate button. Beacon captures the ticket’s current requester, service, device, Change and commitment context in the receipt for the receiver. If routing or lifecycle state blocks the handoff, Ops explains that block instead of opening an empty or misleading form. 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. Placeholders in the snippet ({requester_name}, {ticket_number}, appears. One that cannot be filled — say {assignee_name} on an unassigned ticket — stays in the text as written and is listed under the reply box; Send asks you to confirm while any is still there. Edit it out and the warning goes away. If the snippet cannot be filled at all (a connection problem), nothing is inserted and your the relevant workflow stays so you can pick again.

• Transition — the action bar shows exactly the status moves you can make on this ticket right now, for every ticket type — incidents, service requests, changes and problems alike. The list comes from Beacon, not from the page: it follows your tenant’s workflow (including statuses and moves an administrator added or renamed), and it leaves out any move your permissions or the workflow’s automation-only rules would refuse. Each button reads the move’s name — Start work, Put on hold, Resolve, Close, Reopen on an incident; Start fulfilment, Mark fulfilled, Cancel request on a service request; and so on for changes and problems. Your administrator can rename any move (for example Pick up instead of Start work). A move your administrator added without naming it reads Move to , using your tenant’s name for the status. If you see no status buttons, there is no move available to you from here — the workflow has none, or your role cannot transition tickets. A move to a status that needs a hold reason asks for it first; a move that records a resolution (Resolved, Fulfilled, …) asks for a resolution code first; any other move happens on the click. On an incident, resolving shows an inline resolution code choice 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.

• Start work with a public update — a new incident shows the exact requester-visible message before you act. One button moves it to active work and records that public reply atomically. If the response is interrupted, use Check saved result first; a retry keeps the original key and text. Current view, public-note and transition permissions are checked again on every read or replay. If the recorded note no longer matches the saved request evidence, Beacon reports the committed result as unavailable; it never guesses that the stricter start-and-update action was an ordinary note.

• 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.

• Requester’s other configuration items — background assets their tickets keep touching, most troublesome first, with a count of their open tickets against each. They are not necessarily affected by the current ticket; use Related for the affected service and CIs. 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). It shows loading, an honest empty result, or a retry when its CMDB read fails; it never carries impact from the ticket or signed Portal user you were viewing previously. Operators without CMDB access see that access boundary and Beacon does not make the CMDB request. 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)

Open Ops → Escalation handoff in the shared work record. Sending a human handoff advances the selected escalation stage and requests an eligible receiver’s acceptance. The displayed current owner keeps responsibility until acceptance succeeds; the initiating operator may be someone else. Automatic policy and journey routing retain their existing behavior when there is no human request. A notification-only paging stage records its result without claiming that a person accepted ownership or that an external provider delivered it.

Automatic and journey stage advances also record their resulting stage, target, and ownership in the audit trail as system actions. A human handoff remains one operator-attributed escalation record rather than a duplicate automated entry.

For the first request, the handoff form appears inline with the current SLA evidence. It collects the category’s configured tried-steps checklist, a required diagnostic note, and available recorded device evidence. Checklist answers are Not assessed, Completed, or Not completed; an unanswered step is not a claim that someone tried it. Write the result beside an assessed step. Device evidence is captured from Beacon’s records, not rerun against the requester’s machine. Current inventory permissions still control what each reader can see.

The preview names current routing and explains refusal when the target is unstaffed, the policy or lifecycle cannot proceed, or another request awaits acceptance. The server checks these conditions again when sending. A pending receipt shows its deadline and preserves the accountable owner. The history controls page through the complete trail, newest first, including earlier checklists, decisions and reasons.

If the response is lost, your original note, checklist and request key remain saved for the same tenant, signed-in subject and ticket. Use Recover saved handoff request to restore that saved note, checklist and request key and check its current receipt. This does not send the handoff again. If Beacon finds the receipt, review its outcome and select Review recorded handoff. If no committed receipt is observed, the original request may still finish; Retry original request explicitly sends the same saved body and key. If the read fails, the draft remains frozen and Read current status retries only that read. Ordinary unsent editing drafts still offer Resume draft and Discard. A corrupt or foreign recovery reference cannot be used or silently replaced. Storage errors preserve the in-memory intent and block sending until it can be saved; do not create another request to recover an uncertain result.

Receivers open Handoff requests from Work or their permitted desk/lens entry. The selected request keeps its candidate entry and current scoped briefing together: selecting another request changes the context without discarding the queue. Opening or selecting a briefing rechecks the current tenant, organization, group membership, policy, target and expiry.

The briefing names the retained current owner, the signed-in receiver who would become accountable, and that acceptance can queue an assignment notification. Confirm and accept ownership is the explicit inline decision; ownership changes only after the server confirms it. It is not an optimistic assignment. If the response or the follow-up read is lost, Beacon keeps the briefing and requires Read current status before another decision. Return for more information requires a reason and leaves the current owner responsible. The sender or current owner can cancel a pending request. Expired or superseded requests cannot transfer ownership.

After acceptance is read back, Beacon opens the accepted ticket’s operational context, including its handoff trail. An explicitly selected incoming ticket tab is retained. Competing decisions stay unavailable while acceptance is pending or its outcome is unknown; leaving the briefing prevents a late result from redirecting you.

The handoff receipt records whether receiver notifications were queued or suppressed. “Queued” is a delivery intent, not proof that an external message arrived; Handoff requests remains the authoritative in-product work list.

Acceptance means an eligible person now owns the recovery. It does not mean the service is restored. Keep the missed SLA promise and the sender’s committed recovery note visible, perform the actual technical work, communicate the result, and obtain the required requester confirmation separately.

A returned, cancelled or expired request remains historical. Send a new request to this stage previews the current routing and creates a fresh independent acceptance request with new evidence and a new key. It never reopens the old decision or silently rebinds the old receipt.

After accepting a handoff, the current owner can choose Request return of ownership from the handoff trail. Record the workaround, result, and the decision the former owner must make. Beacon saves that request before sending; after a reload, read its current status before any exact retry. The original owner receives a new briefing and must accept it themselves. Until that happens, the current owner remains accountable. Returning, expiring, or superseding this new request never silently restores the former owner.

The briefing distinguishes current context from context captured when the request was sent. SLA assessment time, age, stale threshold and pause state remain visible. Directly linked service identities are not a complete service impact analysis. MIM communication deadlines come from the recorded update or declaration and applicable cadence policy; reminders do not reset the promise. A directly related Change shows its number, title and current status only when your present ticket access permits that Change; otherwise the briefing says it is unavailable rather than implying no Change exists. A stood-down or settled incident has no active cadence promise. These details still require ordinary MIM record access plus tickets.view; receipt participation does not bypass that boundary. The briefing does not expose communication bodies, recipient lists or war-room links.

Reading the handoff practice requires escalation.trigger or escalation.view, together with ordinary ticket scope or the narrowly scoped current-receiver briefing permission. Sending and deciding require escalation.trigger; the server also verifies the actor’s exact relationship to the current receipt. Opening a receipt never grants general access to other tickets or inventory.

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.

Use the adjacent detailed-add control when you need a description, assignment, due date, or a gating choice. While detailed creation, reassignment, or clearing an assignee is saving, leave the dialog open: Beacon blocks another action and does not let Escape, the close button, or the backdrop dismiss it. If it fails, the dialog stays available to retry, and detailed-create entries remain filled.

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.

When a status move is refused

If the ticket cannot make the move you asked for — the workflow has no path from its current status to that one, the move is reserved for automation, or it needs a permission you do not have — Beacon opens a short explanation instead of a generic error. It says what you asked for (from which status to which), why it was refused, and which moves you can make from here, as buttons. Choosing one starts that move the normal way, so putting a ticket on hold still asks for the hold reason and resolving still asks for the resolution code. If there is no move available to you, it says that too. Bulk actions report the same sentence against each ticket that failed.

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. The status list is every move Beacon offers you on at least one selected ticket, using your tenant’s status names; when a move fits only some of them it says so (Resolved — applies to 3 of 5), and the tickets it does not fit are reported as failed in the outcome report rather than silently skipped. If none of the selected tickets has a move available to you, the dialog says that and cannot be applied. A status that needs a hold reason asks for one; a status that records a resolution asks for a resolution code (required unless your administrator turned the requirement off, 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. The Bulk operation outcome report lists the original tickets as succeeded, failed, pending or unavailable with your current access. Each actual action and refused attempt has its own audit record; checking an outcome or replaying an already finished item does not repeat it.

Beacon saves the original operation before sending it. If that save fails, the dialog stays open with your inputs and explains the problem; nothing is sent. After a lost response or reload, use Check status under Unconfirmed bulk operations. This reads the original outcome without sending the action again. If the operation is incomplete, Continue remaining resumes its original request and processes only unfinished items. An unavailable ticket may conceal unfinished work; the report does not call the operation complete merely because there are no visible pending tickets. A missing receipt also requires an explicit continuation of the saved operation rather than a replacement request.

Recovery stays separate from your current queue selection. Failed terminal items are never automatically retried: review their errors and select the appropriate tickets for a new confirmed action. If your permissions change, recovery may be unavailable until access is restored. If saved data cannot be read, retain it and ask an administrator for help; do not clear it and send the same action anew.

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. In New ticket, wait for the custom-field check before creating the ticket. A failed check offers Retry and retains your report and custom answers; missing permission is shown separately. Changing signed account or tenant starts a separate form. Saved drafts now belong to that signed account and tenant; older tenant-only drafts remain stored but are not automatically offered, because Beacon cannot establish which account wrote them.

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.

Form notifications

When a dialog is open, success and error notifications appear below its form in a separate scrollable area. You can reach Dismiss notification by keyboard. Closing the dialog returns remaining notifications to the main notification area. An interrupted connection means the outcome is unverified; check the current record before repeating the change. An Undo action keeps its original deadline when you open or close a dialog.

Choosing a named Teams war-room target

In Manage → Major incidents, edit the policy and search for a team by its name prefix. The search uses the customer’s connected Microsoft Teams tenant, returns up to 20 names at a time, and offers Next matching teams when more exist. Check the ID shown beside a name if multiple teams have the same name. Choose the named team and save the policy; Clear configured team deliberately removes the target.

Discovery requires major-incident declaration and chat-management permissions, an active Teams connection, and the customer’s Graph discovery consent. A readable name is not proof that Beacon can create a channel or deliver a message. Those outcomes retain their separate incident evidence.

If a saved team cannot be resolved, the form retains it and states that its name is unverified. Retry the read or ask the chat administrator to repair connection or consent. You can still save an unrelated policy change without replacing the saved target. Search and save failures remain visible; failed saves keep the form values. Keyboard users can open the team selector with Enter, Tab into the matching choices, and select with Enter.

File recovery after a confirmed submission

A confirmed ticket or reply is not resent when a file claim is partial or unconfirmed. Keep the recovery panel, use Check current files, then retry only its remaining uploaded files. Files have ticket-level visibility even when the note is internal. The note receipt controls remain available beside the file panel, so Check current note can detect a later merge before any remaining Reply and report drafts are now scoped to the signed tenant and person; legacy tenant-only drafts remain stored but are not automatically restored because their owner cannot be established. An independent unsent reopen reason is preserved.

If your session expires during a request, Beacon refreshes it once and continues the same request when you are still the signed-in person. Signing out or changing accounts while that refresh is pending stops the old request from continuing under the new account. If refresh cannot restore the current session, Beacon saves queued drafts before returning you to sign-in. A cancelled or timed-out request is not replayed later; use the workflow’s visible recovery control before repeating a mutation whose outcome is uncertain.

Record request fulfillment

After required approval, choose Start fulfillment on the request work record. The outcome form then appears inline. Choose the truthful request outcome, record the actual result in the notes, and confirm it. Stock codes use delivery-specific wording such as Delivered and working while retaining the tenant reporting classification underneath. No code is selected for you. A status label or notification is not proof that a provider or physical delivery completed; record and verify that work first.

If the response is interrupted, keep the code and notes and choose Check current status. A failed check preserves them. A current fulfilled or closed state prevents another submission and does not identify which attempt caused it. If the request remains in progress, review the record before retrying. The requester separately confirms whether the outcome was received.

Fulfillment notes and the chosen outcome are saved for your current tenant, account, and ticket. Reopening the record offers Resume draft or Discard. If a submission was in flight, Check current status is required before another fulfillment attempt, even after discarding its draft notes. Escape inside an edited or recovering fulfillment form keeps the record open. If the recovery checkpoint cannot be saved, no fulfillment is sent; restore browser storage and retry with the retained input.

Keyboard Tab traversal through untouched fields does not delay the desk letter shortcuts. After actual typing, the existing brief typing guard still prevents continued prose from invoking actions on a different record.

An escalation’s compliance audit records the authoritative ticket organization alongside its tenant and initiating actor, in the same transaction as the handoff. Prepared journey qualification uses the ordinary queue’s supported q search to retain its 15-ticket cohort (one P1 and fourteen P4 comparators); that controlled workload does not establish tenant-wide growing-queue scale.

Start a request from its queue context

For an approved request whose complete answers are available, the queue displays the requester, recorded owner, approval state and submitted answers beside Start fulfillment. This action opens the request’s Context tab after starting work; it records no delivery. Review actual outcome notes and choose the explicit Confirm request outcome: … action when fulfillment is complete.

If a start or fulfillment response is lost, check current status before deciding again. The observed status does not prove which earlier attempt succeeded. Saved fulfillment intent cannot be replayed after another change to the request; when the same cycle is still in progress, a successful current-status read retains the notes and lets the operator make a fresh outcome decision against that revision. A changed reopen cycle still requires a new intent: discard that earlier intent explicitly, review the current record, and author a new decision. A storage failure prevents dispatch and preserves the visible input.