Administration Console

Scope

The administration console is where the desk is configured and where its health is read. This public guide keeps the operator-facing sections and removes private implementation detail.

The the relevant workflow shell is where administrators and managers configure the service desk. It is a console with a grouped left rail; every section is gated by permission, so an operator only sees the sections they can use. Press ⌘K / Ctrl-K anywhere to jump to a section from the command palette.

Every section is its own route (frontend/src/pages/manage/ManageConsole.tsx), notification_templates), Automation & governance (improvements, the relevant workflow). Admin subsections are bookmarkable and shareable, and browser back/forward moves between sections (⌘K section jumps navigate the same routes). Bare the relevant workflow lands on First-run setup (the relevant workflow) while your tenant still has setup to do, and on the first section you can see once it does not — so a brand-new tenant opens onto a guided checklist rather than an empty report. A direct URL to a section you lack permission for keeps the console up and states exactly which permission is missing; an unknown section key shows a friendly fallback.

Beacon ships ready out of the box: a fresh tenant is seeded with sensible defaults for SLA, escalation, on-call, the service catalog, assignment groups, governance, change freezes, escalation checklists, and the major-incident policy. Every section below renders something useful on day one — you edit the defaults rather than start from a blank page.

When a section can’t load something

Every section distinguishes “nothing is configured” from “we could not find out”. Where a dropdown, picker or panel fails to load, you get a short message naming what failed and a Retry — never a silently empty control that reads as “there is nothing to choose”.

This matters most where an empty control changes what you would do:

• The customer-organization scope selector (Branding, Terminology, Escalation, Priority matrix, Notification templates, Migration, Major-incident policy) is hidden when a tenant has no organizations. If the list merely failed to load, you are told — so you do not save a tenant-wide change believing there are no customers to scope it to.

• Directory lookups (Agent org access, Assignment group members) say the lookup failed rather than showing no results, which would read as “no such user exists”.

• On-call schedules say when the current-rota read failed instead of displaying “No one is on call”. operator recipient picker all report load failures rather than presenting an empty list of choices.

• Migration invalid-record and commit-error lists report a load failure rather than showing nothing beneath a count that says rows exist.

Picking a record from a long list

Fields that choose another record — a customer organization, an assignment group, a category, a dashboard, a ticket template, a journey, a custom field — are searchable pickers, not plain dropdowns. This is the same control the category picker on a ticket uses, so it behaves identically everywhere:

• Click the field to open it, then type to filter. The filter matches both the record’s name and its secondary line (an organization’s external reference, a group’s description), so either end of what you remember finds the row.

• Arrow keys move through the matches, Enter picks the highlighted one, Escape closes without changing anything, and clicking elsewhere closes it.

• Lists shorter than seven rows skip the filter box — the rows are the whole affordance at that size — but behave the same in every other respect, so the control does not change shape underneath you as your tenant grows.

• Retired records stay listed, marked retired. An escalation rule attached to a customer you have since retired has to remain readable and editable.

• If a list is long enough to be capped, the picker says so — “Showing 100 of 412 — keep typing to narrow it down”. It never truncates silently, which would convince you a record does not exist.

The dividing line is who authors the list:

• You author it, so it grows with you — organizations, assignment groups, categories, resolution codes, hold reasons, SLA policies, on-call schedules, alert channels, dashboards, ticket templates, journeys, custom fields. These are searchable pickers.

• Beacon authors it, so it is bounded by what we ship — priority, impact, urgency, status, change type, report metrics, journey step actions, the built-in role names. These stay plain dropdowns: they are short, and a new one only appears when you upgrade.

A per-field choice list you configured on a single custom field (a “select” custom field’s own options, a journey parameter’s allowed values) also stays a plain dropdown — that list belongs to one field and is small by construction.

Sections at a glance

Section	Permission (view / manage)	What it configures
Dashboards	reporting.view	Your own arrangements of the Reports metrics: pick metrics, set their filters, size and position them on a grid, keep them private or share them with a role or the whole tenant
Workload	reporting.workload	Live queue depth per group, open tickets per agent, aging heatmap, SLA breach-risk list, stranded-escalations list
XLA scorecard	reporting.view	Experience metrics computed from the ticket timeline: composite score, per-agent and per-requester-group lenses, frictions, skills gaps
Compliance	reporting.compliance	Whether policy was actually followed: PIR completion and backlog, emergency-change rate, CAB sign-off rate, collision overrides, freeze bypasses, self-approval refusals, approver delegation coverage, escalation handover quality, resolution-code completeness
Organizations	admin.organizations.manage	Customer organizations: names, external refs, active flag, tenant default
Agent org access	org_scope.manage	Restrict operators to specific client organizations (client-siloed agents)
Branding	admin.settings.manage	White-label the requester portal + notification emails (name, color, support email, logo)
Attachments	admin.settings.manage	Upload limits, extra blocked file types, whether unscanned files are downloadable, and requeueing failed/unscanned virus checks
Ticket fields	admin.settings.manage	Tenant-defined custom fields on incidents/changes/problems (desk render, queue filter, CSV export)
Terminology	admin.settings.manage	Rename display labels (ticket types, statuses, portal strings) — machine values untouched
Hold reasons	admin.settings.manage	Tenant vocabulary for pending substatuses: add/rename/deactivate/reorder; SLA pause semantics fixed
Resolution codes	admin.settings.manage	Tenant vocabulary for the resolve dialog: add/rename/hint/deactivate/reorder; machine codes fixed
Priority matrix	admin.settings.manage	The impact × urgency → priority grid (cells editable 1–4; axes fixed; new tickets only)
Notification templates	notifications.preferences.manage	Per-event wording of bell + email notifications with fixed placeholders
Service catalog	catalog.view / catalog.manage	Categories + offerings with dynamic request forms
SLA policies	sla.view / sla.manage	Response/resolution targets, business hours, holidays
Escalation	escalation.view / escalation.manage	Staged escalation targets for SLA breaches (groups, on-call, people, or paging an alert channel)
Escalation checklists	escalation.view / escalation.manage	Tried-steps checklists shown in the desk’s Escalate dialog, one per category or a tenant default
On-call	on_call.view / on_call.manage	Rotations, participants, overrides
Assignment groups	groups.view / groups.manage	Queues + membership + auto-assignment policy (round robin / least open, business-hours gate)
Improvements	improvements.view / improvements.manage	The continuous-improvement register (VoC feedback, process/SOP gaps, SLA actions): routing, due dates, closure with a terminating outcome
Major incidents	incidents.major.declare	Auto-declare threshold + comms cadence + page-on-declare + war-room team + stakeholder lists
Change freezes	changes.freeze.manage	Freeze windows
Approvals	approvals.decide (+ admin.settings.manage for the policy and repair cards)	Approval inbox for every ticket type, self-approval policy, and the stranded-ticket repair
AI provider	ai.config.manage	Beacon-managed classification (on by default) + BYO-AI provider + budget
API keys	integrations.keys.manage	Tenant API keys (public REST API + machine ingest): mint/scope/rotate/revoke
Ingest mappings	integrations.org_mapping.manage	Source-product org reference → Beacon organization mappings
Chat (Teams)	integrations.chat.manage	Microsoft Teams connection + verification code
Chat (Slack)	integrations.chat.manage	Slack workspace connection (“Add to Slack” install)
Automation providers	integrations.automation.manage	Device/service provider connections journeys dispatch through (health, capabilities, job history)
Alert channels	integrations.alerting.manage	PagerDuty/OpsGenie paging: credentials, summary templates, circuit-breaker health, dispatch/dead-letter retry
Email intake	integrations.email.manage	Inbound mailboxes (email-to-ticket): IMAP credentials, polling health, allowlists, intake activity
Directory	directory.view	Read-only mirror of the Portal directory, plus the leaver impact card: deactivated people who still have open tickets, pending approvals, group-roster or on-call slots, or delegations pointing at them. Beacon never reassigns silently — each row is a decision for you, and it disappears once nothing points at the person. SLA clocks keep running throughout; deactivation never pauses a promise
App access	directory.view	Portal-managed marketplace access (read-only) + effective-access lookup
Notification deliveries	notifications.preferences.manage	Per-lane (email/chat) delivery log and retry for the tenant’s own outbound notifications; failed-lane depth and oldest-wait summary
Migration imports	admin.migration.manage	Upload a ServiceNow/Freshservice export, review the dry-run reconciliation report, then commit or discard
Runtime health	admin.runtime.view (+ integrations.alerting.manage to set the health pager)	Beacon’s own operational state: per-lane leadership and lag, mid-tick demotion counters, which alert channel Beacon pages about itself, and the secret-rotation history

Reports

Operational analytics over the last 30 days by default (adjustable from/to range, quick 7/30/90-day presets): headline KPIs, SLA compliance, CSAT, MTTR and first-response by priority, and time tracked. Numbers respect your org restriction if you are a client-siloed agent.

• The window is UTC, and it says so. Under the heading you will see e.g. Window 2026-07-01 → 2026-07-31 (UTC). Day boundaries are UTC ones, not your local midnight — so a ticket resolved at 00:30 on 1 August in Tokyo counted in July. The page states the zone rather than quietly re-drawing the dates in yours.

• “Open tickets right now” is not a period number. It sits in its own tile above the For the selected period block because it ignores the date range entirely: it is a live count taken when the page loaded, stamped with the time. Change the range to last January and it still shows today’s open work — that is correct, and now visibly so.

• Every number is a link to its queue. Click any KPI figure, compliance percentage, breach count, priority row, series bar, CSAT slice, agent row or ticket-type row and the Service Desk opens filtered to exactly the tickets that number counted — not a rough approximation of them. The desk shows a Filtered from a report banner so you can see the queue is narrowed, with a Clear report filter button that returns you to the full queue while keeping your own search and queue tab.

