Skip to content

Morning Check Groups and Routing

Ed Mozley edited this page Aug 12, 2026 · 1 revision

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.


The one thing to understand first

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.


Groups are optional

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

Setting it up

1. Create the groups

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.

2. Point each group at somebody, if you want to

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.

3. Put checks in the groups

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.


What the round looks like afterwards

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?

The Mine filter

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.


Raising a ticket or a task from a check

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.


Undoing a check

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.


Changing a status when there is a note

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.


Permissions

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.


Related pages

FreeITSM

Getting Started

Modules

Multi-tenancy (planned)

Blue sky thinking

Bugs resolved

Links

Clone this wiki locally