Permissions: design for trust, not for control

A user needs a contract in order to respond to a customer. They open the ECM, search for it, but can’t find it. The contract exists, but they don’t have access to it. They therefore send a message to a colleague, who finds the contract, downloads it, and sends it as an email attachment.

The permission model has done exactly what it was designed to do. However, the document has now left the system with no audit trail or version control, and a copy is sitting in someone’s inbox indefinitely. Security hasn’t improved. It got worse.

I’ve seen versions of this story in many projects. This is why I think permissions are one of the most misunderstood aspects of ECM.

Permissions are a user experience decision

We tend to treat permissions as a security topic, and they are!

However, every permission rule also affects how people work every day. A rule that blocks access does more than just protect information. It also creates friction, and friction incurs a cost that is paid repeatedly.

When this cost becomes too high, people will find another way. They email files, save copies on their desktop or maintain a private folder ‘just in case’. The ECM slowly becomes the place where documents are archived, while real work happens elsewhere.

This is why I would argue that an overly restricted system does not become safer. It is bypassed.

Why do we default to control?

If restrictive models cause so many problems, why do organizations continue to build them? I can think of a few reasons why.

Fear of the worst-case scenario. Designs are driven by the one incident that everyone wants to avoid, rather than the thousand normal situations that occur every day.

Incentives that point one way. Nobody gets credit for granting access that turns out to be fine. But everyone remembers who was in charge when something leaked. Over-restriction feels like the safe personal choice, even when it isn’t the safe organizational one.

Copying the past. Many permission models are a direct translation of the old file sharing system, with the same folders, groups and exceptions that have been built up over the last fifteen years. The new system inherits this old mess, and it’s now harder to see.

The hidden costs of “just lock it down”

Over-restriction rarely shows up in a project report, but its effects are real:

• Workarounds and shadow copies. Every document that gets emailed or duplicated is a new piece of information debt.
• Access requests. Administrators and support teams spend their time granting, one exception at a time, what the model should have allowed from the start.
• Poor search. People can’t find what they can’t see. When users learn that search often returns nothing useful, they stop trusting it.
• Lower adoption. If the system blocks people during their first week, they form an opinion that’s hard to change later.

A useful indicator: look at the number of access requests you receive each month. It tells you more about your permission model than any design document.

The opposite mistake

I’m not suggesting that everything should be opened up. Some content genuinely requires strict control, such as HR files, legal matters and financial data, or anything else that is subject to confidentiality obligations. Being open by default doesn’t mean being careless.

The goal is to be deliberate. Protect what needs strong protection, strongly. Make the rest easy. Problems arise when the same level of restriction is applied to everything, simply because it’s easier than making decisions.

A better approach

These are the principles that I try to apply when designing a permission model:

Think in terms of exceptions rather than grants

For most content, ask ‘Who shouldn’t see this?’ rather than ‘Who is allowed to see this?’ Reserve the strict whitelist approach for truly sensitive content.

Use roles and context rather than individuals

If you find yourself managing permissions on a document-by-document or user-by-user basis, the model is too granular. People change roles, projects end and individual permissions are never cleaned up.

Let metadata drive access

This is an area in which a metadata-driven system like M-Files has a real advantage. When access follows properties such as project, department or confidentiality level, the permission model reflects how the business is organized rather than how a folder tree happens to look. With workspaces, this becomes even more intuitive: the context defines who is involved.

Let the lifecycle do the work

Access requirements often change as a document moves through its lifecycle. For example, a draft might be visible only to its authors, an approved version to the whole department, and an archived version to a read-only audience. If your workflow can adjust access permissions at each stage, there is no need for manual management.

Keep the model explainable

A good test is to ask yourself if you can explain your permission model to a colleague in five minutes. If administrators cannot explain it, users certainly won’t trust it. Complex permissions carry their own risks, because nobody dares to change anything.

Trust as a design principle

Another way to think about this is as follows. A permission model is not just a set of restrictions. It also reflects how much the organization trusts its people.

Granting broader access, combined with clear audit trails, can often provide better protection than blocking. People behave differently when they know access is being recorded. This approach also enables you to detect real problems instead of preventing hypothetical ones at the expense of everyday work.

Two things are key to making this approach work in practice:

• Make requesting access easy. Exceptions will always exist. If access requests are quick, visible and responded to promptly, people will use the system instead of finding a workaround.
• Explain the model. Users who understand why something is restricted will accept it far more easily than users who just see a ‘You don’t have permission’ message.

A quick self-check

If you’re wondering where your own system stands, ask yourself:

• Can a new employee do useful work on their first day?
• How many access requests do you receive per month, and what patterns do you see?
• Which content is really sensitive, and is it protected differently from the rest?
• Can you explain your permission model in five minutes?
• What workaround are people using today, and what does it tell you about the model?

The answers are usually more revealing than any audit.

Conclusion

Security and usability aren’t opposites, but they do compete for attention when you design a permission model. If you optimize only for control, you end up with a system that looks safe and pushes people to work around it.

The best permission model is one that users barely notice: it gives them what they need, blocks what truly matters, and leaves an audit trail for everything in between.

How do you handle permissions in your projects? I’d be curious to hear what has worked and what hasn’t.