-
Notifications
You must be signed in to change notification settings - Fork 15
Morning Check Groups and Routing
How to split a long morning round into sections, say who normally does which part, and raise or undo work from a check. Written for the person running the round; the technical version is Morning check groups and routing β Developer Guide.
Asked for in discussion #64. Shipped in 262d7af8.
Routing is guidance. It is never permission.
You can point a group of checks at a team, or at one named analyst. That tells everyone who normally picks that part up. It does not stop anybody else doing it.
That is deliberate, and it is the whole reason the feature is shaped this way. The situation that matters is the one where somebody calls in sick and their checks still need doing at 8am. If routing were permission, the round would stop. Instead, anyone with access to Morning Checks can complete any check, any day β and the round records whoever actually did it, not whoever it was pointed at.
If you never create a group, nothing changes. The round looks and behaves exactly as it did before: one flat list, in the order you set. The Mine filter does not even appear.
Groups become worth having when either of these is true:
- the round is long enough that reading it as sections is easier than reading it as a list
- the round is shared across more than one person or team, and it helps to write down who normally does what
Morning Checks β Settings β Groups β Add.
A group needs a name. It can also have a description, a display order, and an active switch.
Typical groupings are by system area (Infrastructure, Business systems, Security) or by who does them (Service desk, Network team). Either works β the group is just a heading with an optional owner.
On the same screen, a group can be routed to:
- a team β shown on the round as the team name
- an analyst β one named person
- nobody in particular β the default, and perfectly reasonable
If you set both a team and an analyst, the analyst wins. The screen says so.
Settings β Checks, then edit any check. Two new fields:
- Group β which section it belongs to
- Route to analyst β optional, and overrides whatever the group says
That override is for the case where one item in an otherwise shared group really does belong to one person β the certificate renewal that only one person has access to, for example.
A check left without a group still appears on the round. Ungrouped checks are listed last, under Other checks, on the grounds that named sections followed by the remainder reads better than an unlabelled block at the top.
Grouped checks appear together under their group name, with the routing shown beside it. Each row shows, on one line:
| Column | What it holds |
|---|---|
| Check name | Plus, if the check has its own analyst, who that is |
| Description | What to look at |
| Status | One button per configured status |
| Notes | Whatever was recorded |
| Checked by | Who set the status that is currently showing |
| Time | When they set it |
| Actions | Raise, and undo |
Checked by answers the question that used to require asking somebody: has anyone actually done this?
Once anything at all is routed, All checks and Mine appear next to the date. Mine narrows the board to the checks pointed at you β directly, or through a team you are in. Switch back to All checks at any time.
The filter is hidden entirely until something is routed, so an installation that never uses groups never sees it.
Every check row has a +. It opens a small form with the check name, status, date and notes already filled in, and asks one question first: ticket or task?
- Ticket β for work that belongs in the queue, with a requester, priority, department and type
- Task β for a follow-up that does not warrant a ticket
The check keeps a record of what it raised.
Raising is available on any check, not just failing ones. It used to appear only on statuses that required notes, which is a reasonable proxy for something is wrong but a poor one for I want to follow this up β a green check can still deserve a task to go and look at something properly.
Clicking the wrong colour used to be permanent. Now, any completed check has an undo arrow that puts it back to not checked β the same blank state it had before anyone touched it.
Two things worth knowing:
It asks first, because it discards the note. "Not checked" is genuinely blank: the status, the note and the attribution all go. That is the right trade for I clicked green by accident, but it does mean undo is not a way to keep the note and change your mind about the colour. To do that, just click the status you actually meant.
Anything you already raised stays open. If you raised a ticket from the check and then undid the check, the ticket is untouched. Correcting a mis-click should not quietly close a real piece of work that somebody may already have started.
If a check has a note against it and you click a status that does not carry one, the note would be deleted. FreeITSM now asks before doing that, naming the status you are moving to.
This is worth knowing because it depends on your own configuration, not on the colours. Whether a status requires a note is a setting on the status itself, in Settings β Statuses β so on some installations moving to amber will prompt and on others it will not.
| Capability | Grants |
|---|---|
| Access to the Morning Checks module | Completing any check, raising, undoing |
morning_checks.groups |
The Groups settings tab β creating groups and routing them |
morning_checks.checks |
The Checks tab, including a check's group and analyst |
Note the first row. Granting or withholding the Groups capability changes who can set up routing, not who can do the checks. There is deliberately no capability that restricts completing a check to the person it is routed to.
- Morning Checks β the module overview
- Morning check groups and routing β Developer Guide
- REST API β Morning Checks
FreeITSM β an open-source IT Service Management platform Β· github.com/edmozley/freeitsm Β· MIT licence
- Installation
- β° Scheduled tasks (cron jobs)
- Architecture
- AI Providers
- Internationalisation (i18n)
- Timezones & Time Handling
- Theming & Dark Mode
- β¨οΈ Command palette (βK)
- π Searching inside tickets
- π Attached documents
- MobileβFriendly
-
Security
- Layer 1 β which modules you can enter
- β³ π§© Module Access Control
- β³ π οΈ Module Access β Developer Guide
- Layer 2 β what you can administer
- β³ π Roles & Permissions
- β³ π οΈ Roles β Developer Guide
- β³ π€ Why capabilities are constants
- Layer 3 β the System module
- β³ π Admin Access Control
- Hardening
- β³ π Security review response 2026-08
- β³ π‘οΈ Security hardening 2026-08
- β³ π οΈ Security hardening 2026-08 β Developer Guide
- β³ π‘οΈ Round three β plain English
- β³ π οΈ Round three β Developer Guide
- Single Sign-On (SSO)
- ποΈ LDAP & Active Directory
- Browser Extension
- API Reference
-
π REST API β how it works
- β³ π« REST API: Tickets
- β³ π» REST API: Assets
- β³ π΄ REST API: Problems
- β³ π REST API: Changes
- β³ π REST API: Knowledge
- β³ β REST API: Tasks
- β³ ποΈ REST API: CMDB
- β³ π REST API: Contracts
- β³ ποΈ REST API: Calendar
- β³ πΏ REST API: Software
- β³ π¦ REST API: Service Status
- β³ βοΈ REST API: Morning Checks
- β³ π REST API: Forms
- β³ βοΈ REST API: Workflow
- β³ πΊοΈ REST API: Network Mapper
- β³ π§ Using the API docs page
- β³ π OpenAPI specification
- β³ β OpenAPI: kept correct
- β³ π οΈ Maintaining the catalogue
- Watchtower
-
Tickets
- β³ Mailbox Authentication
- β³ π€ Email send log
- β³ Basic IMAP mailboxes
- β³ Email rendering & images
- β³ SLA Management
- β³ WhatsApp channel
- β³ π¬ Web chat channel
- β³ π£ Slack channel
- β³ π Linking tickets
- β³ ποΈ Canned responses
- β³ βοΈ Limiting replies to particular senders
- β³ βοΈ Email signatures
- β³ π The public web address
- β³ π Raising a ticket for someone else
- β³ π Merging tickets
- β³ β Splitting tickets
- β³ β Selecting several tickets
- β³ π οΈ Snoozing tickets β Developer Guide
- β³ π₯ Collision detection
- β³ β±οΈ Time tracking
- Problem Management
- Tasks
- Assets
- Knowledge
- Change Management
- Calendar
- Morning Checks
- Reporting
- Software
- Forms
- Contracts
- Service Status
- π Notifications
- π¨ War Room
- Self-Service Portal
- LMS
- Process Mapper
- CMDB
- Network Mapper
- Workflows
- Issue trackers (Jira, Azure DevOps)
- System
-
Overview
- β³ π Progress tracker
- β³ Concepts & vocabulary
- β³ Email routing & mailboxes
- β³ Settings: global vs per-company
- β³ Users & self-service
- β³ Staff cross-company access
- β³ Worked examples
- β³ Pitfalls & gotchas
- β³ Scope: what it's for
- β³ π οΈ Developer Guide (make a module multi-company)
- β³ ποΈ Case study: CMDB (a linked graph)
- β³ π§ͺ Test harness (prove it's isolated)