The Permissions for a Module That Was Never Built
There are four permissions in our role editor governing who may view, create, edit and delete a proposal. There is no proposals feature — no record, no screen, no address, nothing. The permissions describe a plan, and a plan is what a permission list is made of.
When you evaluate business software you are shown a great deal of evidence, and some of it is much weaker than it looks. The permission list is a good example, and it is the one buyers trust most, because it seems like it comes from the machine rather than from the marketing.
It does come from the machine. It just does not come from the part of the machine that does anything.
Four permissions and no feature
We audited our own on 26 August 2026. Among about two hundred and fifty permissions an administrator can grant, four govern proposals — viewing, creating, editing and deleting them.
There is no proposals feature. Not a limited one, not an early one: there is no record type, no screen, no address you could visit, and nothing anywhere that stores such a thing. The one place the word appears in the product's navigation is inside a comment, which by definition renders nothing.
The four permissions render perfectly. They are in the list, they can be granted to a role, saved, exported and reported on. An administrator could spend a careful afternoon deciding which roles may delete a proposal.
The permission list is a description of the product somebody intended to build. It is generated from a file, and the file was written first.
Why this happens everywhere
Because of the order the work gets done in, and the order is sensible.
When a module is designed, the permissions are one of the first things written down — they are cheap, they are a good way to think about who does what, and they belong to the design rather than to the implementation. They go into a list, and the list becomes real immediately, because the role editor is built to render whatever is in it.
Then the module gets built, or it gets postponed, or it gets replaced by a different idea, or it gets absorbed into a neighbouring feature. Whichever of those happens, the permissions stay, because nothing removes them and nothing checks.
So a mature permission list is an archaeological record. Some of it describes what the product does. Some of it describes what the product does under other names. And some of it describes work that was scoped and never started — indistinguishable from the rest, in the same alphabetical list, rendered by the same screen.
What is actually there instead
This matters for anybody reading the finding as "they cannot send a customer an offer". Quotations are real and they are substantial: numbered, dated, itemised, with tax handled per line, a currency, a snapshot of the terms as they stood, a status, and conversion straight into a purchase order on acceptance.
What a quotation is not is a proposal in the sense a consultancy or an agency means it — a narrative document with scope, approach, options at different prices, assumptions, and an acceptance that ties the client to a version. Those are different documents that happen to share a stage in the sales process, and the difference is precisely why somebody once planned a second module.
What a quotation does here
- Numbered, dated and itemised
- Per-line tax and a currency
- A snapshot of terms as they stood
- A status through to acceptance
- Converts into a purchase order
What a proposal would add
- Narrative scope and approach
- Options at different prices in one document
- Stated assumptions and exclusions
- Acceptance tied to a specific version
- A document that reads as a document
How to read a feature list, whoever wrote it
The general lesson is not about permissions. It is that almost every artefact you are shown during an evaluation is generated from a description of the product rather than from the product.
- A permission list comes from a configuration file. It describes an intended design.
- A feature comparison comes from a marketing document. It describes a positioning.
- An interface reference comes from a schema. It describes what was defined, which is not always what was wired — we published a case of exactly that in a report-sharing mechanism with no way to create a share.
- A menu comes from a template, and a menu item can be present and disabled, or absent and the feature still reachable.
Only one artefact describes the product: the product. Which is why the only evaluation step that reliably works is the boring one — open it, and do the thing.
-
Write down the six things you will actually do weekly
Not features. Actions, in your words. "Send a client a priced proposal with two options and get it accepted."
-
Do each one in a trial account, yourself
Not in a demonstration. A demonstration is a route somebody has walked before, and the interesting failures are all just off it.
-
Note where you had to ask how
Anything you could not find in two minutes is something your team will not find either, and support tickets are the cheapest thing to predict during an evaluation.
-
Then read the feature list, and only then
It becomes useful once you know what the words mean in that product. Read first and it tells you what somebody hoped you would understand.
Three questions that make a feature list honest
Is everything in your permission list attached to something that exists?
What you will hear
Yes, sincerely.
How to read it
Almost nobody has measured this, because measuring it means comparing a configuration file against every screen. Ours had twenty-nine that were not. The answer you want is a number, not a reassurance.
Show me this feature being used on a record you did not prepare.
What you will hear
Usually fine, occasionally revealing.
How to read it
The strongest single request in any evaluation. A prepared record hides the setup work, and the setup work is most of what you are buying.
What is in here that was built and then superseded?
What you will hear
A story, if they are honest.
How to read it
Every product past a couple of years has some. A vendor who can name theirs has looked at their own system recently, which tells you more about how they work than the answer itself does.
What AWRA OpsHub does today
- Quotations as full documents — numbered, dated, itemised, with per-line tax, a currency and a snapshot of terms as they stood when issued.
- A status through to acceptance, and conversion of an accepted quotation into a purchase order without rekeying the lines.
- Customer records with named contacts and structured addresses, so a document goes to a person rather than to a text field.
- Invoices, credit notes and statements downstream, with payments recorded against them.
More we can add to your workspace
- A proposal as a distinct document type, with narrative scope, approach and stated assumptions alongside the pricing.
- Options at several prices inside one document, so a client chooses between packages rather than comparing three separate quotations.
- Acceptance tied to a specific version, so what the client agreed to is recoverable after the document has been revised.
- Removal of the four proposal permissions from the role editor, so the list stops describing a module that was planned rather than built.
Where we point you to a specialist
- A permission list should describe what a product does, and where ours has described a plan we would rather publish that than tidy it away. The four permissions are being removed; saying so here is part of the same job.
- Whether your business needs a proposal distinct from a quotation is a question about how you sell rather than about software. Plenty of businesses are complete with a quotation, and we would say so rather than sell a second document to somebody who does not need one.
- We would decline to relabel quotations as proposals to close this. They are different documents doing different work, and a renamed quotation would satisfy a feature list while leaving the person who needed a proposal exactly where they were.
A proposal document with narrative scope, priced options and version-tied acceptance is scoped work we can quote on.
Two, and the second one is subtraction
One adds the document somebody planned. The other removes the description of it, which is the part that misleads.
A proposal document
Narrative scope and assumptions alongside pricing, options at several prices in one document, and an acceptance that records which version the client agreed to — which is the piece that matters when the scope is later disputed.
A permission list that matches the product
The four proposal permissions removed, and a build check that fails when a permission is offered in the role editor and consulted by nothing. The check is what stops this recurring, and it is the more valuable half.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you sell scoped work rather than priced items, the first item is the one to raise.
Talk to us about sales documentsThe short version
A permission list is written when a module is designed and rendered by a screen that never asks whether the module was built. So it shows you the product somebody intended, mixed indistinguishably with the product that exists, in one alphabetical list. Ours contains four permissions for a feature with no record, no screen and no address behind it. Read every feature list that way — including this company's — and check the six things you will actually do by doing them.
Do the six things yourself
Whatever you are evaluating, and whoever is selling it. Write down the six actions you will take weekly, then perform them in a trial account without help. It is the only evaluation step that tests the product rather than a description of it.
Talk to us about what we actually do