Ask a regulatory operations lead a simple question — "which markets are we approved in?" — and watch what happens. In a surprising number of organisations running a mature, well-configured RIM system, the honest answer involves a spreadsheet someone maintains on the side.

This is not a story about bad software. The system is usually configured correctly. The people are competent and conscientious. The implementation went live on time. And yet the data in the system does not describe the real world.

We see the same pattern across programme after programme, and it has a specific shape, a specific cause, and a fix that costs far less than anyone expects.

The symptom: records that stopped halfway

Regulatory work has a natural rhythm. You plan a submission. You file it. The agency reviews. You get a decision. And then — this is the step that fails — somebody has to go back into the system and record what happened.

That last step has no deadline. Nobody is blocked by it. No regulator is waiting on it. It is invisible until it isn't.

On read-only assessments of production RIM vaults, the same shape recurs:

• A majority of registrations still sitting in a "Planned" state — despite many of the underlying submissions having been filed, reviewed and approved
• A standing queue of registrations that are ready to be promoted — the submission has reached "Health Authority Received" or been archived, but the registration itself was never updated
• Registrations sitting in Planned with no linked submission at all
• Market activities recorded as unassessed, several of them provably complete in the real world — including markets that had already submitted and received decisions

Measure again days later and the backlog has usually grown. It is not a historical artefact being worked down. It is an active, compounding gap.

Here is the part that matters: none of this is a configuration defect. Every one of those records could have been updated correctly by an existing user with existing permissions in under two minutes.

Three failure classes, and why everyone misdiagnoses them

When someone reports that "the system is wrong," the problem is always one of three things. They look identical from a distance and they have completely different remedies and costs.

1. A data problem

A record holds the wrong value, or is missing. Fix: data entry. Cheap, fast, and the one everyone assumes they have.

2. A process problem

The record is fine, but nobody performed the step. The classic version: every assessment field is filled in perfectly, and the record's lifecycle state was never changed. Fix: ownership, notification, and a procedure. Not configuration.

3. A configuration problem

No user can do the right thing, because the system forbids it — field-level security in a given state, a missing constraint record, a field that was never added to the page layout, a lifecycle action that doesn't exist. Fix: an administrative change, usually with quality sign-off.

The expensive mistake is treating a process problem as a configuration problem. Organisations commission system changes — with the analysis, testing and validation that entails — to solve a problem that a report and a named owner would have solved in a fortnight.

The reverse mistake is just as common: teams retrain users over and over on a task the system will not actually let them perform.

A diagnostic that costs nothing: ask the person reporting the problem to show you. If they can do the right thing and simply didn't, it's process. If they cannot, it's configuration. And if you are logged in as an administrator, you will not reproduce their problem at all — admin accounts bypass the field-level security that is generating it.

The three sentences that resolve most escalations

The single most common support escalation in a connected RIM and Quality environment is a change control that will not progress. The quality system reports that regulatory change items are not all in an assessed state, and nobody can see why.

Almost always, the resolution is one of these three facts:

Completed fields are not an assessment

The assessment is the lifecycle state. A record with a perfectly written summary, a disposition, a classification and a decision date is still, as far as every downstream system is concerned, unassessed — until its state changes. Users reasonably believe that filling in the form is the work. In these systems, the state transition is the work.

One market blocks everything

A change control spanning fifteen markets is gated on all fifteen. Fourteen diligent teams are held up by one. Nobody looking at their own market sees the problem, because from where they sit everything is done.

The gate reads system state, not real-world status

A market can have submitted, been approved, and be shipping product — while its record still says "Planned." The quality system cannot see reality. It sees the record. The correct habit is to assess when the impact decision is made, not when you file, and not when you are approved.

We have watched a change control consume two days and seven people, resolved eventually by a two-minute state change that the right person made once someone told them to look at the status indicator rather than the form.

Why this is worth real money

It is tempting to file all this under housekeeping. It isn't, for three reasons.

Impact assessments silently under-report

This is the one that should concern you most. Impact assessment reports — "which markets are affected if we change this manufacturing site?" — run against registered details: what is recorded as authorised. A registration still sitting in Planned is invisible to them.

So a change that genuinely affects ten markets returns three. The report is not broken. It is accurately describing a record set that does not describe reality. And nobody questions it, because it looks like an answer.

That is a regulatory risk with a straight line to a missed variation.

Quality processes stall on regulatory records

In connected environments, quality change controls gate on regulatory assessment state. Unassessed records are not a regulatory inconvenience — they are a manufacturing and supply blocker sitting in another department's queue, usually with no visibility into why.

Nobody can answer the basic question

"Where are we approved, with what, as of today?" — for a board paper, a due diligence exercise, an inspection. If the answer lives in a spreadsheet, you have paid for a system of record and are running on a system of memory.

The fix is detection, not training

The instinct is to write a work instruction and run a training session. Do that — but understand it will not be sufficient, because the failure is not ignorance. People know they should update the record. The step simply has no forcing function.

What works is making the gap visible to the person who owns it. Two reports do most of the work:

Report 1 — Reality drift

Records where a decision or approval date is populated, but the status is still Planned.

This is the highest-yield artefact you can put in front of an organisation, because it is not an opinion. Each row is a record that proves itself incomplete: the same record asserts both that a decision was received and that nothing has happened. There is no argument to be had about whether it needs attention.

Report 2 — Promote-ready

Registrations whose submission has reached "Health Authority Received" or archived status, but which have never been promoted.

This is your queue of unrealised work — approvals you have already earned and not yet recorded.

Pair each with three things: a named owner (not a team — a person), a weekly sweep written into someone's actual job, and an ageing escalation so items cannot sit indefinitely. Add a notification when a new market activity is created, so the owner learns about work when it arrives rather than when it blocks something.

If you do only one thing: detect what is unassessed, and tell the person who owns it.

Three cheap changes that outperform their cost

• Rename your user actions. "Change State to Impact Identified" is system language. "Complete Assessment — Impact Identified" tells a user what they are doing and why. This is a configuration change measured in minutes that measurably reduces support tickets.
• Put a hint on the page layout. A short read-me panel linking the governing procedure and a two-minute walkthrough, on the record where the work happens — not in a document library nobody opens.
• Give quality a read-only view. Most cross-departmental chasing exists because the quality team cannot see regulatory progress and has no option but to ask.

Present it as habit, not blame

A closing observation, learned the hard way. When you show an organisation that most of its records are incomplete, you can frame it two ways, and the framing determines whether anything changes.

Framed as a compliance failure, you get defensiveness, disputes about methodology, and an initiative that quietly dies. Framed as "three different people downstream depend on this record, and right now they can't see your work" — you get engagement.

Put the live statistics in the assessment report for the sponsor. Keep them out of the end-user training. Nobody has ever been motivated by a scoreboard showing them losing.

Where to start

If any of this sounds familiar, the diagnostic is genuinely quick. A read-only assessment can tell you, within days and without touching a single record:

• How many registrations are stuck, and how many are ready to promote today
• Which market activities are unassessed, and which of those are provably complete
• Which change items will block a quality gate the next time somebody tries to close one
• Whether your impact assessments are under-reporting, and by roughly how much
• What is accumulating silently — connector errors, overdue document reviews, orphaned records

Most organisations are surprised by at least one number. Almost none of them have a system defect.