Part 7 · Platform, hosting and artificial intelligence

Irregularity register

A list of what is quietly wrong (records that are late, off process, orphaned or silent), kept by rules you set, and served to each person for what they are responsible for.

Symbifox 18.0 (September 2026 catalogue) · Modules: bf_irregularity, bf_irregularity_project, bf_irregularity_digest · Base applications: Discuss, Project, Task Logs · Revised 2026-11-02

The Irregularity register picks up what goes wrong without making any noise: an activity whose deadline passed long ago, a file waiting on a client for months, an email that never left, an archived project that took its open work with it. Each kind of problem is a rule you tune, and each finding goes to the person responsible for the record. In practice: a short list per person, which keeps itself and empties as the causes go away.

Overview#

Two objects are enough to understand the module.

A detector is a named rule: a kind of problem, a severity, a threshold with its own label, a fallback owner, and a checkbox that decides whether a reminder should be placed on the record itself. A detector is data, not code: you switch it off, change its threshold or reassign its findings without any development.

An irregularity is a finding: what is wrong, the record it points at, who is responsible for it, when it was first and last seen, and its state (open, acknowledged, muted, resolved). A finding is unique per detector and per record, so a pass that runs again updates instead of stacking copies.

A pass runs every hour over the active detectors. A finding whose cause is gone closes itself, with the date. Nothing is emailed and no reminder is placed until you tick Schedule an activity on a detector.

Configuration#

Access and rights#

Level	What it opens
Internal user	Sees their own findings, acknowledges them, mutes them or reopens them. Reads detectors without changing them.
Administrator	Sees every finding, creates and tunes detectors, runs a pass by hand.

The separation is held by a record rule on the responsible person, not only by what the screen shows: running a pass requires write access on the detector, even through a direct call.

The rules that ship#

The base module installs four, all live:

Rule	Family	Default	What it finds
Activity overdue for too long	Late	7 days	A planned activity whose date passed longer ago than the threshold, with no follow-up.
Activity assigned to an archived user	Orphaned	none	The person has gone, their activity stayed under their name.
Scheduled message not sent	Late	1 hour	Its time has passed and it is still in the queue.
Outgoing email failed	Hazardous	none	The send failed.

The projects bridge adds four more:

Rule	Family	Default	What it finds
Task waiting for too long	Silent	21 days, critical at twice that	A task in Waiting - Client or Waiting - External. A task whose deadline or planned activity falls within thirty days is left alone.
Open task in an archived project	Orphaned	none	Still open, and no longer visible anywhere.
Open task with nobody assigned	Orphaned	off	Shipped off: many teams leave tasks unassigned on purpose.
Working day without a timesheet	Silent	5 working days	Read from the person's own working hours, with approved time off left out.

⚠️ The projects bridge installs itself as soon as the register, the waiting states and timesheets are all present, and the timesheet rule works from the first pass. On a database with history, expect one finding per person and per day with no time logged, over a five working day window. The register stays silent (no email, no reminder), but the list will not be short: switch that rule off or widen its threshold before the first pass if that is not what you want.

Tuning a rule#

Irregularities › Detectors, then open the rule.

Field	Role
Active	Switches the rule off without deleting it. Its findings stay.
Severity	Info, warning or critical. Sets the colour and the order.
Threshold	The number the rule reads: days, hours or a window, depending on the threshold label.
Fallback owner	Receives the findings nobody else is responsible for.
Schedule an activity	Places a reminder on the record itself, for the responsible person. Unticked on all eight shipped rules.

First steps#

Open Irregularities › Irregularities. The list opens on your own open findings, most serious first.
Open one. It names the record, what is wrong, its age and the rule that raised it.
Click Open record to go and fix the cause.
Come back and click Acknowledge, or leave it: on the next pass, if the cause is gone, the finding closes itself.

Common tasks#

Mute a finding#

A finding that is not for today can be muted for a month: it leaves the list and comes back afterwards. Useful for a file on hold whose reason you already know.

Change a threshold#

Twenty-one days of waiting is not right for everyone. Open the rule, change the threshold, save: the next pass applies the new value, and findings that no longer hold close themselves.

Run a pass right away#

On a detector, the Run button replays that rule immediately. Reserved to administrators, because a pass writes for everybody.

Add your own rule#

A small bridge module declares the rule as data, then adds the method that finds it. The register, the hourly pass, the automatic closing and the digest section come with it. The projects bridge is the example: four rules, no screen.

The menus, one by one#

Irregularities › Irregularities: the list of findings, filtered on yours and on the open state.

Irregularities › Detectors: the rules, with each one's open count, last run and last error. Administrators only.

Reference#

Fields of a finding#

Field	Description
Irregularity	The sentence that says what is wrong.
Detector	The rule that raised it.
Severity	Info, warning, critical.
Record	The record it points at, clickable.
Owner	The person responsible for it.
First seen / Last seen	The two ends of the finding.
Age (days)	Since it was first seen.
State	Open, acknowledged, muted, resolved.
Resolved on	The date of the pass that closed it.

Automations#

An hourly pass runs the active rules. A rule that fails keeps its error on its own record and does not stop the others. Findings whose cause is gone close on the next pass. With the daily digest, your open findings appear in the morning email.

Understanding#

Why a finding closes, and why sometimes it does not#

A rule returns the list of what it found. Any finding of that rule no longer in the list closes. But a rule that only scans a window, the last five working days say, also returns the list of days it checked: a finding about a day that has left the window stays open rather than closing without evidence. That is deliberate: not having checked is not the same as having resolved.

What the register may name#

To name the record it points at, the register reads it with elevated rights. A finding can therefore name a record its reader could not open. The reader only sees findings they are responsible for, and opening the record goes through the ordinary access rules: it is the name that crosses, not the content.

Troubleshooting#

The list is empty although I know there are problems. You only see findings you are responsible for. Ask an administrator: they see all of them.

A rule has never run. Open its record: the last run and the last error are there. A rule with no method installed says so in its error.

Far too many findings on day one. That is the working-day-without-a-timesheet rule, shipped live. Switch it off or shorten its window, then run a pass.