The Report You Cannot Hand Over
A custom report here belongs to the person who built it, and there is presently no way to hand it to anybody else. The machinery for deciding who may open a shared report is complete, carefully written and will never be consulted, because nothing in the product can create the record it reads.
We audited our own reporting module on 26 August 2026 and found something we had been describing incorrectly on three live pages. A custom report cannot be shared. Not "sharing is limited", not "sharing lacks expiry" — there is no mechanism to share one at all, and one of our own articles listed the feature among the things we had built.
This page is the accurate version. It is also a good illustration of a failure mode worth recognising in any system you are evaluating, because the reason nobody noticed is more interesting than the fact itself.
Half a feature, and it is the wrong half
Sharing a report is two pieces of work. Someone has to be able to grant access — a button, a form, a choice of person or role, a note of what they may then do. And the system has to enforce that grant when the recipient opens the report.
The second piece is built here, and built well. There is a place to record a share, and it distinguishes four kinds: private to the owner, granted to a named person, granted to a role, or open to the whole organization. When somebody opens a report they do not own, the code works through those possibilities in order and decides what they may do with it.
The first piece was never built. No screen creates a share. No address in the application accepts one. The visibility setting on a report is stamped private at the moment the report comes into existence and nothing anywhere changes it afterwards.
A lock, a key mechanism, and a careful list of who is allowed through — attached to a door with no handle on the other side.
So the enforcement runs on every report open, every time, and finds nothing, correctly, forever. There is no error and no warning, because nothing is wrong. It is doing exactly what it was written to do with the data it has, and the data is an empty set.
Why a test suite did not catch it
This is the part worth taking away, because it generalises well beyond us.
There is a test covering report sharing. It passes. What it checks is that the storage has the right shape — that a place exists to record who a report was shared with, what kind of share it is, and who granted it. Every one of those checks is true.
None of them is a test that a report can be shared. A test of the shape of a container is not a test of the thing the container is for, and the difference is invisible in a summary that says the suite is green.
The general form of this
A capability gets designed, the storage gets built, the read path gets built because it is the interesting engineering, a structural test gets written, and the ordinary screen at the front is left for last and then not done. Everything downstream of the missing piece works perfectly. Nothing upstream of it exists. In a demonstration nobody notices, because a demonstration shows one person opening their own reports.
What this actually means for a business
Less than you would think in some places, and considerably more in others, so it is worth being precise.
The standard reports are not affected. Every module's built-in reporting is governed by ordinary permissions, and those work: viewing, exporting and exporting sensitive figures are separate grants and they are enforced. If somebody in your business needs the stock valuation or the ageing report, they get it through their role, as they should.
What is affected is the report somebody built. A finance manager who assembles a view of margin by branch, with the filters and groupings that make it right, owns that view alone. The way it reaches a colleague is by being run and exported, or by the colleague building the same thing again.
What works today
- Every standard module report, governed by role permissions
- Viewing, exporting and sensitive-export as three separate grants
- Scheduled delivery of a report to people or addresses on a timetable
- Exports recorded with who, what format and which run
- Field-level settings marking a field hidden, sensitive or export-restricted
What a built report can do
- Be built, saved and re-run by its owner
- Be exported and sent on by hand
- Be pinned to its owner's dashboard
- Be scheduled for delivery to others
- Be rebuilt from scratch by the next person who wants it
That fourth item in the right-hand column is the practical escape and it is a real one: a scheduled delivery sends the output to whoever is on the schedule, and it is genuinely built. It sends the same output to everybody on it, so it substitutes for sharing where the audience should all see the same rows, and it does not substitute where they should not.
How to find this in any system, in ten minutes
You do not need access to code. You need two accounts and a stopwatch, and the same method finds the same class of problem in any product you are evaluating.
-
Build something as one person
Not a demonstration report — one with a filter and a grouping, so it is a thing somebody would actually want. Save it.
-
Try to give it to the second account
Look for the button. If you find it, use it. If you spend more than a couple of minutes hunting, that is already the finding, because a feature people use daily is never hard to find.
-
Log in as the second person and look
The only step that proves anything. A share that was accepted by a form and is not visible to the recipient is the same outcome as no share at all, and it is a much more confusing one.
-
Then take the same report away again
Removal is where half-built sharing usually shows itself. If access can be granted and not withdrawn, you have a permanent grant wearing a temporary label.
Four questions, and the last one is the one that matters
Can I share a report I have built with a colleague?
What you will hear
Yes, almost always.
How to read it
A reasonable answer to give in good faith. Ask them to do it while you watch, with two accounts, rather than to describe it. Ours is no today, and this page exists because we said otherwise.
Can I share it with a role rather than a person?
What you will hear
Sometimes.
How to read it
Worth asking because it decides what happens when somebody leaves. A share to a person is a grant you must remember to remove; a share to a role removes itself when the role does.
Can I take a share back, and does the recipient stop seeing it immediately?
What you will hear
Yes.
How to read it
Test the second half. Access that persists in a cached view or a pinned dashboard after removal is the usual defect here and it is invisible from the granting screen.
What test do you have that a report can actually be shared?
What you will hear
A pause.
How to read it
The question that would have caught ours. A test that storage exists is not a test that the feature does, and only this question separates them.
What AWRA OpsHub does today
- Role permissions on every standard module report, with viewing, exporting and exporting sensitive figures as three separate grants.
- Field-level settings marking a field hidden, sensitive, or restricted from export, applied wherever the field appears.
- Scheduled delivery of a report to named people, to a role, or to an email address on a timetable — the route most teams actually want.
- Exports recorded with the person, the format and the run behind them, and report views captured in the audit log.
- A certification workflow on a report definition, so an official version can be marked as such and requested, reviewed and signed off.
More we can add to your workspace
- A way to grant a colleague access to a report you built. The permission model that would govern such a grant is complete and ready for the screen that creates one.
- A visibility control on a saved report, so an owner can move it between private, shared and open to the organization.
- Withdrawal of a granted share, which belongs in the same piece of work as granting one.
- Time-boxed access for an auditor or consultant, expiring on a stated date rather than on somebody remembering.
- Row-level filtering inside one report, so a branch manager opening a group report sees their own branch.
Where we point you to a specialist
- We would rather publish this than describe the read path as though it were the feature. The enforcement is real and well written, and saying so would have been true and misleading at once, which is the failure the ledger exists to prevent.
- Deciding who in your business may see margin, salary or customer detail is your call and your data-protection officer's. We build the partition you specify and would not choose it for you.
- Scheduled delivery is a good answer for an audience who should all see the same rows and a poor one for an audience who should not. We would push back on using it as a substitute for per-recipient filtering rather than let it stand in.
The granting screen, withdrawal, a visibility control and time-boxed access are one coherent piece of work we can scope and quote on.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
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. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThe finding, in one line
The machinery that decides who may open a shared report is finished, correct and unreachable, because the screen that would create a share was never built — and a test asserting the storage had the right shape kept the suite green while the capability was absent. If you are evaluating any system on its sharing, do not ask whether it shares. Open two accounts and try.
Two accounts, ten minutes
Build a report as one person and try to hand it to the other. It is the cheapest test in software evaluation and it finds a class of problem that documentation, demonstrations and green test suites all miss.
Talk to us about reporting accessFrequently asked questions
Can I share a custom report with a colleague today?
No. A report you build belongs to your account. The practical routes are to export and send the file, or to set up a scheduled delivery, which does exist and sends the same output to everyone on it.
Does this affect the standard module reports?
No. Stock valuation, ageing, payroll summaries and the rest are governed by ordinary role permissions, and those are enforced normally on both the web and the API.
What is the workaround for a team that needs one view?
A scheduled delivery to the people who need it, on the cadence they need. It is the closest thing to a shared report the product has and it is genuinely built.
Why did another page on this site say sharing was available?
Because it was wrong, and it has been corrected. The storage and the access rules exist and read as a finished feature from the inside; the screen that would create a share does not. We would rather say so here than leave the claim standing.
