Permission models fail in one of two directions and the second is worse.

Too loose and the model protects nothing. Everyone can see everything, the supplier portal shows more than it should and the first time this matters is an audit or a lost tender.

Too tight and people route around it. Someone cannot open the drawing they need, so a colleague emails it. Now the controlled document exists as an uncontrolled copy in an inbox, which is precisely the outcome the permission was meant to prevent. A model people bypass is not a strict model. It is an absent one with extra steps.

The second failure is worse because it is invisible. Nothing errors. Nobody files a ticket. The system reports full compliance while the real data flow has quietly moved to email.

Design from questions, not from the org chart

The common approach is to mirror reporting lines: department groups, a role per job title, permissions attached to each. It produces a model nobody can reason about within two years, because job titles change constantly and the model has no memory of why any given grant exists.

Design from the questions the business actually asks instead. There are usually about six:

  • Who may see a part before it is released?
  • Who may change it after release?
  • What can a supplier see, and only for the parts they quote or make?
  • What can a customer see?
  • Who may see cost?
  • Who may see this specific project, when the project itself is confidential?

Each question has an answer expressible as a rule. Rules survive reorganisations; group memberships built from an org chart do not.

The four rules that keep it maintainable

1. Grant to teams and states, never to individuals.

An individual grant is invisible in six months. Nobody knows why j.patel has write access to that assembly, so nobody dares remove it, and it accumulates. When someone changes role, individual grants follow them silently. Grants belong to a team or a role, and people move between teams — that way membership changes are one edit, in one place, with an obvious meaning.

2. Let the lifecycle do the work.

Most access questions are really state questions in disguise. "Who can edit this?" almost always means "who can edit this while it is in progress", and the answer changes the moment it is released. If your model expresses that directly — the same item grants differently in Draft than in Released — you have eliminated an entire category of manual permission management, and you have made "released means locked" true by construction rather than by discipline.

This is where a platform whose permissions are configuration data rather than code pays for itself, because state-dependent access is exactly the rule that is tedious to hard-code and trivial to model.

3. Deny by default, and make the exception path fast.

Deny-by-default is the correct starting posture, but on its own it produces the second failure mode above. It only works if there is a legitimate, quick way to get access when someone genuinely needs it.

If requesting access takes three days, people will not request it. They will ask a colleague to send the file, and you will have traded a controlled system for an uncontrolled one. A same-day request path is not a convenience — it is what makes the strictness real.

4. Every rule must be explainable in one sentence.

If you cannot say why a grant exists in a sentence a non-specialist understands, it will never be safely removed, because nobody will know what removing it breaks. Write the sentence down when you create the rule. "Suppliers on the sourcing team for a part may view its released drawing and its material spec, and nothing else" is maintainable. A stack of overlapping group grants accumulated over four years is not.

Test it from the outside

Design reviews of permission models tend to check that authorised people have access. That is the easy half, and the half that gets tested in practice anyway — because if someone lacks access they complain immediately.

Test the other direction, which nobody complains about:

  • Log in as a supplier account and try to reach a part that supplier does not work on. Try the search. Try a direct URL to the item. Try the file itself rather than the record — this is where models most often leak, because the metadata is locked down and the vault link is not.
  • Log in as a standard engineer and try to reach the confidential project.
  • Take a released item and try to edit it as someone who should not be able to.
  • Take a person who left a team last month and confirm what they can still reach.

That last one finds the most problems, and it is the one that never gets tested.

The signals that your model is wrong

  • People email files. The single clearest signal, and the reason to ask rather than assume — nobody reports it, because from their point of view they are being helpful.
  • Everyone has been added to one large group because it was the fastest way to fix a complaint. That group is now your real permission model.
  • Nobody can say who can see cost. If the answer requires investigation, the answer is probably "more people than you think".
  • The access request queue is measured in days. See rule 3.
  • Leavers still have access. Not a permission problem exactly, but the same root cause: grants that live on individuals rather than on membership.

Where to start if the model is already a mess

Do not redesign it in one pass. Inventory it first — every group, every rule, who is in it and, where anyone can remember, why. Simply writing that down usually reveals that half the groups are unused and a handful of overlapping ones do all the work.

Then take the six questions above and answer them with rules, one at a time, retiring old grants only as each new rule demonstrably covers them. A permission model is one of the few things in PLM where a big-bang cutover is genuinely dangerous: get it wrong in the loose direction and you have leaked data; get it wrong in the tight direction and you have stopped production. Incremental is not timidity here, it is the correct engineering judgement.

Working paper. If you are reworking an access model — particularly one covering export-controlled or customer-confidential data — get in touch.