• The window travels with the link, on the right clock: the SLA card filters on when tickets resolved, the first-response card on when they were first responded to, the CSAT card on when the response arrived.

• The SLA links carry “had a policy bound” as part of the filter, because tickets without one are neither met nor breached and are excluded from the percentage.

• “Open tickets right now” links with no date range, because the number ignores the range too.

• A day or week bar opens only the days it actually counted — a partial first or last bucket is trimmed to the report window, not rounded out to a full week.

• Where a figure genuinely has no expressible filter — the (not set) bucket of a custom field, since a queue filter matches a stored value and cannot match “the field was never filled in” — the figure stays plain text rather than offering a link that would open the wrong tickets.

• Every number also lists a sample. Alongside the link, KPIs and the SLA breach bars carry a View N tickets button showing the most recent 20 behind that figure without leaving the page. It is a sample; the link above is the whole population.

• Every figure explains itself. The small ⓘ beside each figure opens its definition: what the number measures, separately which records were counted (the denominator, in plain words), how many records that was, and the target it is being judged against. Tap or click — it is not a hover tooltip, so it works on a phone. The SLA card’s population in particular says “tickets that resolved inside the window”, which is what makes its breach count different from the Workload tab’s (see Workload below).

• Targets and variance. Where your organization has set a target for a measurement, the figure carries a chip showing the gap — e.g. -4% vs 95% in red, or +2% vs 95% in green. If nothing qualified in the period the chip reads No data vs 95% in neutral grey rather than scoring a miss against zero, and where no target is set there is no chip at all: Beacon does not invent a promise you never made.

• Targets are set by an admin (admin.settings.manage plus reporting.view) and are per-measurement, not per-report — set “95% resolution SLA” once and the summary tile, the SLA compliance card and the customer’s service review all report against that same promise.

• The available targets are SLA resolution and response compliance, CSAT average, mean time to resolve, mean first response, open backlog, resolved per period, major incidents per period, and post-incident-review completion. Each has a fixed direction — a lower MTTR is better, a higher CSAT is better — which is not configurable, so a target can never be set to mean the opposite of the metric.

• Anyone who can read reports can see the targets. The promise is part of reading the number.

• When the numbers were taken. The summary header and each report card carry a Generated … stamp, in your own local time. If a page has been open a while, that is how you know.

• CSV downloads — the summary block and every report card carry a CSV button exporting exactly what the current range shows (same filters, same org scoping). Downloads are audited.

• Tickets by custom field — pick any custom ticket field your organization has defined and see volume grouped by its values, with how many were resolved, how many breached SLA, and the average time to resolve for each. The card states what it counted, and it is worth reading:

• It reports only on the ticket types the field applies to. A field set up for changes reports on changes; it does not pad the numbers with every incident that could never have had a value.

• For a multi-select field, a ticket counts under each value it carries, so the rows add up to more than the ticket total. The card says so.

• A retired field still reports on the values it captured, and says it is retired so you know why the numbers have stopped moving.

• Tickets with no value are grouped as (not set), listed last however many there are.

• Tickets by requester attribute — the “how does Finance feel about IT” volume view: tickets grouped by the requester’s department, location, or business unit as it stood when each ticket was created (a later team move never rewrites history). Same columns as the custom-field card, same (not set) handling, own CSV. Where the data comes from (read this before relying on it): the attributes sync from the Portal directory, and Portal does not provide these fields yet. Until it does, every ticket shows (not set) and the card says exactly that in plain words — this is the expected state, not a fault. The moment Portal ships the fields, new tickets pick them up automatically; existing tickets keep their honest (not set).

• Group-by on MTTR / first response — both series cards carry a picker: by priority (the default) or by requester department / location / business unit. The CSV follows whichever grouping is selected.

• CSAT slice — the CSAT card’s picker adds a per-department (or location / business unit) response count and average under the distribution, from the attribute stamped on each rated ticket. Same (not set) honesty.

• Service review (requires reporting.service_review) — see below.

• Scheduled email reports (requires admin.settings.manage in addition to reporting.view) — email any report on a fixed cadence: daily (covers the previous day), weekly on a chosen weekday (previous week), or monthly on a chosen day-of-month (previous calendar month; day 31 clamps to shorter months). All times UTC. Recipients are operators (picked from known identities, resolved to email at send time) and/or explicit email addresses. The email carries top-line numbers in the body and the full CSV attached, configure Notification email first; a schedule without a working relay retries briefly, then shows an error badge with the reason. A missed window (e.g. maintenance) sends once on the next pass and never duplicates. Data is scoped to the creator’s org restriction — except the service review, which names its own organization (see below). Creation, edits, deletion, and every send are audited. Scheduling Tickets by custom field asks you which field to group by; the email subject names it (“Tickets by Cost Centre”) so several breakdowns landing on the same morning stay distinguishable. If that field is later retired the schedule keeps running on the values it captured rather than silently failing. Scheduling Tickets by requester attribute works the same way: pick department, location, or business unit, and the subject names it (“Tickets by department”).

Service review (the monthly customer report)

The report you take into a customer’s monthly service review, and the one they receive by email. It covers one organization and a single period:

• SLA attainment — resolution and response, overall and by priority;
• CSAT — average, response count, score distribution;

• Volumes and trend — raised by type and priority, resolved, each compared with the previous period;

• Major incidents — every major declared in the period and whether its post-incident review is complete;

• Improvements — the “you said / we did” record: improvements you closed, split into ones raised from this customer’s feedback and service-wide ones.

Pick the organization and period, then either Open branded HTML — the exact artifact the customer receives, ready to print or forward — or CSV for the underlying data. The period defaults to last calendar month, which is the period the scheduled email delivers; change the from/to dates for an ad-hoc range.

The preview is a working surface, not a printout:

• Every major is a link. The ticket number and the title in the majors table open the incident in the Service Desk, so “what happened on the 9th?” in the meeting is one click, not a search. (Those links are for you — the branded HTML the customer receives does not send them into your desk.)

• Each headline figure carries its ⓘ and its target, exactly as on the dashboard, so you walk in knowing whether 91% was a good month against what you committed to. The figures also drill through to that customer’s tickets — and only that customer’s.

• It says when it was generated, under the organization and period.

Three things worth knowing before you send one:

• The numbers are the same numbers. Every figure comes from the same aggregation as the dashboards and CSV exports, filtered to that customer. The review cannot disagree with what the customer sees in their own portal.

• Outstanding post-incident reviews are stated, not hidden. If majors in the period have no completed PIR, the customer’s report says so — and the preview warns you before you send. Get the PIRs done, or expect the question.

• A quiet month reads as quiet. Rates with nothing to measure show as “—”, never 0%, so a customer with no SLA-bound tickets is never reported as 0% attainment. A month with no majors shows PIR completion as “—”, not 100%.

Branding follows your Branding settings, including any per-customer overlay — a customer with their own logo or colour gets their own, falling back to your tenant branding field by field. Generating the HTML is audited.

To send it monthly, create a scheduled email report, choose Service review, and pick the organization; the schedule then carries that organization rather than inheriting your org restriction. Deleting an organization deletes its service-review schedules — it never silently widens them to cover every customer.

Dashboards

Who sees it: reporting.view — the same permission as Reports.

Reports is the fixed page everyone gets. Dashboards is where you build your own: pick the metrics you actually look at, set each one’s filters, size and place them, and open that one screen instead of scrolling the whole Reports tab.

Create a dashboard, then Add widget. Choose a metric, optionally give it your own title, and fill in whatever the metric needs — the Tickets by custom field widget asks which field, the Service review widget asks which customer, MTTR and First response let you choose what to group by. Leave the two “Pin” dates blank and the widget follows whatever window you view the dashboard with; set them to lock that widget to a fixed period regardless.

Arrange with the small buttons on each widget: nudge left, right, up and down, make it wider, narrower, taller or shorter. The grid is 12 columns wide, so a half-width widget is 6. Moving a widget up or down also moves it in the reading order, which is what a keyboard user and the mobile single-column layout follow.

Who can see your dashboard

Three choices when you create one:

• Only me — nobody else sees it exists.
• A role — everyone holding the role you pick sees it, and so do you.
• Everyone — everyone in the tenant who can open this tab sees it.

Sharing shares the layout, not the data. This is worth reading twice, because the natural assumption is the opposite. Every widget is still checked against each viewer’s own permissions and org restriction each time it is drawn. If you put a Service review widget on a dashboard you share with everyone, a colleague without reporting.service_review opens that dashboard, sees the rest of it normally, and sees that one tile as “you do not have access to this” with the missing permission named — not blank, not an error, and certainly not the customer’s numbers. A client-siloed agent gets the same treatment for a customer outside their org access.

Only the person who created a dashboard can change or delete it, whoever it is shared with. If you want your own version of a colleague’s dashboard, create one and add the widgets you want; a shared dashboard should mean the same thing to everyone reading it.

Deleting a dashboard removes it for everyone it was shared with. It never touches the reports themselves — Reports, CSV exports and scheduled emails are unaffected.

What a dashboard cannot do (yet)

Widgets show existing metrics. You cannot define a new number that combines two of them (say, “MTTR per resolved ticket”) — that is a genuine gap, not a hidden feature, and it is recorded as out of scope in schedule; use a scheduled email report for recurring delivery.

Workload

Who sees it: reporting.workload — held by the Incident Manager role (the service-delivery-manager persona) and Beacon Administrators. Everyone else does not see the tab at all. It is deliberately narrower than reporting.view, because this page names individual agents and shows how much each one is carrying.

Where Reports tells you how last month went, Workload tells you what is happening right now. It takes no date range: every number is the queue as it stands at the moment you loaded the page, stamped As at in the top row. Press Refresh for a fresh reading.

