Obligations & Deadlines

Tracking Statutory Deadlines

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

Where to find it

These features have no dedicated Architect Panel section of their own. They are configured through their datastores, opened from All Datastores, and most of what a caseworker sees appears on the record itself rather than on an admin screen.

Why not just a date field

A date column tells you when something is due. It does not know what to do as the date approaches, it does not escalate, and it does not distinguish a deadline met from one missed. Reporting on it means someone writing a query and remembering to run it.

An obligation carries the deadline plus what should happen around it, which is what turns a date into something the system acts on.

Schedule templates

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

Working days and calendars

Statutory windows are usually working days, so the calculation must know about weekends and bank holidays. Configure business hours calendars before relying on derived dates — a twenty-working-day deadline calculated as twenty calendar days is wrong by about a week and wrong in the direction that breaches.

Escalation

Escalation is the point. A deadline that notifies somebody on the day it breaches has told you about a failure. One that escalates at 75% elapsed has given you time to prevent it. Set escalation points where somebody can still act.

The sweep

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

Stage History and Breaches

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

These features have no dedicated Architect Panel section of their own. They are configured through their datastores, opened from All Datastores, and most of what a caseworker sees appears on the record itself rather than on an admin screen.

Why stage history matters

When a statutory deadline is missed, the useful question is not who had it at the end but 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, the investigation is a reconstruction from memory.

Breaches

A breach is recorded rather than inferred, so it can be reported on, explained and counted. Record the reason where one exists — an obligation breached because the complainant did not respond is a different thing from one breached because nobody picked it up, and a count that conflates them is not useful to anybody.

Reporting

Obligations and their stage history are queryable like any other datastore, so a performance return showing responses within statutory timescales is generated rather than assembled. That is usually the immediate reason a service adopts obligations at all.

Use it to change the process

The pattern to look for is a single stage consuming most of the window. That is where the 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.