The Permission That Is Really a Mailing List
One permission lets somebody schedule a report to a list of email addresses. The addresses are not checked against your user list, and nothing compares what the report contains against what each recipient is allowed to see.
Access control in most business systems governs what you can open. It very rarely governs what you can send, and the two are different questions that people assume are the same one.
The position, stated first
This is a delegation feature working as designed, not a hole — scheduling requires its own permission, and emailing a pack to somebody outside the organisation is the point of it. What a buyer needs to understand is that granting that permission grants the ability to redistribute any schedulable report to any address, and that the report's own access rules do not follow it out of the door.
How a recipient list is assembled
Three sources, merged and de-duplicated.
-
Named users
Chosen from your user list, scoped to your organisation. The addresses come from their accounts.
-
Roles
Everybody currently holding a role, resolved at send time — so the list follows the role rather than being a snapshot. This is the right behaviour and it means a new joiner starts receiving the report without anybody remembering.
-
Free-text email addresses
A comma-separated list. No user lookup, no membership check, no verification. Any address at all.
The report is then rendered once per format, and the same file goes to every address on the merged list.
What is not checked
Whether any given recipient would be permitted to open that report interactively.
A person who cannot reach the margin report in the interface because their role does not carry the permission will still receive the margin report by email if somebody put them on the schedule. The delivery path does not consult the access model at all.
The permission to schedule is the permission to redistribute, and it is a single grant that is not bounded by the reports it can redistribute.
Why this is not simply a bug
Because the most valuable use of scheduled reports is exactly this. A monthly pack to a board member who has no account. A stock summary to a supplier. A performance extract to an auditor. Every one of those requires sending data to somebody the access model has never heard of, and a system that refused would be useless.
The design question is not whether to allow it. It is whether the permission that allows it is narrow enough to be granted deliberately, and whether the organisation understands what it confers.
What people assume it means
- Can set up a delivery of reports they can already see
- Recipients get what they are entitled to
- Internal distribution only
- Bounded by the report's own permission
What it actually means
- Can schedule any schedulable report
- Recipients get the report, entitled or not
- Any email address, inside or out
- Bounded by nothing except the grant itself
What to do when you grant it
Treat schedule_reports as a senior permission and grant it the way you would grant the ability to export. It is the same class of thing: a route by which data leaves the boundary, deliberately, at somebody's discretion.
Then review the schedules themselves periodically. A schedule is durable — it keeps sending after the person who created it changes role, and a role-based recipient list keeps adding people as the role fills. Both of those are correct behaviours and both mean a schedule left alone drifts away from the intent it was created with.
Two, and the first is a report about the reports
Neither of these restricts the feature. They make it reviewable, which is what a delegated redistribution capability actually needs.
A schedule register
Every active schedule, what it sends, who created it, who receives it, and which recipients are external addresses rather than users — on one screen, reviewable in ten minutes. Today a schedule is visible to the person who made it, and nobody has the whole picture.
A warning where a recipient could not open the report
Not a refusal — a flag at the moment the schedule is created, naming the recipients whose permissions would not let them view it interactively. It keeps the delegation and removes the accident, which is the part that is worth removing.
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 operate a group structure with external directors, the register is the one to ask for.
Talk to us about report distributionWhat AWRA OpsHub does today
- Report schedules guarded by their own permission on every route — create, preview, pause, resume and delete.
- Three recipient sources: named users, roles resolved at send time, and free-text email addresses.
- A per-schedule timezone, so a schedule runs in the time of the place that reads it.
- Multiple output formats per schedule.
- Delivery records per schedule, so what was sent and when is answerable.
What it does not do
- Any permission check on a recipient. The delivery path does not consult the access model.
- Per-recipient data filtering — everyone on a schedule receives the identical artefact.
- Conditional delivery. A schedule sends whether or not there is anything to report.
- Any verification that a free-text address belongs to anybody in particular.
- An organisation-wide register of active schedules and their recipients.
Not ours, by choice
- Sending data to people outside the access model is the purpose of this feature, not a flaw in it. We would not build a version that refused, and a vendor claiming their scheduler is bounded by report permissions has probably not built external delivery at all.
- The permission gate is real and is on every route. This page is about what the grant confers, which is broader than the phrase "schedule reports" suggests.
- Nothing here is Nigerian or Ghanaian. Lagos and Accra are here because group structures with external directors and investors are ordinary there, which makes outward distribution a daily operation rather than an exception.
Four questions about scheduled delivery
Can a schedule send to an address with no account?
A good answer sounds like
Yes — that is the point.
What it actually means
A no means no external delivery, which is a bigger limitation than it sounds.
Is a recipient's permission checked?
A good answer sounds like
An honest no, or a warning.
What it actually means
Almost universally no. Knowing it lets you scope the grant accordingly.
Who can see every active schedule?
A good answer sounds like
An administrator, on one screen.
What it actually means
Ours has no such screen. A delegated capability nobody can review is a capability that drifts.
Does a role-based list update as the role changes?
A good answer sounds like
Yes, at send time.
What it actually means
Ours does, which is right — and it means the recipient list on day one is not the list on day two hundred.
Review your schedules once a quarter
They are durable, they follow roles, and they outlive the intent that created them. Ten minutes a quarter is the whole control.
Talk about report governanceFrequently asked questions
Can I stop external addresses being used?
Not as a setting. The control available today is who holds the scheduling permission, which is why we would treat it as a senior grant rather than a convenience one.
What happens when a recipient leaves?
A named user or a role-based recipient drops out as their account or role changes, which is the right behaviour. A free-text address does not — it is a string, and it keeps receiving until somebody edits the schedule.
Is the delivery recorded?
Yes, per schedule, so what was sent and when is answerable after the fact. What is not available is a single organisation-wide view of every schedule and its recipients, which is the thing that would make the after-the-fact record useful before the fact.