If you are restricted to particular customer organizations, everything here is restricted the same way — you see your customers’ queues and nobody else’s.

The top row

Open tickets is everything still needing hands on it. Resolved tickets are not counted: once it is resolved it is off the agent’s plate, even though the desk still lists it until it closes. Already breached is work that has missed its resolution commitment. At risk of breaching is the count of the breach-risk list below.

Each tile prints, in small text underneath, exactly which tickets it counted. Read it once — particularly for Already breached.

“Workload says 5 breached, Reports says 2” — both are right

They answer different questions, and neither is a fault:

• Workload → Already breached counts open tickets that are already late, right now, whenever the breach happened. It is the late work still on the floor.

• Reports → SLA compliance → breached counts tickets that were resolved inside the date range you chose and had an SLA policy attached. It is how the finished work went.

A ticket that breached in June and is still open is in the first number and not the second. A ticket that breached and was closed last week is in the second and not the first. Both pages now state their population next to the number, so you can tell at a glance which question you are looking at.

Stranded escalations

Escalated tickets that currently have no owner at all — no individual agent, and either no assignment group or a group with nobody in it. This is the most urgent card on the page: every row is live customer-facing work that an escalation handed to nobody, most often because a stage fired into a group whose members were never added (escalating to a group intentionally clears the individual assignee, so an empty group strands the ticket the moment the stage fires).

Each row shows the ticket, its escalation stage, how long it has been stranded, and where it is sitting (“group — no members” or “No group, no assignee”). To clear a row, either assign the ticket to a person or add members to the group it sits in — the card reads the live queue, so it clears on the next refresh. The count in the heading is the full total even when the list is capped.

The escalating agent is warned before this happens: the escalate dialog names the target and its member count, and shows an explicit warning when the target reaches nobody. The ticket’s timeline also records the moment (“Escalation stage N reached nobody: …”), so the stranding is visible from the ticket as well as from this card.

Breach risk

Open tickets that have used 75% or more of their resolution time, worst first, with the percentage of budget consumed. Amber from 75%, red from 90% — the same two thresholds Beacon uses to mark a ticket at risk on its own timeline, so this list and the ticket agree.

The percentage is real working time, not clock time. Under a 9–5 policy a ticket raised at 4pm Friday has not burned its weekend, and will not appear here on Monday morning purely because two days passed.

Tickets that have already breached are not listed. This list is the work you can still save; the breaches you cannot are counted in Already breached and against their group and agent below.

Queue depth per group

One row per assignment group, deepest queue first. No owner counts tickets sitting in that group with no individual agent picked up yet — usually the number worth acting on. Tickets belonging to no group at all appear as an Unassigned row, never hidden.

The Open and Breached numbers are clickable: they open the tickets behind them (the 20 most recent; the number beside them is always the full total). Every aggregate on this page and on Reports has that route to its tickets — you should never have to take a number on trust.

Open per agent

What each person is personally carrying, heaviest first, with Oldest showing the age of the longest-held ticket. That last column finds the agent sitting on one ancient ticket, which a headline count alone hides. Unassigned open work is shown as its own row so the agent numbers and the group numbers add up to the same total.

Only genuinely ownerless work shows as “Unassigned”. Beacon works out each agent’s name from the ticket, then from the Portal directory; if it can do neither it shows their Portal subject rather than lumping them in with the unassigned pile. If you see a row with an opaque identifier instead of a name, that ticket was assigned without picking the person from the directory — it is owned, and reassigning it through the person picker will give it a name.

Aging

Where work is piling up, bucketed under 1 day / 1–3 days / 3–7 days / over 7 days, and shaded so the hot corner is obvious. Switch between By group and By priority — the toggle is instant, because both are already loaded. The priority view keeps P1 at the top regardless of volume.

XLA scorecard

Experience metrics computed straight from the ticket timeline — did the user actually get helped, as opposed to did the process run on time. Every number drills through to the tickets behind it.

Small samples do not get a score. On the Agents tab (and the requester-group tab), anyone with fewer than 5 resolved tickets in the window shows n/a (<5 resolved) instead of a composite, and sorts below everyone who has one. This is deliberate: an agent who resolved a single clean ticket would otherwise score 100 and sit at the top of a table people read as a ranking. The row still appears with its real resolved count — the score is withheld, the person is not hidden.

Compliance

Whether policy was actually held to, across incident review, change control, approval authorization and closure quality — in one window. The other Insights tabs answer “how did we perform” and “who is drowning right now”; this one answers “did we follow our own rules”.

Nothing here is a new rule. Every number is read out of a control another part of Beacon already enforces — the PIR close gate, the CAB, the segregation-of-duties refusal, the CI-collision warning, the escalation handoff, the resolution-code gate. If a number looks wrong, the record behind it is one click away.

Every tile tells you four things, because a compliance number you cannot interrogate is worse than no number at all:

• What it measures and, separately, which records it counted — the denominator, in words. Two correct numbers look contradictory until both say what they counted.

• A target, with the direction that counts as good (≥ 100%, ≤ 0).

• A verdict — green when the target is met, red when it is not, and deliberately grey when nothing qualified. “No major incident resolved this month” is not a compliance failure, and this tab will not colour it as one: it shows an em dash and says so in as many words.

• The exceptions. “View N exceptions” opens the records that failed the control — the majors with no review, the changes approved without a CAB signature, the escalations handed over with a one-line note. Never a sample of the ones that passed. A tile with no exceptions shows no button rather than a dead one.

The window defaults to the last 30 days and is stated in UTC, alongside the moment the report was generated. Report days are UTC days; showing them in your own timezone would put a record outside the window that counted it.

The four panels

Review discipline — major-incident PIR completion for the window, plus the standing backlog of majors never reviewed and not yet closed. The backlog deliberately ignores the window: a major declared eight months ago and never reviewed is exactly what you need to see. Same pair for change post-implementation reviews, which today means emergency changes (they get 72 hours from submission).

Change control — the emergency-change rate, the CAB sign-off rate, schedules booked over a known CI collision, and changes run through a freeze.

The emergency rate is the one to watch. An emergency change auto-approves the moment it is submitted: it skips the CAB and every freeze, in exchange for a mandatory 72-hour review. A tenant running 40% emergency changes does not have change control.

The sign-off rate is exact, not estimated: normal and standard changes always open an approval request, and the emergency path never does, so a change that reached “approved” with no approved request behind it was approved by bypass.

Collision overrides only exist where your governance template sets the collision policy to warn — under block the transition is refused outright and there is nothing to count. Warn is a legitimate choice; a rising count is your signal that the maintenance calendar has stopped meaning anything.

Changes run through a freeze deserves a note on what it is and is not. Beacon does not record a “freeze override”, because it cannot: a normal change whose window overlaps a freeze is refused and never saved. Emergency classification is the only way through a freeze. So this count — emergency changes whose maintenance window overlaps a freeze that would otherwise have covered them — is the complete set of bypasses, not an estimate of it.

Authorization control — self-approvals refused, and approver delegation coverage.

A refusal means the segregation-of-duties control worked: someone tried to sign off their own work and was stopped. The target is still zero, because a rising count means approvals are being routed to people who cannot decide them. That is a routing problem for you to fix, not a discipline problem for them.

Delegation coverage does not claim to know who is on holiday — Beacon has no absence calendar. It reports who has no out-of-office delegate at all, which is the condition under which one person being away stalls every request routed to them. Its exceptions are people rather than tickets, so it lists them by name with how many requests went to each, and links straight to Approver experience where you book cover.

Handover and closure quality — escalation-note substance, escalation checklist completion, and resolution-code completeness.

Beacon already refuses a blank escalation note, so “did they write something” is not a question worth asking. The question that is worth asking is whether they wrote enough: notes reaching 120 characters — roughly the two sentences it takes to say what was tried and what the next person should do — count as substantive.

Checklist completion only counts escalations that actually had a checklist template attached. If you have not configured one, your agents are not scored for skipping it.

Resolution-code completeness covers exactly what the resolve dialog requires: incidents reaching resolved and service requests reaching fulfilled. Changes and problems are excluded on purpose — a change’s outcome is its post-implementation review. Tickets resolved before the requirement existed, or while it was switched off, still have no code, and this number shows that gap rather than hiding it. The exception list is what you can have re-coded from the ticket itself.

Who sees it

reporting.compliance — held by the Incident Manager and Beacon Administrator roles, and by the Change Manager (who chairs the CAB and owns six of these numbers). It is deliberately not part of the general reporting.view grant your service desk holds: this tab names individual approvers who were refused for self-approval and individual approvers with no cover, and that is a management lens rather than a service-desk one.

Organizations

Your customers. Every ticket, ingest org mapping, catalog restriction, and assignment group is scoped to one of these, so this is the first thing to fill in when onboarding a new customer.

• Create / edit — name (unique per tenant), an optional external reference (a stable id from another system, e.g. a Relay account key — org mappings can target it), and an active toggle. There is no delete: organizations with history are deactivated instead, which hides them from new-work pickers while keeping every ticket attributable.

• Default organization — exactly one active organization is the tenant default (badged in the list). Incoming work that carries no explicit organization — desk tickets, portal requests, unmapped ingest events routed through a key’s default — lands here. Promote another organization with Make default; the flag moves atomically. The current default can be neither deactivated nor unset directly, so the tenant can never end up defaultless.

• Queue weight (0–100) — how much extra pull this customer’s tickets get in the desk’s Focus ordering. 0, the default and the value every existing organization has, means no thumb on the scale.

Use it sparingly and understand what it can and cannot do. It is capped at 100 against an SLA signal worth up to 400 and a priority signal worth up to 200, so it can move a weighted customer’s ticket ahead of a comparable one — which is the point — but it can never float a quiet customer’s P4 above somebody else’s breached P1. A weight that could do that would be a way of quietly deprioritising work you have made a promise about.

