The Same Report, Different Rows
The usual way to stop a branch manager seeing every branch’s figures is to build them their own copy of the report. Then there are twelve copies, and they drift. Row security lets one report show each person only their rows, decided by who is looking, and fails closed when it cannot tell.
The finance team built a good sales-by-branch report, and then the branch managers wanted it. They could not be given it as it was, because each of them would see every other branch’s margins. So the report was copied twelve times, one filter each. Within a quarter, three copies had an extra column, two were missing the returns adjustment, and the one the managing director read was not the one the branches were measured on.
Copying a report to restrict it is the most common access control in small and mid-sized organizations, and it fails slowly. Nobody decides that the copies should differ. They just do, one edit at a time, until the same question has twelve answers. We have written about the other half of the problem, deciding who may see a report at all, in report sharing and permissions. Row security is the narrower question inside it: everyone may open this report, and each of them should see different rows.
A rule that reads who is looking
A row rule says: for these viewers, keep only the rows where this field matches this value. The viewers are one person, one role, or everyone. The value can be fixed, such as a single region, but the useful version takes it from the viewer: their own user, their department, their warehouse or their employee record. One rule, “warehouse equals the viewer’s warehouse, for the Branch Manager role”, replaces twelve copies, and a thirteenth branch needs no new report at all.
| Rule | Who it applies to | What each person sees |
|---|---|---|
| Warehouse = viewer’s warehouse | Branch Manager role | Their own branch’s rows |
| Department = viewer’s department | Everyone | Their own department’s spend |
| Assignee = viewer’s employee record | Field Staff role | Their own tasks and time |
| Region is not Head Office | One named contractor | Everything except head-office rows |
When it cannot tell, it shows nothing
If a viewer has no warehouse set, or the rule’s field has been removed from the dataset, they see zero rows, not all of them. A row rule that fails open is worse than none, because everyone believes it is working. The people who manage all reports are not limited by rules, so someone can always check the whole picture.
The parts that make one report safe to share
Row rules only help if the report underneath is one people can trust. Three other pieces matter for that.
- A data dictionary with an owner for each dataset and a set of certified calculations, so gross margin means one thing on every report rather than whatever the author typed.
- Joins that cannot multiply rows. A report can bring in a related record’s fields, such as an invoice’s customer or a bill’s purchase order, but only along declared relations, from a record to its single parent. Adding a column never turns one invoice into three and inflates a total. That is the problem behind one dataset per report, solved without giving up the related fields.
- Guardrails for size. A run stops after 30 seconds and asks for a filter; each plan has a row limit per run; heavy reports can be built every hour ahead of time. A person limited by a row rule always gets a live run rather than the owner’s pre-built copy, because that copy holds everyone’s rows.
Twelve copies of a report is not access control. It is twelve reports.
When the rows leave the building
Row security governs what a person sees on screen. An export is the moment that view becomes a file nobody controls. A sensitive report can require its own export permission and a written reason, and the file carries a watermark with who exported it, their email, the date and the organization. That does not stop a determined person, and nothing would. It does mean that a spreadsheet found in the wrong inbox says where it came from, which changes how carelessly people treat it. The role design underneath all of this is in role-based access control.
Row rules in more places
Row rules run on the reports you build today. The engine that applies them is not specific to the builder, and three extensions come up most often.
Rules on system reports
The same viewer-based rules on the maintained reports by module, not only on reports you build.
Columns hidden by role
A cost or margin column that some roles never see, on a report they can otherwise open.
Scheduled deliveries per recipient
A scheduled report emailed to a group, with each recipient’s copy filtered by their own rules.
What AWRA OpsHub does today
- Row rules for one person, one role or everyone, matching a fixed value or the viewer’s own user, department, warehouse or employee record.
- Fail-closed behaviour: no viewer value or a missing field means no rows.
- A data dictionary with dataset owners and certified calculations, on the web, over the API and in the mobile app.
- Joins along declared relations that never multiply rows, and pivots up to 24 columns and 500 rows.
- A 30-second time limit, a row limit per plan, cached previews and hourly pre-built results, with live runs for anyone under a row rule.
- A reason and a watermark on sensitive exports.
More we can add to your workspace
- Row rules on the system reports by module, alongside the reports you build.
- Columns hidden by role on a report a person may otherwise open.
- Scheduled deliveries filtered per recipient by each recipient’s own row rules.
Where we point you to a specialist
- We will not decide who in your organization should see which figures. Row rules enforce the policy you write; the policy is yours.
Rules on the system reports reuse the row-security engine already applied to the builder.
Our position
Build the report once and decide the rows by who is looking. Take the value from the viewer rather than typing it into twelve filters, make the rule fail closed, and keep one person able to see everything. Pair it with a data dictionary so the one report means one thing, and with a reason and a watermark on the exports that leave.
See the report builder
Build a report once, join related records safely, and let each person see only their own rows.
Explore custom reportsFrequently asked questions
What can a row security rule be based on?
Any field in the report’s dataset, compared with a fixed value or with something about the viewer: their own user, their department, their warehouse or their employee record.
What does someone see if the rule cannot be applied to them?
Nothing. If the viewer has no value for the field, such as no warehouse set, or the field no longer exists, they see zero rows rather than all of them.
Can anyone see the whole report?
Yes. People with the manage all reports permission are not limited by row rules.
Do pre-built report results bypass row rules?
No. A person limited by a row rule always gets a live run, because the pre-built copy is made as the report owner and holds everyone’s rows.
How large can a report be?
Each run is limited by plan: 2,000 rows on Free, 5,000 on Basic, 25,000 on Pro, 50,000 on Premium and 100,000 on Enterprise. A run that takes longer than 30 seconds stops and asks for a filter.
