Row-level security done right: when everyone should see only their own numbers

One report, many audiences, and each one allowed to see only their own slice. Row-level security is how you do it without building the same report ten times.

Plenty of reporting problems are really access problems wearing a disguise. A business has one set of numbers, but the people who need them are not all allowed to see the same rows. Investors should see only the developments they have money in. Regional managers should see only their region. A supplier portal should show a supplier their orders and nobody else’s. The lazy answer is to build a separate report for each audience and keep them in step by hand. It works for a while, then it drifts, and one day someone sees a number they should never have seen.

Row-level security is the answer

Done properly, it means one model, one report, and rules that decide what each person sees the moment they open it. We built this recently for a housebuilder reporting across three portfolios and dozens of separate entities. The monthly investor reporting was one of the heaviest manual burdens in the business, precisely because every investor was entitled to a different slice and assembling those slices by hand was slow and risky. On governed data with row-level security, each investor now opens the same report and sees only their own developments. The rules travel with the model, not with the person who built last month’s pack.

Security belongs in the data, not the copy

The principle is simple. Once the rule lives in the model, every report, dashboard and export built on top of it inherits the same boundary automatically. You are not trusting a person to remember to filter the file before they send it. The filter is not optional and it is not manual.

What separates security that holds from security that leaks

A few things make the difference between row-level security you can trust and row-level security that quietly lets a number escape.

• Map the rule to something real. The boundary should follow the business relationship, an investor to their developments, a manager to their region, not a static list of names someone has to maintain. Lists rot. Relationships in the data do not.
• Test it as the person, not as yourself. The developer building the model can see everything, which is exactly why the developer is the worst person to judge whether the security works. Every role has to be tested through the eyes of someone inside it.
• Mind the exports and the edges. Security that holds on the screen can still leak through a download, a subscription email or a poorly scoped export. The boundary has to hold everywhere the data can leave, not just in the main view.
• Keep the model single. The whole point is one governed model serving many audiences. The moment you clone it to handle an awkward case, you are back to keeping copies in step by hand, which is the problem you were solving.

Where reporting and governance meet

Row-level security is where good reporting and good governance meet. It is the difference between a business that can safely open its numbers to investors, partners and suppliers, and one that keeps everything locked down because it cannot trust who sees what. Get it right and the same platform that runs your internal reporting can safely face outward too. If you are running the same report several times over because different people are allowed to see different rows, that is a governance job worth doing once and properly. Talk to us at hello@hoptonanalytics.com.