Obligations & Deadlines

Tracking Statutory Deadlines

An obligation is anything with a deadline: a statutory response window, a contractual milestone, an undertaking, a court direction, a review date, a licence renewal.

Where to find it

Architect Panel → Automation:

• Obligations — the live obligations and their state
• Obligation Types — the kinds you track, and their defaults
• Schedule Templates — how a due date is derived rather than typed
• Schedule Milestones — the checkpoints within a template
• Escalation Steps — what happens, to whom, and when

Architect Panel → Data:

• Business Hours Calendars — the working-hours calendar deadlines are counted against

One module, because it is one measurement

An SLA target, a statutory deadline, an undertaking, a court direction, a project milestone and "how long did this sit in triage" are all the same thing: elapsed working time between two events on one record, measured over one calendar.

Split into separate features, each would carry its own copy of the working-hours arithmetic and the copies would drift — which is how an organisation ends up with two reports that disagree about whether the same case was late. One definition of overdue, one walk of the calendar, one report.

Why not just a date field

A date column tells you when something is due. It does not know about weekends or bank holidays, it does not escalate, it does not distinguish a deadline met from one missed, and reporting on it means somebody writing a query and remembering to run it. An obligation carries the deadline plus what should happen around it.

Working hours are not optional

Statutory windows are almost always working days. A twenty-working-day deadline calculated as twenty calendar days is wrong by about a week, and wrong in the direction that breaches.

Configure a business hours calendar before you rely on derived dates. Two behaviours are worth knowing:

• Calendar 0 means plain elapsed time — a 24/7 wall clock. That is the right choice for something genuinely continuous, and it is what an installation that has not configured business hours gets.
• A calendar that exists but has no working hours is treated as a configuration error, not as zero-length days. The obligation opens with no due date and the problem is logged, rather than opening with a deadline that has already passed. Wrong-but-obvious beats wrong-but-invisible.

Schedule templates

Rather than typing a due date, derive it. A template says "a complaint response is due twenty working days from receipt", and every obligation created from it gets the right date because the rule is recorded once rather than remembered each time. When legislation changes the window, you change the template.

Schedule Milestones add checkpoints within a template — acknowledge within three days, first response within ten, final response within twenty — each tracked in its own right.

Holds move the due date

When a clock is paused — you are waiting on the complainant, the court, a third party — the pause moves the due date rather than being subtracted later at comparison time.

That is a deliberate design decision with a practical benefit: everyone downstream sees one number that is already correct. A list sorted by due date, a reminder, an escalation and a person looking at a screen all agree, instead of each having to remember to subtract the paused time. The original due date is kept separately, so attainment reporting can still say "we agreed five days and took nine, of which three were on hold".

Escalation

Escalation is the point of the whole feature. A deadline that notifies somebody on the day it breaches has reported a failure. One that escalates at 75% elapsed has given you time to prevent it.

Configure escalation steps where somebody can still act — and escalate to a person who can do something about it. Escalating to the caseworker who is already overloaded achieves nothing; escalating to their team leader might.

The sweep

The Obligations Sweep task re-derives dates, fires escalations and marks breaches. It ships disabled and should run every few minutes — an escalation that arrives hours late is not an escalation.

Worked example — a council FOI team

An FOI request creates an obligation from the "FOI standard" template: twenty working days from receipt, over the council's calendar including bank holidays. Milestones at day 3 (acknowledged) and day 15 (draft response). If a clarification is requested the clock is held, and the due date moves. At 80% elapsed the case escalates to the information governance lead. The quarterly return showing responses within statutory timescales is generated from these records rather than assembled from a spreadsheet.

Recommendations

• Set the calendar up first. Everything else depends on it, including the bank holidays.
• Derive, never type. A typed due date is a date somebody can get wrong.
• Escalate early and to someone with authority. Late escalation is reporting, not prevention.
• Use holds honestly. A hold applied to protect a performance figure rather than because you were genuinely waiting is visible in the data, and it will be found.

Stage History, Breaches and Attainment

Stage history records how long a case spent at each point in its lifecycle. It is what turns a set of deadlines into an understanding of where time actually goes.

Where to find it

Architect Panel → Automation:

• Obligations — each obligation, its stage history and its outcome

Architect Panel → Dashboards:

• Explore — attainment and breach reporting over that history

Why stage history matters

When a statutory deadline is missed, the useful question is not who was holding it at the end. It is where the time went.

A case that breached at twenty days having sat unallocated for twelve has an allocation problem, not a caseworker problem. Without stage history that investigation is a reconstruction from memory and email timestamps, and it usually concludes with the wrong person being spoken to.

Breaches are recorded, not inferred

A breach is written as a fact, so it can be counted, explained and reported. Record the reason where one exists — an obligation breached because the complainant did not respond is a categorically different thing from one breached because nobody picked it up, and a performance figure that conflates them is not useful to anyone.

Attainment against the original

Because the original due date is kept alongside the current one, attainment reporting can distinguish three things that are usually collapsed into one number:

• What was originally agreed or required.
• What the deadline became after legitimate holds.
• What actually happened.

"We agreed five days and took nine, of which three were on hold" is a far more useful sentence than "58% within target", and it is the sentence that survives a challenge.

Reporting

Obligations and their history are queryable like any other datastore, so a performance return is generated rather than assembled. That is usually the immediate reason a service adopts obligations at all — and it is worth building the report early, because it tells you whether the configuration reflects reality.

Use it to change the process, not to grade people

The pattern to look for is a single stage consuming most of the window. That is where an intervention belongs.

Adding a reminder two days before the deadline does not help if the case spent three weeks waiting for a decision that took ten minutes to make. Stage history tells you which of those you have, and they need completely different fixes.

Worked example — a housing repairs service

Repairs have a fourteen-day target. Attainment sits at 71% and nobody can say why. Stage history shows a median of nine days between "reported" and "surveyed", and two days for everything after. The intervention is survey capacity, not repair capacity — which is the opposite of what the team had assumed and had been recruiting for.

Recommendations

• Report medians as well as averages. A handful of very old cases will drag an average somewhere misleading.
• Break attainment down by stage before drawing conclusions. The headline number rarely tells you what to change.
• Record breach reasons consistently. A free-text reason nobody categorises cannot be counted.
• Publish the figures internally. Teams improve what they can see; a performance report that only leadership reads changes nothing.