Sheet BEA-04 · ITSM Manual
Tenant Setup & Onboarding
First-run setup for a new tenant: what Beacon creates for you, what it leaves empty, and the steps to a working desk.
Scope
What a new Beacon tenant contains, what the administrator must add before the desk can run, and the eight setup steps.
Audience: the administrator who has just been given a new Beacon tenant.
Where: the relevant workflow — “First-run setup”, the first section in the
Administration console’s Service Management group. Visiting bare the relevant workflow
takes you there automatically until setup is finished.
Permission: admin.setup.view to read it, admin.setup.manage to record
progress. Both are included in the Beacon Administrator role.
What Beacon has already done for you
Beacon is not a blank product. The moment your tenant was created it seeded a working service desk:
| Area | What was created |
|---|---|
| Organization | One default organization, named after your tenant |
| Categories | A 7-branch category tree (Hardware, Software, Network, Access & Identity, Email & Collaboration, Service Request, Other) with 25 subcategories |
| Assignment groups | Service Desk, Change Advisory Board, Engineering |
| SLA | Four priority-keyed policies (P1–P4) plus a business-hours fallback, and two recurring public holidays |
| Priority | The conventional 4×4 impact × urgency matrix |
| Service catalog | A “Common Requests” category with five offerings (Password Reset, New Laptop, Software Access Request, New User Onboarding, VPN Access) |
| Escalation | A two-stage default policy, a weekly “Primary on-call” rotation shell, and five starter escalation checklists |
| Change | Five governance templates, an example (inactive) year-end freeze |
| Major incident | A default policy that auto-declares at P1 with a 30-minute comms cadence |
| Automation | Three default-on hygiene journeys, the chat intent map, hold reasons, resolution codes, three system saved views |
Your job is to review this, not to retype it. Every setup step shows what is already configured and lets you accept it in one click, or jump straight into the real admin section to change it.
What Beacon deliberately leaves empty
Just as important, and the wizard now says all of it out loud rather than rendering a reassuring green tick:
| Area | What is empty, and what that means |
|---|---|
| People | The seeded Service Desk, Change Advisory Board and Engineering groups have no members, and the seeded Primary on-call rotation has no participants |
| Ticket templates | None. Recurring work (onboarding, offboarding) is typed from scratch |
| CMDB | No configuration items and no business services, so a ticket cannot say which service it affects, change collision detection has nothing to collide on, and a major incident cannot name what is down |
| Major-incident stakeholders | No stakeholder list, so the declare announcement, the comms updates and the stand-down all go to an empty audience |
| Knowledge | No articles |
The one thing Beacon will not do for you
Beacon never invents a person. That is why the groups and the on-call rotation above ship empty: the first person to log in to a new tenant might be a requester, and guessing a human into a paging path is worse than an empty one.
That is why a brand-new tenant is configured but not yet operable, and why the wizard says so on the very first screen rather than letting you discover it when an escalation quietly reaches nobody.
The eight steps
Work through them in order; you can open any of them at any time, and you can leave halfway and come back — Beacon remembers exactly where you got to.
-
Organization and identity — confirm the default organization is named the way your users would recognise it, and decide whether you are running one organization or several (branding and terminology live here too).
-
Teams, agents and escalation — the step that actually needs you. Put at least one person in a group; add participants to the on-call rotation if you page out of hours; review the escalation policy and the starter escalation checklists.
-
Service level promises — the response and resolution clocks Beacon shows requesters, and the business calendar they run against. Review the numbers before they become a promise you are measured on, and add the public holidays your desk does not work.
-
Service catalog and desk content — keep the seeded offerings that match services you actually provide, retire the rest, and check each one has a fulfilment group and, where it needs approval, a named approver. This step also reports the two things Beacon seeds none of: canned responses and ticket templates.
-
Business services and the CMDB — what your desk is protecting. Beacon seeds nothing here, and an empty CMDB quietly degrades three things: a ticket saying which service it affects, change collision detection, and a major incident naming what is down. Add your top business services first; the estate underneath them can be imported later. This step never blocks go-live — it tells you what you are missing and leaves the decision to you.
-
Practices: change, major incident, knowledge — the practices beyond the desk, and the step most likely to surprise you. Two things ship seeded and switched on: the high-risk change template routes approval to the Engineering group (which has no members yet), and the major-incident policy auto-declares every P1 and promises stakeholders a 30-minute comms cadence (with no stakeholder list to send it to). Both are readiness rules.
-
Front doors — how work reaches you. The requester portal is always on. Microsoft Teams and inbound email are optional and off until you connect them.
-
Integrations — API keys, outbound webhooks, paging channels (PagerDuty/OpsGenie) and automation providers. None of these stop the desk from running; review them and move on if you have nothing to connect yet.
Accepting versus customizing
Each step offers two ways to finish it, and they mean different things:
- Accept these defaults — “what Beacon seeded is right for us.”
- I have customized this — “I went into the section and changed it.”
Both are recorded in the audit log with your name and the time, because “who reviewed the SLA promises?” is a question an auditor is entitled to ask, and accepting a default changes nothing in the settings tables that would otherwise answer it.
Clicking Customize in (or Open
Review again reopens a step you already resolved.
“Is this workspace operable?”
The panel at the top of the wizard answers that, and it is computed from your live configuration every time you open the page — not from how many steps you have ticked. Seven rules:
| Rule | Why it matters |
|---|---|
| A default organization exists | Intake files a ticket from an unrecognised requester against it. Without one, portal and email intake have nowhere to put the ticket |
| At least one assignment group has a member Beacon can verify | Assignment, auto-assignment and group routing all pick from group membership. An empty group is a queue nobody is in — and a member the Portal directory cannot match is counted as nobody, not as staffing (add members by picking them from the directory) |
| Escalation reaches a real target | A stage pointing at an empty group escalates successfully and notifies nobody |
| A fallback SLA policy is marked default | A ticket whose priority matches no policy would otherwise carry no clock at all — and the promise Beacon shows the requester is silence |
| At least one catalog offering is published | Without one, the portal can only take issue reports and half the service-request practice is unreachable |
| Every change-approval stage bound to a group reaches a real approver | An approval stage pointing at a group with nobody in it is not a review body: the change either waits for an approval that cannot arrive, or the decision falls to whoever happens to hold the approval permission. On a fresh tenant this means putting somebody in Engineering, which the seeded high-risk change template routes to |
| Major-incident stakeholder communications reach somebody | While a major-incident policy is active, Beacon declares majors and expects a comms cadence — but the declare, the updates and the stand-down all go to your stakeholder lists. With none, every one of them is written to an empty audience and nothing warns you. One list with one address (an exec distribution list is enough) satisfies it |
Two of those rules are new, and a fresh tenant now needs three people-shaped actions, not one, before it reads operable: somebody in a desk group, somebody in the Engineering group the seeded change template approves through, and one major-incident stakeholder address. Both new rules are conditional — a tenant whose change templates route approval to no particular group, or whose major-incident policy is switched off, meets them with nothing to do. And an empty CMDB is deliberately not a rule: it is reported, never gated.
Three consequences worth knowing:
-
You cannot click your way to “operable”. Accepting all eight steps while nobody is in a group leaves the verdict unchanged, and the wizard keeps saying why.
-
Operability can be lost again. Remove the last member from your only staffed group and the next visit reports the workspace as not operable. This is intentional: the verdict describes your configuration today, not the day you signed it off.
-
Your Portal directory has to be synced first. “A member Beacon can verify” means exactly that: the membership must point at somebody who is present and active in your mirrored Portal directory. If the directory has never synced, Beacon has confirmed nobody, so no group counts as staffed — even if it has rows in it. The groups step says so and names the fix (“run Sync now in Manage → Directory”). This closed a real hole: until 2026-09-01 an unsynced tenant passed this rule on any membership row at all, including one typed by hand that named no real person, so Beacon could certify a workspace operable when routing would have reached nobody.
If Sync now is not available in Manage → Directory, Portal has not finished activating Beacon for your tenant — see Directory in act.
Stopping the prompts
Stop prompting me silences the landing redirect — bare the relevant workflow will go to your usual first section instead of the wizard. It does not mark anything as done, and every unmet readiness rule keeps reporting unmet whenever you open the wizard. The dismissal is recorded with your name; Prompt me again reverses it.
Once every step is resolved and every readiness rule is met, the wizard stops prompting on its own and records the date the workspace became operable.
Escalation checklists
New in this release: your tenant ships with five starter escalation checklists — a tenant-wide default plus one each for Hardware, Software, Network and Access & Identity. They are what an agent is asked to confirm they have already tried when they escalate a ticket, and the answers travel with the handoff to L2/L3.
Edit them at the relevant workflow. If you delete them, Beacon will not put them back on your next login — a checklist you deliberately removed stays removed.
Related
readiness rules and the API