Row level security for event portfolios where a director sees only their show

The sales director for the design shows asked for access to the portfolio dashboard and got a polite delay that lasted four months. The reason nobody would say out loud was the rate card. The dashboard held booth pricing for all nine shows, including two run by a team she had left on bad terms, and there was no way to hand her the page without handing her their commercial position.

So the data team did what teams do. They built her a copy. Then the events team asked, and got another copy. Row level security for event portfolios exists to stop that, and the mechanism is one filter on one dimension rather than a new model every time somebody asks.

The nine show problem

An exhibitions group with nine shows has a natural shape in the warehouse. One show dimension with nine rows. Fact tables for registrations, badge scans, booth contracts, exhibitor invoices and sponsorship, each carrying a show key. Five years of history on each show, so roughly forty five event instances hanging off the same nine rows.

Everybody who works there needs a subset of that. The group commercial director needs all nine. A show director needs one, plus the portfolio totals with no breakdown. A vertical lead needs three. The finance team needs all nine on revenue and none of the attendee detail. An exhibitor account manager needs the accounts on their patch across whichever shows those accounts buy into, which cuts across the show dimension entirely.

Copying the model for each of those shapes is the path teams walk by default, and it fails on maintenance. Nine models means nine copies of every measure. Change how contracted value handles a mid-term upgrade and the change has to land nine times, tested nine times, and one of them will be missed. Microsoft's report consumer security planning guidance (Microsoft Learn, 2026) puts the trade-off plainly: "It's typically better to create, test, and maintain one data model rather than multiple data models."

Filter the dimension and let the relationships do the rest

The design is smaller than the problem suggests. You do not filter five fact tables. You filter the show dimension, and the relationships push the filter outward.

A role holds one filter expression evaluated per row of the show dimension, returning true for rows the user may see. Rows returning true stay. Everything else disappears from the model as far as that user is concerned, and because registrations, scans, contracts, invoices and sponsorship all join to the show dimension on the show key, every one of them is filtered by the same single rule. A measure summing contracted value across all shows now sums it across the shows that survived the filter, with no change to the measure.

That property is what makes the approach scale. Adding a tenth show adds one row to the dimension and zero lines of filter logic. Adding a sixth fact table adds one relationship and zero lines of filter logic. The security surface stays one expression on one table however wide the model gets.

There is a cost worth naming before you meet it. Filters travel in one direction along relationships by default. If you have a genuine many to many between shows and something else, for instance an exhibitor account that spans several shows, and you switch the relationship to filter in both directions to make the security work, the Power BI documentation (Microsoft Learn, 2026) warns that bi-directional security filtering "can negatively impact query performance, especially in models with many relationships or large datasets". On a portfolio model with five years of scan data that warning is not theoretical. Design the star so the security filter runs one way if you possibly can.

Why does the sales director still see everything?

Here is the failure that wastes the most time, because the filter is correct and the outcome is wrong.

Row level security applies to people who can read the model. It is bypassed by anyone who can edit it. The Power BI documentation (Microsoft Learn, 2026) states it directly: "RLS only restricts data access for users with Viewer permissions. It doesn't apply to workspace Admin, Member, or Contributor roles." The implementation planning guidance goes further and spells out the permission table, where a user with read permission has the filter enforced and a user with write permission sees all data in the semantic model.

Now count your own audience. Of forty people with access to the portfolio model, suppose twelve were added to the workspace as contributors at some point, usually because somebody needed to subscribe a colleague to a report and contributor was the role that made the error message go away. Those twelve have edit rights, so the filter does nothing for them. That is 30 per cent of the audience seeing all nine shows while the security page shows a correctly configured role and everybody assumes the problem is solved.

The fix has nothing to do with the filter. It is a workspace membership change, and it belongs to workspace permissions for event teams. What matters here is knowing that a correct filter and a correct outcome are two different claims, and only the second one is worth anything.

Why do roles beat a list of named people?

The alternative that keeps getting proposed in these conversations is per-person access. Give each director the shows they own, one grant at a time, and skip the abstraction.

That approach has been understood as a poor fit for organisations of any size for over thirty years. Ferraiolo and Kuhn set out the case at the 15th National Computer Security Conference in 1992, arguing that "reliance on DAC as the principal method of access control is unfounded and inappropriate for many commercial and civilian government organizations", where DAC is the discretionary model in which the owner of a resource decides individually who may see it. Their alternative binds access to the role a person holds in the organisation and binds the person to the role separately.

In an event portfolio the argument is easy to feel. People move constantly. A show director takes a second show, a vertical lead covers a colleague's maternity leave, an account manager transfers between brands after an acquisition. Under per-person grants each of those is an audit of every report that person can reach. Under roles it is one membership change, and the question "who can see the hospitality show's rate card" has an answer you can read off a page instead of reconstructing.

Assigning people to a role through groups

Once the filter exists, somebody has to say who is in the role, and doing that by typing forty names into a security page is how the configuration rots.

Role membership takes groups, with a specific and slightly annoying set of exclusions. The Power BI documentation (Microsoft Learn, 2026) lists distribution groups, mail-enabled groups and Microsoft Entra security groups as supported, and states that "Microsoft 365 groups aren't supported and can't be added to any RLS roles." That exclusion catches teams out constantly, because the Microsoft 365 group is usually the one that already exists and already has the right people in it.

Two behaviours to hold in mind. Roles are additive: a user who belongs to two roles sees the union of what both allow. Put a vertical lead in a four show role for their vertical and a three show role for a project, with one show appearing in both, and they see six shows. Neither role author intended that and neither role is wrong. The other behaviour is the guest account. Where an external user is involved, the documentation recommends adding them to the role by email address directly instead of through a security group, because group membership for guest accounts is not always resolved the way you would expect.

What one model actually buys you

Put numbers on the maintenance argument, because that is where the decision gets made.

Nine models with five reports each is forty five report definitions. A measure change that takes twenty minutes per report including a check costs fifteen hours and produces at least one report where somebody forgot. One filtered model with five reports costs one hundred minutes for the same change, and there is nowhere for a stale copy to hide.

The second gain is the portfolio question. With nine models, "how many companies exhibited at more than one of our shows this year" requires a tenth model that unions the nine, at which point the security you built into each of the nine has to be rebuilt in the union. With one filtered model the question is a distinct count and the filter already applies.

Where this stops

Row level security restricts rows. It has nothing to say about columns, and the difference matters more in an event portfolio than in most businesses.

An operations lead may legitimately need every exhibitor row across all nine shows to plan the floor, and may have no business seeing what any of them paid. No row filter expresses that. The documentation is explicit that if a user can see a row, they can see every column on it, and hiding a column is a different mechanism entirely, covered in object level security.

The second limit is aggregate leakage. A user restricted to one show who can still see a portfolio total can often work backwards. Nine shows, a portfolio total of 4,182,000 in contracted value and their own show at 517,000 tells them the other eight sum to 3,665,000. Show them a portfolio total by vertical and the arithmetic gets sharper. Row filters do not stop inference from totals, and the answer is either removing the totals from that audience's report or setting a floor on group size before a figure is displayed at all.

Start this week with one query rather than a project. Pick your portfolio model, list everybody who has access, and put their workspace role next to their name. Count how many hold anything above viewer. That count is the number of people for whom the whole filtered model is currently decorative, and it is usually higher than the person who built the filter expects. The mapping between people and shows, and how to keep it from becoming forty roles, is the mapping table's job, and proving the filter actually works belongs to the test matrix.