Take work and keep it visible
An officer claims an item to work on it and releases it if they cannot continue. Colleagues see who holds it. Draft notes stay private to the officer until a decision is recorded.
Registry Casework
One inbox for the work that needs a person to decide.
Corrections, disputes, requests another system cannot settle on its own: some work has to be given to a person, tracked against a due date, and answered. Registry Casework gives your teams one place to receive that work, take it, decide it, and show who did what and when. The system that owns the work keeps its own rules about what may change.
One example: a licence scope correction in a registry
Correct a licence with one officer accountable from request to decision.
A professional register receives a request to correct the scope of a licence. The registry team wants corrections reviewed by an officer before they take effect, a first response within 48 hours, and a clear record of who decided.
An illustrative correction request
One officer takes the request. The register records the change in their name.
Professional register
Correction request
Correction request REQ-3106
- Licence
- LIC-4471
- Requested change
- Scope of practice
- Submitted by
- Licence holder
- Received
- Tuesday 09:14
The register keeps the licence record and decides who may change it.
Registry Casework
Queue: Licence corrections
- ReceivedRouted to Licence corrections. First response due within 48 hours.
- ClaimedHeld by R. Adeyemi. Draft notes stay private to the holder.
- Correction requestedCertificate missing. The clock pauses while the item awaits the applicant.
- ApprovedDecision recorded inside the 48-hour target. The paused time did not count.
Supervisors see who holds each item and for how long.
Professional register
Change applied
Applied by the officer
Licence record LIC-4471
- Scope of practice
- Corrected
- Changed by
- R. Adeyemi
- Applied
- Wednesday 10:02
- Revision
- 12
The officer applies the approved change under their own account, with the access they already have.
History Who received, held, asked, approved, and applied the item, and when. Supervisors read it without opening the database.
Casework never changes the register on its own. The officer who approves the correction applies it under their own account, so the register records the change against the person who made it, with the permissions that person already has. The same holds for any other system that owns the work.
One inbox for the work that needs a person
Know who holds each item, what is due, and who decided.
Work arrives from a registry, a case system, or any service that hands in a request. Casework routes it to the agreed queue, and everyone with access sees the same picture: what is waiting, who is working on it, and when the first response is due.
Ask the applicant before deciding
When information is missing, the officer records a correction request and the item waits for the applicant. The response clock pauses while the item is awaiting the applicant, so measured response times reflect the time your team controlled.
Decide, then apply in the officer’s name
Approval and application are separate steps. The officer applies the approved change in the source system under their own account, and that system records who made it. If its answer is uncertain, the attempt is kept and recovered; no outcome is invented.
How it fits your organization
Run the team without opening the source system.
Casework holds the queue, the holder, and the clocks. The system that owns the work keeps eligibility, permissions, and the records themselves. Supervisors and administrators run the team from Casework rather than from database access.
Work reaches Casework in two ways. A source system connects through an adapter, which decides how its work appears in the inbox and what a decision may do there; Base Registry Engine ships with one, and another system needs an adapter written against the published contract. Any service can also hand in a request through the API and follow its progress; it cannot claim or decide the item.
If the review a registry needs is a fixed number of approvals and nothing more, Base Registry Engine can require them on its own and hold the proposal until they are in. Casework is for review work that has to be given to a person, tracked against a due date, chased when it stalls, and answered back to whoever asked.
- Your team agrees the queues and targets
- Decide which requests need a person to look first, which queue receives each kind of work, the response target for each queue, and the working-day calendar that reminders and escalation steps follow.
- Supervisors keep the caseload moving
- See what each officer holds and for how long, reassign an item, move a caseload when someone is away, and review the reminders and escalations that are due. Casework works out when they fall due; a person decides what happens next, and no message is sent automatically.
- Administrators manage teams, not cases
- Set up teams, the queues each team serves, and the holiday calendar. Administrator access covers the team directory only and does not open the content of any item.
For developers and implementers
Connect a source system or a requesting service and run the first queue.
Start with the overview: what runs where, how work reaches the inbox from a source system or a requesting service, and which guide an author, an operator, or an application developer opens next.
The configuration guide then walks through a starter project: declare queues, routing, and clock policies, test them against synthetic fixtures, and package the reviewed policy for deployment.
- Two sources of work
- Casework presents work from a connected source system, which Base Registry Engine provides through its adapter, and hosted decisions that another service creates through the API. The source remains the authority on who may see an item and who may change it, and Casework never acts with more access than the person it is acting for.
- Interface, adapters, and clients
- One HTTP API covers both kinds of work, with maintained Rust, Node.js, and Python clients. A source adapter implements a published contract for finding work, showing its current state, and carrying out the actions a decision allows. Casework supplies the API and clients; the staff screens come from your own application or an existing staff tool.
- Continue in the documentation
- Run and operate Casework for the database, identity, and audit requirements, and read the API reference for the exact operations, headers, and recovery responses.
Work with us
Get help when you need it.
Get hands-on help through a paid implementation pilot, or ongoing support while your team builds and runs the solution.
Implementation and support