No list of administrators, and that's the tool's best idea

An international group, a whistleblowing channel, two groups of users: the central team that handles the cases, and the reporters who file them. The application has to know who is who. The usual answer is a list of administrators, and I didn't build one.

The problem with lists

A list of administrators is simple at first. A few names in a table. The application reads the table and shows the right screens.

Then the team's life goes on. Someone joins. Someone leaves. Access rights are updated on one side, the list on the other. Sometimes by two different people. Sometimes not at all.

The day the two stop saying the same thing, the application gets it wrong. It shows case-handling screens to someone who no longer has the rights. Or it hides them from someone who should see them.

One more list is one more truth. And two truths end up contradicting each other.

One question at startup

In this tool, there is no list. At startup, the application asks itself one question.

"Can I see cases created by people other than me?"

If so, the user belongs to the central team. The case-handling screens switch on.

If not, they are a reporter. They see their own space, and only their own space.

Why does it work? Because the platform already knows who is allowed to read what. A reporter reads only their own reports. The central team reads everything. The application doesn't need to be told who is who: it observes it.

The role is deduced from actual permissions

That's the heart of the idea. The role isn't declared in a table. It's deduced from actual permissions.

Three consequences.

• One source of truth. Access rights. Nothing else.
• Zero tables to maintain. When someone joins or leaves the central team, you change their rights. The application follows on its own.
• No possible mismatch. The screen shown and the data that can be read come from the same source. They can't contradict each other.

To be honest, it's not the solution people expect. They expect an admin screen, a list, checkboxes. Here, there's none of that. And that's exactly what makes the tool solid.

Why it's the right idea for compliance

In a whistleblowing system, the question "who sees what?" isn't a detail. It's the heart of the matter.

With a list, the answer depends on two things that must stay aligned: the rights, and the list. With a role deduced from the rights, the answer depends on one thing only. When someone asks you who has access to the cases, you look at the rights. The tool can't say anything different.

This choice goes hand in hand with another: confidentiality is carried by the platform's permissions, at the data level. The interface protects nothing. It simply shows what the rights allow.

What this means for you

Look at your internal tools. How many keep their own list of "who is allowed to do what"? A table of approvers, an administrators tab, a list of owners?

Each of these lists risks duplicating information that already exists, for example in the access rights. And each one can drift.

• For each list, ask who updates it, and when.
• Ask whether the information already exists in the access rights.
• If it does, ask your technical team whether the role can be deduced from them, instead of being maintained by hand.

When the answer is yes, the list can go. With it go the oversights, the gaps and the question "who updated the list?".

The same tool applies this idea to security: hiding a button does not protect the data. It also computes the status of each case instead of having it typed in: the status that is computed. The full project is in the case study A whistleblowing channel that watches its own deadlines. The approach is described on the page An application instead of the Excel file.

The best reference list is the one you never need to keep up to date.