It is not secret. Any agent looking at a weighted customer’s ticket sees “Priority org (+60)” on the queue row, with the number. Every change is audited with the before and after value.

• Everywhere else in the relevant workflow that needs an organization (ingest key default, org mappings, catalog restriction) uses a searchable picker that matches on name or external ref — raw numeric organization ids never surface.

All changes are audited (organization.created / organization.updated). Writes require admin.organizations.manage; the read-only list additionally serves the pickers for holders of integrations.keys.manage,

Service catalog

Two tabs: Offerings and Categories.

• Categories group offerings in the requester portal. Create, rename, and deactivate them inline.

• Offerings are the request types requesters submit. The offering editor is a wide slide-over with configuration on the left and a live preview of the requester’s form on the right — what you build is exactly what requesters see.

• Details: name, descriptions, category, fulfillment group.

• Ticket defaults: impact/urgency, the delivery estimate, and an optional single-organization restriction picked by name from the searchable organization select (else the offering is tenant-wide).

  Delivery (working days) is requester-visible. It is quoted on the catalog card and the request form (“Typically ready by Thu 16 Jul”), and it is fixed as an expected-delivery date on each request the moment that request is cleared for fulfillment — at submission for an offering needing no approval, at approval for one that does. It counts working days on the service desk’s calendar, skipping weekends and holidays, and the requester is told at fulfillment whether the date was met. Editing it later does not re-quote requests already raised: each request keeps the figure it was quoted. Leave it blank to publish no timescale at all — the portal then shows nothing rather than implying one. See

