The View Everybody Uses Is a Convention
A saved filter here belongs to one person. A report schedule can be driven by one. So the weekly figures a team runs on can rest on a private view that nobody else is able to open, inspect or inherit.
Every organisation has a number that everybody trusts and one person produces. It is almost never a deliberate arrangement. It is the residue of somebody being helpful for long enough that the helpfulness became infrastructure.
Three things that look similar and are not
This product has three artefacts that all feel like "a report I set up", and they have very different properties.
What each one is, and who can see it
Artefact Ownership
A saved filter Yours alone
A named set of filters on a screen, belonging to a user. No visibility setting, no sharing, no team. Nobody else can open it, inspect it or inherit it.
A report definition Shareable and governable
Carries a visibility setting, can be shared, and can go through a certification review with a requester and a reviewer recorded separately.
A report schedule Sends to others
Delivers on a cadence to named users, roles or external email addresses — and it can be driven by a saved filter.
The third row is where the three interact, and it is the one worth thinking about.
The interaction
A schedule can reference a saved filter. A saved filter belongs to one person and cannot be opened by anybody else.
So a weekly figure can be delivered to a dozen people, generated from a view exactly one of them can inspect. The recipients see the output and cannot see the question.
The recipients can read the answer and cannot read the question, which is a strange position for a number a team makes decisions on.
Why this is not obviously wrong
Personal saved filters are correct as a design. A filter is a working preference — the way somebody likes their list arranged — and making every one of them a shared object would produce a list of four hundred views with no owner, which is its own well-known failure.
The problem is not that filters are personal. It is that a personal object can become a shared dependency without anything marking the transition, and there is no moment at which the system asks whether that is intended.
What happens when that person leaves
The sequence, which is always the same
The last row is the cost. The data is all still there; what is gone is the agreement about which slice of it counted.
The practice that avoids it
-
If more than one person depends on it, it is a definition
Report definitions are shareable and certifiable. Saved filters are not. The moment a view has an audience, it should be the first kind of thing.
-
Never schedule from a personal filter to other people
This is the specific rule. Sending your own view to yourself is fine; sending it to a team creates a dependency nobody else can inspect.
-
Certify the ones that matter
The workflow exists and records a reviewer separately from the requester. Use it on the handful of numbers that get quoted, and treat certification as attaching to the day it was granted.
-
Audit schedules when somebody changes role
Schedules are durable and outlive intent. Leavers are the moment to look, and it is the moment nobody looks.
What AWRA OpsHub does today
- Personal saved filters per user and module, with no permission required to create one.
- Report definitions with a visibility setting, sharing, and a certification workflow recording requester and reviewer separately.
- Report schedules that can reference either a saved filter or a report definition.
- Pinned reports on a dashboard.
- A record of report runs, so who ran what and when is answerable.
What it does not do
- Any sharing, visibility or team ownership on a saved filter.
- Any warning when a schedule sending to other people is driven by a personal filter.
- Any transfer of ownership when a user leaves or changes role.
- Any view of which artefacts a departing user owns.
- Version history on a report definition, so a shared one can change without a record.
Not ours, by choice
- Personal filters are the right design and we are not proposing to share them. The gap is the absence of a boundary between a working preference and a shared dependency.
- The certification workflow is real and useful, and it attaches to a definition rather than to a version — which is a separate finding we publish on its own page.
- Nothing here is Australian, New Zealand or Pacific. Oceania is here because small head-office teams covering dispersed operations are the norm, and that is exactly the shape where one person's view quietly becomes everybody's number.
Two small ones, and neither changes how filters work
The aim is to mark the transition from preference to dependency, not to make every personal view a governed object.
A warning when a schedule sends a personal filter to others
At the moment the schedule is created, not later. It is a sentence on a form and it is the entire intervention — it converts an invisible dependency into a decision somebody made knowingly.
Ownership transfer on departure
A view of what a user owns — filters, definitions, schedules — and a way to reassign it before the account is deactivated. This is the leaver checklist item that does not currently exist, and it is where the knowledge is actually lost.
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.
Talk to us about report ownershipFour questions about shared numbers
Who else can open this saved view?
A good answer sounds like
A named group.
What it actually means
If the answer is nobody, and other people receive its output, you have found a dependency.
What happens to it when its owner leaves?
A good answer sounds like
It transfers.
What it actually means
Ours has no transfer. This is the leaver question nobody asks about reporting.
Is this number a definition or a filter?
A good answer sounds like
They know the difference.
What it actually means
The two look identical on screen and have completely different properties.
Can I see every scheduled report in the organisation?
A good answer sounds like
Yes, one screen.
What it actually means
Ours has no such screen, so nobody has the whole picture of what is going out.
Our position
Keep personal filters personal, and apply one rule: anything sent to somebody else should be a report definition, not a saved filter. Then check what a departing user owned before you deactivate the account — because the data will still be there, and the agreement about which slice of it counted will not.
Find the number one person produces
Every organisation has one. Ask whether it comes from a shared definition or a private view, and you will know within a minute whether it survives that person.
Talk about reporting governanceFrequently asked questions
Can I convert a saved filter into a report definition?
They are different objects rather than two states of one, so in practice it means rebuilding the view as a definition. That is a few minutes of work and it is worth doing for anything with an audience.
Does a pinned report share the same problem?
A pin arranges a dashboard rather than defining a number, so the exposure is smaller. The question worth asking is always what the pinned thing points at — a shared definition or a personal filter.
Why not require a permission to save a filter?
Because it is a working preference and gating it would make the product worse for everybody to solve a problem that only appears when a filter acquires an audience. The intervention belongs at the moment it gets shared, not at the moment it is created.