• Request form — the schema builder. Add fields of nine types (text, Each field has a label, a machine key (a valid identifier, unique per form), a comma-separated option list. Reorder with the up/down arrows. Validation mirrors the backend: a select without options, a duplicate key, or a bad-identifier key is rejected before save.

• Approval routing: toggle require approval, set the quorum, and optionally seed named approvers (subject/name/email). With no named approvers, any holder of service_requests.approve may decide. Flip on Sequential stages to chain multiple approval stages (e.g. Manager → Security), each with its own name, quorum, and optional named approvers — a stage’s approvers can only decide when their stage is active, and later stages are notified only when their stage begins. Up to 10 stages; reorder with the arrows.

• Published controls whether the offering appears in the requester portal.

Deleting an offering is a hard delete; existing requests keep their submitted answers as history.

SLA policies & holidays

• Policies bind a response and resolution target (in minutes) to a business- hours window (or 24×7). A policy can target a single priority (P1–P4), a single organization (per-client SLAs — pick it in the policy dialog; the list shows an org chip), or act as the tenant default fallback; exactly one policy is the default and it can never be org-bound. Resolution order: ## Policy resolution).

• Holidays are excluded from the business-hours clock. They can recur yearly (matched by month + day) and apply to all policies or one.

The seeded set is four priority-keyed policies (tight 24×7 for P1 down to a relaxed P4) plus a business-hours default, and two recurring public holidays.

Agent org access

Client-siloed agents for the MSP operating model. Restricted operators see and work only their listed organizations’ tickets, problems, changes, CIs, and reports; everyone else keeps tenant-wide access (restriction is opt-in — an empty panel means nothing is restricted).

• Restrict operator picks an operator Beacon has seen (assignment-group members and ticket assignees, with directory-mirror names/emails) — or a raw Portal subject for operators who haven’t touched anything yet — plus one organization. Add one row per organization the operator should keep.

• Each org chip has a revoke ×. Removing an operator’s last chip returns them to tenant-wide access; the panel warns before doing it.

• Grants and revocations are audited (org_scope.granted / org_scope.revoked).

• Gated by org_scope.manage (elevated; beacon_admin only out of the box).

Branding & white-label

White-label the requester portal and notification emails for your clients. Anything left blank keeps the stock Beacon look; operator consoles are always Beacon-branded regardless.

• Portal display name replaces “Beacon” in the portal header, the browser title ({name} Help Center), the email From-name, and a [{name}] subject prefix on notification emails.

• Primary color (hex, e.g. #1d4ed8; picker or text) tints buttons, links, and accents in the requester portal only.

• Support email renders as a “Need help?” footer in the portal and is appended to notification email bodies.

• Logo (PNG or SVG, ≤256 KB) replaces the Beacon mark in the portal header; upload shows an instant preview and can be removed independently.

• Reset to defaults (confirm-gated) removes everything, logo included.

A live preview card shows the portal header with your current (unsaved) values. Gated by admin.settings.manage (critical risk; beacon_admin only

Custom ticket fields

Define tenant-specific fields on incidents, changes, and problems (service requests keep their catalog item forms). the relevant workflow, gated by admin.settings.manage.

• Create a field with a key (immutable), label, type (immutable — the full catalog form vocabulary: text, paragraph, dropdown, multi-select, number, date, checkbox, email), options for select types (one per line), help text, an applies-to scope (one type or all three), and a “required at creation” flag.

• Required applies only to tickets raised from the desk or requester portal. Machine-created tickets (Relay ingest, Teams chat, journeys) are never blocked by a missing required field — ingest is correlation-critical.

• Edit label, options, help, applies-to, required; reorder with the arrow buttons. Key and type cannot change (the API refuses with an explanation) — deactivate and create a new field instead.

• Deactivate instead of delete: the toggle removes the field from the desk and filters, but values already stored on tickets are kept, keep rendering on ticket detail, and keep appearing in CSV exports.

• The Desk preview panel renders the active fields exactly as agents see them.

On the desk, active fields render in a “Custom fields” block on ticket detail (edit-in-place, tickets.update), appear in the new-ticket dialog, power the field filter next to the queue tabs, and export via the queue’s CSV button.

Terminology (labels)

Rename what your tenant sees without changing how the platform works. the relevant workflow, gated by admin.settings.manage.

• Grouped editor over the fixed vocabulary: ticket types (singular + plural), ticket statuses, change statuses, problem statuses, and requester-portal strings (“Help Center”, “My tickets”, “Report an issue”). Pending hold reasons are managed in their own section (below) — they are tenant vocabulary, not just labels.

• Each field shows the stock label and its token; deviations get a “custom” badge. Type the stock label back into a field to remove that override.

• Save labels applies everywhere immediately: desk badges and queues, transition chips, changes/problems workspaces, and the requester portal.

• Reset all to stock (confirm-gated) removes every override.

• Display layer only: the API, filters, saved views, automation, webhooks, and CSV machine columns keep the standard values (incident, in_progress, …). All changes are audited.

Hold reasons (pending)

Control what operators can pick when they put a ticket on hold. the relevant workflow, gated by admin.settings.manage.

• The list is your tenant’s vocabulary, in picker order. Add creates a new reason: type a label (“Awaiting parts”) and the machine key is suggested automatically (awaiting_parts). The key is stored on tickets and never changes; the label can be renamed any time (pencil icon).

• Reorder with the arrows — the desk “Put on hold” and bulk-transition pickers follow this order.

• Deactivate hides a reason from pickers and blocks new transitions to it; tickets already holding it keep their label. Reactivate any time. At least one reason must stay active.

• The seeded three (“System” badge) can be renamed and reordered but not deleted. awaiting requester also cannot be deactivated: the requester portal and chat show “Waiting for you” exactly when a ticket holds on it — that meaning survives any rename.

• Delete is only offered for custom reasons and only succeeds while no ticket references the key (otherwise deactivate instead).

• Putting a ticket on hold always pauses the resolution SLA, whatever the reason — the hold state is fixed; you control the vocabulary. All changes are audited (hold_reason.*).

Resolution codes

Control what operators can pick when they resolve a ticket. the relevant workflow, gated by admin.settings.manage.

• The list is your tenant’s vocabulary, in picker order. Add creates a new code: type a label (“Fixed by vendor”) and the machine key is suggested automatically (fixed_by_vendor); an optional hint shows under the resolve picker. The key is stored on tickets and never changes; label and hint can be edited any time (pencil icon).

• Reorder with the arrows — the desk resolve dialog and the bulk-transition picker follow this order.

• Deactivate hides a code from the resolve dialog and blocks new resolutions with it; already-resolved tickets keep rendering its label. Reactivate any time. At least one operator code must stay active.

• The seeded six (“System” badge) can be renamed and reordered but not deleted. The three “Machine” rows — Resolved by source (ingest), Automated resolution (journeys) and Resolved with major incident (the stand-down sweep) — can’t be edited at all and never appear in the resolve dialog; they exist so automated resolutions render a label and stay distinguishable from work an agent did.

• Delete is only offered for custom codes and only succeeds while no ticket references the key (otherwise deactivate instead).

• Require a resolution code (top of the page, on by default) decides whether an agent must pick one of these codes to resolve an incident or resolution reporting and the completeness view read, and a missing reason cannot be reconstructed later. Turning it off is for a genuine exception — an integration of yours that resolves tickets through the API without a code and now gets rejected, while you update it — and the page warns you that every ticket resolved while it is off is permanently missing from that reporting. The change itself is audited.

• All changes are audited (resolution_code.*).

Canned responses

the relevant workflow — reading needs tickets.canned_response.view, changing anything needs tickets.canned_response.manage. Requesters hold neither, so this library is never readable from the portal.

• New canned response takes a title (what agents search for and see in the list), a body (the text inserted into the reply), and an optional free-text category for grouping. Titles are unique per tenant so the composer’s list has no ambiguous entries — a duplicate title is rejected.

• Active controls whether the snippet is offered in the composer. Deactivating keeps it here for later without exposing it to agents; this list shows active and inactive rows, the composer only ever sees active ones.

• Bodies are plain text with no substitution or templating syntax. A snippet is inserted for the agent to review and edit before sending, never auto-posted — the agent is always the author of what the requester reads.

• Delete asks for confirmation. Replies already sent using a snippet are unaffected; they are ordinary notes.

• All changes are audited (canned_response.created/updated/deleted).

Priority matrix

Tune how priority is derived from impact × urgency. the relevant workflow, gated by admin.settings.manage.

• A 4×4 grid: rows are impact (1 = organization-wide … 4 = single user), columns are urgency (1 = work blocked … 4 = can wait). Each cell selects the resulting priority P1–P4. Cells that differ from the standard ITIL grid are highlighted, and the section shows a “Customized” badge.

• Save matrix validates the whole grid (all 16 cells, P1–P4) and applies it to new tickets (and future impact/urgency edits) only — existing tickets keep the priority they were triaged with; SLAs, escalations, and reports on old tickets never churn.

• Reset to ITIL default restores the standard grid.

• The 1–4 axes are fixed — you can’t add or remove scale points.
• All changes are audited (priority_matrix.*) with the full before/after grid.

Requester priority cap

Below the grid: the most severe priority a requester’s own submission can reach. Beacon has always capped urgency arriving from chat and email intake; this is the same control for the portal, which was the last channel where a requester’s own choices reached the priority column unmediated.

• Default P2 — High. Choose “No cap” to let requesters raise a P1 directly, or a lower ceiling (P3/P4) for a tighter desk.

• Only the person submitting is capped. Your agents are never capped — including when they log a ticket on someone else’s behalf from a phone call or a walk-up. That person is doing triage; the cap exists for the report form, not for them.

• The requester is told. Their ticket says “You told us this is Critical — an agent will confirm the final urgency”, the clamp lands on the ticket timeline, and the creation audit record carries what was asked for, what applied, and the cap in force. Beacon never quietly downgrades someone.

• Confirming the requester’s call releases the cap. An agent who agrees re-saves the same impact and urgency on the ticket; the priority is then re-derived without the cap and the timeline records the confirmation. There is nothing to hunt for and no value to wiggle.

• What this means for major incidents: the auto-declare sweep reads the capped priority. At the defaults (cap P2, auto-declare at P1) one requester’s report can never auto-declare a major incident by itself. If you set a major-incident policy’s auto-declare threshold at or above this cap, you have chosen to allow exactly that — Beacon will honour it.

• Changes are audited (tenant.requester_priority_cap.updated) with before/after.

## Requester priority cap.

Notification templates

Rewrite the wording of the notifications Beacon sends (bell + email; email keeps your branding wrapper). the relevant workflow, gated by notifications.preferences.manage.

• One editor per event (ticket reply, assignment, reopen, CSAT invitation, escalations, approvals, service-request decisions, major-incident roles/RCA/ comms-overdue). Events you haven’t customized show a “Default” badge and use the built-in wording.

• Each event has a fixed set of {placeholders} shown as chips (click to insert). Saving a template with a placeholder the event doesn’t support is rejected — the editor warns as you type.

• Preview renders your draft against realistic sample data without saving.

• Reset to default removes the override; the built-in wording returns immediately.

• Operator-authored messages — major-incident comms updates and journey notification steps — are written where they’re sent and are not templated here.

• All changes are audited (notification_template.*).

Escalation policies

An escalation policy fires staged notifications when a ticket breaches or nears its SLA. Create the policy (optionally scoped to a priority), then edit its stages: each stage has a delay (minutes after the trigger) and a target — an assignment group, an on-call rotation, or a named person. Stages are edited as an ordered list and saved atomically.

“Reaches nobody” warnings. A stage pointing at an assignment group with no members fires and reaches nobody, so Beacon says so rather than reporting success. The policy row shows a reaches nobody badge, the stage itself is highlighted with empty group, and the reason is spelled out under the stage strip. This is checked every time the page loads, not just when you saved the stage — a group can lose its last member long after the stage was configured.

This applies out of the box: a new tenant’s Default escalation policy sends stage 1 to the seeded Service Desk group, and that group starts with no members. Beacon will not guess someone into a paging path on your behalf, so adding at least one Service Desk member is a first-run task — and the console keeps telling you until you do.

Saving a stage that points at a group, schedule or alert channel that does not exist is rejected outright. A stage targeting a named person must be picked from the Portal directory (see Identity checks under Assignment groups) — a hand-typed subject cannot be verified.

Escalation checklists (/manage/escalation_checklists)

“Tried-steps” checklists — what an agent should have attempted before handing a ticket of a given category to the next tier. Shown to the agent in the desk’s Escalate dialog and recorded as answered on the handoff (H3.6). Reading needs escalation.view; creating, editing and deleting need escalation.manage.

• One template per category, plus one tenant default. A template targets a single ticket category, or is left unscoped (“Tenant default — all categories”) to apply everywhere no category-specific template exists. Beacon allows exactly one template per category and one default; the category picker greys out categories that already have a template rather than letting you create a second and hit a conflict on save.

• Steps are a name plus optional help text, added and reordered freely while drafting. Each step gets a stable machine key derived from its label the first time it is saved — the handoff’s recorded answers reference that key, so it is generated once and then left alone even if you later reword the step.

• At least one step with a label is required to save, and the template needs a name. Both are validated before the Save button is enabled.

• Active/inactive — deactivating keeps the template for later without offering it in the desk’s Escalate dialog.

• Delete asks for confirmation and removes the template outright — there is no soft-delete/reactivate path for a deleted template the way hold reasons and resolution codes have; recreate it if needed.

half of this feature.

On-call schedules

Each schedule is a rotation (daily, weekly with a handoff day/time, or custom hours) in a timezone. Open Participants to set the rotation order (members are Portal subjects, with optional name/email for notifications) and to add a temporary coverage override for a date range. Each schedule card shows who is on call now, resolved from the rotation math (or an active override).

Assignment groups

Groups are the queues tickets route to. Create/rename/deactivate groups and manage members (people picked from the Portal directory, with optional name/email). The member count is shown on each group and updates as you add or remove people. Each member has a role in the group — Member or Lead; nothing else is accepted.

A group that routes work but reaches nobody gets a routes to nobody badge and an explanation on its row. That means something sends work here automatically — an escalation stage targets it, or it has an auto-assignment policy — while there is no one it can actually reach: either the group has no members at all, or none of its members could be matched to a person in the Portal directory. It is not an error to have an empty group nobody routes to; it is a silent failure to have an unreachable group that something does.

Identity checks

When you add a member, find them in the Portal directory. The pick records their Portal user id — the durable identity Beacon routes, verifies, and matches “assigned to me” by — and the dialog confirms the match (“Directory match recorded”). The OIDC subject field is under Advanced and optional: the directory cannot verify a subject, so only supply one copied from something Beacon already knows. A member Beacon could not verify carries an unverified badge in the member list, and does not count toward go-live staffing or clear the routes-to-nobody badge.

By default Beacon refuses a person it cannot find in your directory, and tells you which field was wrong. An administrator can switch the tenant to warn (Directory → identity validation) if you need to configure people Beacon has not mirrored yet: the member is saved, you get the warning anyway, and the fact is written to the audit log. The same check applies to escalation targets, on-call rosters, approval delegates, journey people parameters, ticket and task assignees, and agent org-access grants.

If your directory has not synced yet — no mirrored users at all — the check is skipped entirely and nothing is blocked. There is nothing to check against, and Beacon says so on the Directory page rather than implying a check is running.

Each group also has an auto-assignment policy (edit dialog → Auto-assignment):

• No auto-assignment (default) — tickets wait for an agent to pick them up.

• Round robin — rotates through members in a stable order; removing a member simply advances the rotation.

• Least open tickets — picks the member with the fewest open tickets; ties resolve deterministically.

With a policy selected, Business hours only gates assignment to the tenant default SLA policy’s business calendar; off-hours tickets stay unassigned until an agent takes them or the 5-minute sweep runs once hours resume. Groups with a policy show a badge on their row (e.g. “Round robin · business hours”). Every auto-assignment writes a system timeline event and an audit entry with the

Note: unassigning a ticket that stays in an auto-assign group only holds until the next sweep — move the ticket out of the group (or set the policy to “No auto-assignment”) to keep it unassigned.

Improvements (/manage/improvements)

The continuous-improvement register — voice-of-customer feedback, process/SOP gaps, and SLA-driven follow-up actions, owner-routed and due-dated, closable only with a terminating outcome. It is the “you said / we did” record that also feeds the service-review report’s Improvements section. Reading needs improvements.view; routing, raising and closing need improvements.manage.

• Raise takes a title, an optional detail, a category, an optional customer organization (tenant-wide by default — an operator restricted to specific organizations must name one, or the raise is refused: a tenant-wide item they cannot see would be invisible to its own author), an accountable group (“route later” leaves it unrouted), and an optional due date.

• Route (or re-route) the accountable group inline from the list, for any item not yet closed or rejected.

• Close requires a terminating outcome — rejected needs only an optional reference; every other outcome additionally asks for a “We did…” summary, the plain-words half of the “you said / we did” record a customer reads in their service review. register only ever grows, so the list is server-paginated rather than capped.

Major-incident policy

Sets the auto-declare priority threshold (which incidents become candidates for automatic major declaration) and the comms cadence (how often the incident commander must post a stakeholder update). Closure of a major incident requires a PIR, which spawns a linked RCA problem.

The threshold is read against the priority the ticket actually holds, which for a portal report means after the requester priority cap (Priority matrix → Requester priority cap). At both defaults — cap P2, threshold P1 — a requester cannot auto-declare a major incident on their own. Setting the threshold at or above the cap is a deliberate choice to let them, and Beacon will not second-guess it.

Two more per-policy controls:

• Page alert channels on declare — declaring pages every active alert channel (PagerDuty/OpsGenie); stand-down or resolution clears the page.

• War-room Teams team — when set, the first declaration creates a dedicated Teams channel (MI <number> <title>) in that team and puts the join link on the incident. Needs the Beacon bot’s AAD app to hold admin-consented Channel.Create in your AAD tenant; failures are recorded on the incident timeline, never silently dropped.

Stakeholder lists

Below the policies: stakeholder distribution lists — plain email audiences (execs, account managers; no Beacon account needed) notified when a major is declared and again when it stands down, without becoming ticket watchers. Each list can be limited to one customer (lists are additive — a tenant-wide list and a customer list both fire) and to a priority floor (“P1 only”). Message texts are the incident.stakeholder_declared / incident.stakeholder_stood_down templates under Notification templates. The list pages 25 at a time (10/25/50/100, remembered per table) with a “Showing X-Y of Z” count rather than rendering every list on one screen. See

Approvals (/manage/approvals)

The approval inbox lists every pending approval in the tenant, whatever raised it — a service request, a change, or a journey step. Each row is badged with what it is attached to, so you can see you are clearing a service request before you click.

Deciding here is exactly the same as deciding on the ticket’s own surface. An approval you approve in this inbox moves the service request to approved and tells the requester (with their delivery date), or takes a change through the CAB gates, identically to the portal, the Teams card, or the approve-by-email link. There is no “wrong place” to approve something.

Tickets awaiting a decision that was already made

If a warning card appears at the top of this section, it is listing tickets left awaiting approval after their approval was already decided — a fault that existed in earlier builds of the generic inbox. Those tickets cannot be approved, rejected or cancelled from anywhere, and their requesters are still being shown a promise that cannot resolve.

Apply the recorded decision finishes what the approver actually chose: the ticket moves exactly as it should have at the time, the requester is notified, and the repair is written to the audit log. It never re-asks the approver and never invents an answer — a recorded rejection stays a rejection.

A change whose scheduled window has since fallen inside a freeze is refused rather than approved into it. Reschedule the change, then apply the decision again.

The card is invisible when nothing is stranded, which is the normal state.

Approver experience (/manage/delegation)

Three things that decide whether an approval actually gets decided, rather than sitting in somebody’s inbox while the requester watches “awaiting approval” with no clock on it.

Out-of-office cover

Set who decides your approvals while you are away, and for how long.

• It is self-service. Anyone who can decide approvals can set their own cover — you already hold the authority you are lending. Setting cover for somebody else needs approvals.delegation.manage, and administrators with that permission can tick Show everyone’s to audit the whole tenant.

• The approval stays yours. Your delegate’s decision is recorded against your name, with theirs noted as the person who actually made it. Quorum is unaffected — cover does not add an approver, it lends yours.

• You still get told. Cover is not a mute button: you are notified alongside your delegate, so a window you forgot to close does not silence you.

• Cover does not chain. If your delegate is also away, their cover does not inherit yours. Approvals would otherwise drift to somebody neither of you chose.

• Either of you can end it early — you taking your approvals back, or your delegate declining a mandate they cannot carry. Decisions already made stand.

• Windows are bounded (start, end, 180 days maximum). For a permanent hand-over, change the approval policy on the catalog item instead.

Segregation of duties still applies to your delegate. They can never approve something you could not have approved yourself. If you raised the ticket, you are not an eligible approver of it — and neither is anyone standing in for you. They are told exactly that, and the refusal is audited.

Reminders

Beacon re-asks approvers who have not acted.

• Remind after (hours) — the quiet period between nudges to one approver. Default 24. Set it to 0 to switch reminders off for the tenant.

• Maximum reminders per approver — default 3. Bounded deliberately: an endless nudge gets treated as spam by mail providers, and then the real approval emails stop arriving too.

Reminders stop as soon as the approval is decided or resolved, and they reach an approver’s out-of-office delegate as well. Wording is editable under Notification templates (event Approval reminder).

Approve from the email

Off by default. When you turn it on, approval emails carry Approve and Reject links that work from any browser with no sign-in — so an approver can clear a request from a phone in one tap.

What to know before enabling it:

• Each link works once. After it is used it is dead, and pressing it again says so explicitly, including what it already recorded. Using one link kills the other, so nobody can approve from one email and reject from the next.

• Nothing is recorded until the button is pressed. Opening the link shows a confirmation page first. This is deliberate — corporate mail scanners and link-preview tools fetch every link in an inbound email, and a link that acted on being fetched would let the security appliance approve everything before the human saw it.

• Links expire after the window you set (default 72 hours).

• No rules are relaxed. Segregation of duties, stage eligibility and quorum apply exactly as they do in the app, and every decision made this way is written to the audit log as approval.decided_by_email_link.

• It is a real way to approve without a Beacon session, which is why it is opt-in rather than on by default.

Chat (Microsoft Teams)

Let your staff report issues, raise catalog requests, decide approvals, and check status from a Microsoft Teams chat with the Beacon bot. Reports become incidents and requests become service requests through the normal machinery — the chat layer never executes anything — and one Teams thread maps to one ticket. Catalog request forms render as cards in-thread (validated server-side by the same rules as the portal; forms over 12 fields hand off to a prefilled portal form), and approvers who have chatted with the bot get actionable approval cards — deciding on a card goes through exactly the same approval service, quorum rules, and audit trail as the portal, and only works for people actually named on the request. Slack runs on the same channel abstraction and is connected separately, below.

Connecting a tenant (RBAC integrations.chat.manage):

1. Click Generate verification code. The code is shown once — copy it now.
2. Install the Beacon app in your Microsoft 365 tenant (personal scope).
3. From an administrator’s account, send verify <code> in the Beacon bot chat. Beacon binds your Microsoft tenant and the card flips to Connected.

One Microsoft tenant connects to exactly one Beacon tenant; a code presented from a Microsoft tenant that’s already connected elsewhere is refused. Regenerate code re-keys the channel (a fresh verify is then required); Disable stops intake without releasing the binding; Re-enable restores a previously connected channel.

Once connected the card shows the bound Microsoft tenant id, the conversation count, the number of trusted service URLs (hosts Beacon will proactively message), today’s classification count against the daily budget, and the chat priority cap. Identity is resolved against the Portal directory mirror: a requester whose Teams email doesn’t match an active directory user is asked for a work email in-thread and their ticket is flagged identity unverified for the desk. The bot’s app credentials are platform configuration, not entered here.

Chat priority cap — the urgency the classifier suggests for a chat ticket (mapped exactly like the requester portal’s urgency question) can never silently set a priority above this cap (default P2; P1 must always be a human decision unless you deliberately lift the cap). Changing it is audited.

Intent mappings (same RBAC): the deterministic table that routes a classified utterance. Each closed-set intent (printer, VPN, disk, Outlook, browser, password reset, plus the built-in report/request/status behaviors) has an enable toggle, a minimum-confidence threshold (default 0.70), and — for non-built-in intents — a picker over your active external-intent journeys. The classifier only suggests; a journey runs only through an enabled mapping after the user confirms in-thread (one tap, always). Intents with no linked journey fall back to a plain ticket, with the classified intent still recorded for the desk. Mappings are seeded automatically when the tenant is provisioned and auto-link when you enable the matching gallery template (password-reset, the Windows top-5 remediation templates); your manual edits are never overwritten.

Chat (Slack)

The same assistant, in Slack. Everything above about what chat can and cannot do applies unchanged — reports become incidents, requests become service requests, approval and catalog cards work in-thread, and the chat layer still executes nothing. Intent mappings, thresholds, the classification trail and the priority cap are tenant-wide settings shared with Teams; you do not configure them twice.

Connecting a workspace (RBAC integrations.chat.manage):

1. Click Add to Slack. Beacon sends you to Slack to approve the app.
2. Choose the workspace and approve the permissions Beacon asks for.
3. Slack sends you back here and the card flips to Connected.

Direct messages with Beacon work immediately. To have Beacon answer in a shared channel, invite it to that channel — a direct message is one long-running conversation (like a Teams personal chat), while a message in a channel starts a thread, and Beacon replies in that thread.

One Slack workspace connects to exactly one Beacon tenant. If the install comes back saying the workspace is already connected elsewhere, disconnect it from that Beacon tenant first — Beacon will not silently move it. If it says the install link expired, click Add to Slack again for a fresh one; each link is single-use and short-lived. Reinstall in Slack re-runs the approval (use it after changing the app’s permissions); Disable stops intake immediately without releasing the binding; Re-enable restores it.

Once connected the card shows the bound Slack workspace id, the conversation count and the chat priority cap. Identity works as it does for Teams, with one honest difference: Slack tells Beacon who sent a message but not their email address, so Beacon looks the address up through Slack’s API. That requires the users:read.email permission granted during the install. Without it — or if the lookup fails — Beacon does not guess: the person is asked for a work email in-thread and their ticket is flagged identity unverified for the desk, exactly as an unmatched Teams user would be.

The Beacon Slack app’s own credentials (client id, client secret, signing secret) are platform configuration and are not entered here. The bot token your install produces is stored encrypted and is never shown, in this console or through the API.

Classification trail — the second tab lists recent classifications: utterance, intent, confidence, sentiment/urgency, the mapping decision budget_fallback), and the resulting ticket/journey run. Use it to tune thresholds and judge classifier accuracy honestly.

Degraded states are explicit banners, never end-user errors: budget exhausted (the per-tenant daily classify budget is spent — chat runs menu-only until tomorrow) and classifier off (no platform key and no BYO AI provider — chat is fully functional via the menu; classification is an accelerant, never a dependency).

Chat intake metrics — once connected, a metrics strip shows live tenant-wide aggregates: chat ticket volume (and how many resolved), time to first resolution (from connecting the channel to the first resolved chat ticket — your onboarding proof), chat-triggered journey runs and the honest resolved-by-journey rate over finished runs, the classification accuracy proxy (confirmed vs rejected confirmation cards), and chat notification deliveries (sent / failed). All numbers are computed server-side, across all chat channels (Teams, Slack and the portal assistant), with a per-channel split available in the API response.

Deflection by category — the honest answer to “what is the assistant actually resolving”, one row per intent, with a Teams / Slack / Web / All channels filter. This table is deliberately hard on itself:

• Deflected means the journey run finished with a resolved outcome. A ticket raised for your service desk is intake, not deflection — it is counted in its own column and never in the deflection number. A run still in flight, a run that merely completed its steps, and a run that escalated to a human are all not deflections.

• A rejected confirmation card counts against that category’s rate. If the assistant guessed wrong in front of the requester, that is a miss, not a neutral non-event.

• A rate of “—” is not a zero. It means there is nothing to measure, and the reason is printed beside it: no journey mapped (the category is switched on but nothing runnable is linked — a real capability gap, shown rather than buried), built-in intake behaviour (report / request / status never link a journey by design), or no attempts yet. A category that genuinely tried and deflected nothing shows a real 0%, and the two never look alike.

• Turns the assistant declined to classify are counted, not hidden. When the daily budget or per-user pacing is spent, those turns stay in the denominator. Turns arriving while classification is switched off write no record at all, so they cannot be counted — the table says so rather than implying a zero.

The methodology is printed under the table, from the same source as the numbers. Expect real-world deflection well below the 65-80% the category advertises; the point of this table is that you can see which categories earn it and which do not. It is visible to anyone with integrations.chat.manage, whether or not the Teams or Slack channel is connected — the portal assistant is a front door in its own right.

AI provider (/manage/ai)

Two independent things live here. Read the first one even if you never intend to supply an AI key — it is on by default.

Beacon-managed classification (on by default)

Beacon classifies incoming chat messages using its own model, included in your subscription. You do not need an API key and there is nothing to set up. It is switched on for your tenant.

What it can and cannot do:

• It can work out that “my printer is jammed again” means printer problem, offer to start the matching journey, and pre-fill a ticket from what the person actually said.

• It can never change a ticket on its own. Classification only ever suggests. Even a 99%-confident result produces a card the person taps before anything happens. Auto-apply is not a setting we left off for you — it is impossible on Beacon’s own model, by construction.

• It only classifies. The richer AI actions (draft a reply, summarize, suggest priority, detect duplicates) require your own key, below.

Minimum confidence (default 0.70) is the bar a classification must clear before Beacon acts on it. Below the bar the conversation quietly falls back to the menu — the person still gets served, they just get the menu instead of a shortcut. Every attempt, including the ones that fell short, is recorded with the confidence it scored, so you can judge accuracy from evidence in the chat classification audit rather than from vibes.

Raise it if Beacon is guessing too eagerly. Lower it if it is being too timid and people are seeing the menu when a shortcut would have been right. If you tune individual intents in Chat, the number here acts as a floor beneath those per-intent thresholds — so a permissive setting on one intent still cannot let Beacon’s model act on a weak guess.

Turning it off. One toggle. Chat keeps working exactly as it did before classification existed: the menu flow is the full product, not a degraded mode. Turning this off does not touch your own provider key — that always takes precedence over Beacon’s model anyway.

If your deployment has no Beacon-managed model configured, the panel says so plainly rather than showing you a switch that does nothing.

Your own AI key (BYO)

Supplying your own provider key unlocks the six journey ai_step actions and the duplicate-detection gallery template. The key is encrypted and never shown again. Set a monthly token budget to cap spend; a call that would exceed it is skipped rather than charged. Nothing degrades without a key — AI steps simply skip.

Allow auto-apply applies only to your own key, and even then it is doubly gated: you must switch it on and the individual journey step must ask for it.

Removing the provider asks you to type a phrase first

Remove is not a one-click action. It opens a dialog naming what stops — AI-assisted classification for the tenant, so chat conversations and tickets no longer get suggested categories or summaries, and the six journey ai_step actions skip — and you must type REMOVE PROVIDER exactly before the confirm button becomes usable. Cancel, Escape and clicking outside all leave the provider in place.

The phrase is there because the API key is write-only: Beacon has no copy to give back, so an accidental Remove means re-issuing a key with your provider.

Removing your own key does not switch off Beacon-managed classification — that is the independent toggle above, and it keeps working.

Confidence is a visible policy, not a hidden constant. An ai_step with auto-apply on exposes a Minimum confidence threshold in the journey studio (0–1, default 0.75): the model’s stated confidence must clear it or the result stays advisory. A model response that states no confidence never auto-applies — unknown certainty is treated as unknown, not as certainty — and the refusal is recorded with its reason on the AI invocation log. When an AI step does change a ticket (category, impact, urgency, priority), the ticket timeline shows exactly which fields moved, old → new, with the confidence and threshold, and a full ai.auto_applied audit record (provider, model, before/after) lands in the compliance log. Nothing the AI does to a ticket is invisible.

Automation providers

Connect the device and service providers that journeys act through — the other half of automation: intake decides what should happen, providers are how it happens on real endpoints and platforms.

• Connect once per vendor. A vendor connection exposes every capability family it supports (device executor, service executor, inventory source). Pick the vendor, name the connection, paste credentials (write-only — encrypted at rest, never displayed again). Connecting runs an immediate health check.

• Health cards show the connection state (healthy / error / unchecked / disabled), the capability families, the provider-verified capability list, latency class (honest — “minutes” means agent jobs that survive reboots), and the last error when unhealthy. Test re-checks on demand and refreshes the verified capabilities.

• Capabilities unlock journey templates. Gallery cards with requires_capability (the Windows top-5 device remediations, access-request fulfillment) stay locked until a connection provides the capability — no fake execution, ever. What an enabled journey may actually dispatch stays bounded by its template’s allowlist; connecting a provider never widens it.

• Disable vs delete. Disable stops new dispatches immediately (in-flight jobs still finish or time out). Delete is only possible for connections with no dispatch history — the job audit trail always survives.

• Job history per connection lists every dispatched device job and service action: kind, allowlisted key, target device, status (dispatched/running/succeeded/failed/timeout/rejected/requires-human), and the ticket/journey-run links.

• Job stats on each card: total jobs dispatched, the success rate, and the median dispatch→finish latency — computed over finished jobs only, so in-flight work never flatters or skews the numbers.

• Dev-mode fakes: on development builds, contract-faithful fake providers are connectable to exercise the full loop without a Relay connection; they never appear in production.

Permission: integrations.automation.manage (elevated). Every connect, update, enable/disable, delete, dispatch, and completion is audited.

Email intake (email-to-ticket)

Connect the mailbox your users already email (support@…) and Beacon turns it into tickets — new mail becomes an incident, replies thread onto the existing ticket, and outbound replies keep the conversation in the requester’s mail

A reply to a finished ticket reopens it. Email honours the same reopen rule as the portal and machine ingest: a reply to a resolved ticket reopens it at any time, a reply to a closed ticket reopens it inside your tenant’s reopen window (Settings → reopen window, default 30 minutes), and the assignee — or the assigned group when nobody owns it — is notified that it came back. A reply that arrives after the window is never dropped: it becomes a new ticket linked to the old one, and the acknowledgement sent back to the requester names the earlier ticket so the changed number is explained rather than mysterious.

• Connect a mailbox (IMAP). Display name, mailbox address, IMAP host/port/SSL/folder, username + password (write-only — encrypted at rest, never displayed again), poll interval, optional default organization, optional sender-domain allowlist. Beacon polls read-only (your mail is never marked read) and never sends from this mailbox — outbound replies use the

• Health card per mailbox: healthy / error / unchecked / disabled, the last transport error, last poll + last message seen, and honest counters (tickets created, replies appended, suppressed, throttled, errors). Test verifies reachability + login on demand.

• Loop safety is built in. Auto-replies, bounces, and Beacon’s own mail are suppressed and never answered; senders are throttled to a handful of new tickets per hour (overflow lands as one digest note on their newest ticket) — a mail loop cannot flood the queue.

• Activity ledger per mailbox shows every processed message with its outcome (ticket created / reply appended / suppressed / rejected / throttled / error) — including per-message errors, so nothing fails silently.

• Nothing arrives without a record. A message Beacon fails to process is written to the ledger as an error before the mailbox cursor is allowed to move past it. If even that record cannot be written, the cursor stays put and the message is simply read again on the next poll. Mail is never both un-ticketed and un-logged.

• Retry a failed message. Error rows carry a Retry button. Beacon re-reads the original message from your mailbox (it is still there — polling never marks, moves, or deletes anything) and runs it through intake again, updating the same ledger row with whatever happens this time. If the message has since been deleted from the mailbox, or the mailbox is unreachable right now, you are told exactly that instead of getting a silent no-op.

• Unknown senders still get help: their ticket is created with the captured address and a visible unverified-identity flag for the desk.

• Disable vs delete. Disable stops polling immediately; delete is only possible for mailboxes with no intake history — the message ledger always survives.

Permission: integrations.email.manage (elevated). Connects, updates, enable/disable, deletes, and message retries are audited; ticket creation records an email.ticket.created audit entry and a retry records email.message.reprocessed.

App access (Portal-managed)

Beacon access is granted and revoked in Portal, never here — this tab is a read-only window plus troubleshooting tools:

• Install card — install status, listing id, activation time, and a Manage assignments in Portal deep link. A non-active install means no Marketplace roles resolve for anyone, and the card says so.

• Assignments table — every user/group role assignment with role key, System-vs-Custom type, and whether it was granted directly or via a group.

• Effective access lookup — search the mirrored directory for a user and see their resolved access: direct roles plus roles inherited through (nested) group membership, each labeled with its source. System roles expand to their permission list; Portal-defined custom roles are flagged as managed in Portal. An explicit No Marketplace access state appears when the install is live but the user holds no role — assign a role in Portal to fix it.

• Assignment change history — the audit trail of assignment webhooks.

Degraded states are explicit: “credential not provisioned yet” before first activation, “rotate the credential in Portal” when Portal rejects Beacon’s service credential, and “Portal unavailable” for transient upstream failures.

Notification deliveries (/manage/notification_deliveries)

The delivery log and retry surface for the tenant’s own outbound notifications (P1.1). Gated notifications.preferences.manage.

Every notification carries two independent delivery lanes on one row — email and chat — and each lane tracks its own status last error. A lane that exhausts its retry budget lands at failed and stops there — nothing retries it automatically, which is why this page exists: before it, an approval email that silently died had no surface at all.

• Leads with the number that matters. A summary strip (per selected channel) shows the failed-lane depth and how long the oldest failure has been waiting, ahead of the table — so “are we currently failing to reach people” is answered before you scroll.

• Filter by channel (email / chat), status, and event type; the table is server-paginated, since this ledger grows with every notification the tenant ever sends.

• Retry sits on the row itself for any failed lane — requeues that one double-fire a delivery that already recovered).

• claimed_by names the last process to hold the delivery’s work claim, so a row that died mid-flight under a rolling restart is traceable to a worker rather than looking like an unexplained stall.

Migration imports (/manage/migration)

Bring historic tickets in from ServiceNow or Freshservice (H3.10). Gated by admin.migration.manage.

• Upload an export file, naming its source system and which entity kind it contains (, e.g. incidents/requests/problems). Nothing touches live Beacon data yet.

• Dry-run reconciliation report. The upload stages a report of what would happen — created vs. updated vs. skipped vs. errored rows — before anything commits. Review it, then either Commit or Discard.

• Commit runs in the scheduler, not inline: the console tracks the background job to a terminal state and reports the real outcome then (created/updated/skipped/errored counts), rather than claiming success the moment the request returns.

• Idempotent by construction. Re-running an overlapping export skips records already imported, tracked through a persistent identity map — you can safely re-upload a wider export that includes rows you already committed.

• Import history is server-paginated (not silently truncated at a default page size) and shows each import’s status kind, and row counts. Selecting a past import shows its individual records and any invalid-record / commit-error detail.

Audit log (/manage/audit_log)

Requires admin.audit.view. Read access is admin-tier only: audit rows name who did what and carry the before/after state of control-sensitive changes across every practice, so being able to read them is itself a privilege.

This is the compliance record — the evidence you produce for an access review, an incident post-mortem, or an auditor. It is not the same thing as a ticket’s Activity timeline, which is the operator narrative for one ticket and does not satisfy an audit requirement.

Browsing

The table shows, newest first: when, who (with a badge when the actor was a service or the system rather than a person), the action, the resource it touched, and whether it succeeded. Details opens the full before/after state for that row.

Filters, all combinable:

Filter	Behaviour
Actor	Substring of the actor’s name, email or Portal subject
Action	Prefix match — type change. to get the whole change lifecycle, api_key. for key mint/rotate/revoke
From / To	Inclusive of both days, in UTC. The Last 7d / 30d / 90d buttons fill both.
Outcome	Succeeded or failed
Tier	Live (default), Archived, or both — see Retention below

The table is paginated, not capped: the audit log is the largest table in the system, and a page footer that said “showing the newest 100” while silently hiding the rest would be exactly the kind of dishonest surface Beacon avoids. The footer tells you the true total.

Export CSV downloads the rows matching the filters currently on screen — the same query, so the file always matches what you were looking at. It is capped at 10,000 rows; narrow the date range if you need more. Exports are themselves recorded in the audit log (audit.exported, with the filters and row count), because bulk extraction of the compliance record is worth a record of its own.

If you are an agent restricted to specific organizations, you see only audit rows belonging to your organizations. Tenant-wide configuration changes are not shown, by design.

Retention

At the bottom of the section. Requires admin.settings.manage to change; holders of admin.audit.view alone can read it but the fields are disabled. Reading the trail and deciding how long it survives are separate privileges.

Two windows, both blank by default, meaning nothing is ever deleted:

• Keep in the browsable view for (days) — after this, rows move to the archive tier. They are still retained and still exportable; you just have to select the Tier filter to see them. Nothing is destroyed.

• Permanently destroy after (days) — after this, archived rows are deleted and cannot be recovered. Because this is the one control in Beacon that destroys compliance evidence, enabling it requires typing a confirmation phrase.

Both windows are counted from when the row was written. The second must be greater than or equal to the first, and requires the first to be set — purging acts on the archive tier, so a row that never gets archived would never be purged.

Minimum: 90 days. Beacon refuses shorter windows rather than quietly rounding them up. A trail shorter than the review cycles that read it cannot answer the questions an audit log exists to answer, and 90 days is the shortest window defensible to an external reviewer. If you set anything under 365 days the section shows an advisory — PCI DSS and most ISO 27001 control statements expect at least a year of audit history — but it will let you save it, because Beacon does not know which regime binds you and a data-minimisation obligation can legitimately pull the other way.

A daily background job applies the policy. It runs in the analysis workload class and is bounded, so a large backlog drains over several days rather than in one spike; nothing you can observe changes if it runs a few hours late.

Right-to-erasure requests: Beacon does not support deleting one person’s rows from the audit trail, and this is deliberate — see position and its reasoning. Uniform time-based retention above is the supported control.

Desk: working a service request

In the Service Desk workbench, opening a service_request ticket shows a dedicated work surface (not the incident action bar):

• Approval state — the quorum progress (n/m approved) and each approver’s decision; multi-stage requests add a Stage n of m badge and show the current stage’s approvers. Approvers can approve or reject inline (only the current stage’s named approvers on a staged request).

• Actions follow the SR state machine: Start fulfillment

• Submitted details — a read-only render of the requester’s answers against the catalog item’s form schema, including any answers whose field was later removed from the form.

CI Registry (/cmdb)

The CI registry is not a Manage section — it lives at the relevant workflow (shell switcher → “Go to → CI Registry”, also carded on the L2/L3 shells) — but its controls are admin-relevant:

• cmdb.view (standard) reads the registry; cmdb.manage (elevated) creates, edits, retires, and reactivates manual CIs and assigns CIs to organizations. Both are assigned through Portal role management like every other permission. Retire asks for confirmation and is not a dead end: a retired manual CI’s detail card carries a Reactivate button that flips it straight back to active — nothing about its history (ticket links, relationships, source identities) was ever touched by retiring it.

• Provider CIs (synced from Relay via asset.sync ingest keys configured in Ingest keys) are read-only except org assignment. They go stale — never deleted — when the source stops reporting them for longer than the tenant window (default 30 days); a stale CI is badged and drops out of pickers, but keeps its full ticket history.

• Org mappings on ingest keys drive which organization a synced CI lands in; unmapped assets become tenant-wide CIs visible to all agents.

• Relationships + service map (C2) — cmdb.manage holders draw typed edges (runs on / depends on / component of) on any CI’s detail card; cycles, self-edges, and duplicates are rejected with the reason. The Service map tab (the relevant workflow, deep-linkable with ?service=<id>) renders each business service’s dependency chain as an expandable indented list with open work per node. Incident/problem/change detail shows the resulting impact panel (affected services + open work) whenever the ticket has linked CIs, and major incidents can be declared against a business-service CI.

On a phone or tablet

The section rail down the left is pinned on a laptop. Below that width it becomes a drawer: tap the ☰ button at the top left to slide it out over the page, tap a section to go there (the drawer closes itself), and tap outside it, press Esc, or use the back gesture to dismiss it without going anywhere. Every section is in the drawer — nothing is hidden on a small screen.

The console is administration, so most of it is genuinely desktop work: wide configuration tables, multi-column forms, and rule builders are far easier with a keyboard and a large screen. Two areas are built to be read on a phone, because they are the ones people check away from a desk:

• Reports and the XLA scorecard. KPI tiles reflow to two columns, and the agent scorecard and skill-gap tables become one card per agent rather than a table you scroll sideways. Raise training action stays on the card.

• Approver experience. The out-of-office cover list becomes cards, with End now on each — so an approver who realises mid-holiday that their cover is wrong can fix it from their phone.

keep their table layout and scroll horizontally. They are operator surfaces nobody triages from a phone, and a card per log line would be worse to read, not better.

Runtime health

Requires admin.runtime.view. This is Beacon reporting on Beacon: whether the deployment is doing its work, not whether the process is up.

Readiness. One verdict at the top. Ready means every workload class has a live lease somewhere in the deployment and no sweep has stopped succeeding. It is deliberately not a measure of how much work is queued — a backlog means the deployment needs more capacity, and marking it unready would remove capacity.

Platform-health paging. Choose the alert channel Beacon pages about itself: sweeps that keep failing, a workload class nobody is running, and integrations Beacon has auto-disabled after repeated delivery failures. Changing it needs integrations.alerting.manage and is written to the audit log, because it decides who finds out when Beacon stops working. Leave it unset to receive no platform pages.

Two limits stated on the page rather than left to assumption. It covers partial failure only — if the scheduler process stops entirely it cannot page, which is what the external readiness probe is for. And if the designated channel is itself disabled, Beacon cannot page you to say so; the page shows a red banner instead, which is the only place that fact can appear.

Workload classes. Per lane: who leads it, its worst sweep lag, and how much work it has abandoned to mid-tick lease demotion. That last pair matters because an abandoned lane and a failing lane look identical from lag alone and need decision table. A demotion or two around a rolling restart is failover working, not an outage.

Secret rotation. Every key-rotation sweep, dry runs included, with the run that authorises removing a retired key called out separately from ordinary runs. A run still marked running means a partially rotated deployment. Full