Who’s Officially Allowed to Build Reports at Your Organization? (And who’s building them anyway?)

The Headache

The finance department’s most valuable dashboard has been maintained for two years by an FP&A analyst named Sarah. She is not on the BI team. She is not officially authorized to build anything more sophisticated than a personal report. The dashboard emerged organically: she figured out how to build it on top of the certified Revenue model, discovered nobody was checking, and just kept going. Her work is good, so nobody stopped her. The CFO uses the dashboard every Monday morning and does not know who built it.

Sarah goes on parental leave. Three weeks in, the dashboard breaks. A measure name changed upstream and her Live Connection needs updating. Nobody knows how to fix it because nobody knows how it was built. The BI team gets pulled in, discovers a personal-workspace publication with custom M queries feeding a semantic model with measures that duplicate but subtly differ from the certified ones, and estimates six weeks to reverse-engineer the business logic. For six weeks, the CFO reverts to a spreadsheet. Sarah’s parental leave becomes the accidental audit that reveals your organization has been running critical financial reporting on an unofficial arrangement with a single point of failure.

The problem is not Sarah. Sarah is talented, motivated, and produced excellent work. The problem is that your organization has an informal build-rights arrangement that isn’t documented, isn’t repeatable, and depends entirely on the continuity of specific humans. When those humans are unavailable, the work becomes invisible and expensive. When the humans leave, it becomes catastrophic.

Season Two’s trust subseries (Issues Four and Five) closed with a stable, transparent platform that consumers actually trust. This issue asks the natural follow-up: once trust is stable, who is actually allowed to build on top of it? Not “who has permissions on paper.” Who has permission by design.

The Blueprint: Managed Self-Service as a Designed System

Managed self-service is not “we let people build.” It is a designed system with tiers, a written operating agreement, and an enablement model that moves people between tiers. Skip any one of the three and you get one of two failure modes: a locked-down platform that produces compliance without innovation, or an open platform that produces the Sarah scenario at scale.

1. The Build-Rights Ladder.

In our engagements we implement a four-tier model that maps cleanly to typical mid-market realities.

Level 1 is the Consumer. Can view certified reports. Cannot create anything. This is roughly 70-80% of a typical BI licensee base. If you are not sure whether someone should be above Level 1, they should not be.

Level 2 is the Personal Builder. Can build in a personal workspace. Cannot share broadly. Can Live-Connect to certified semantic models but cannot create their own. Sharing beyond a small named group requires an approval workflow, typically a lightweight Teams-based one that resolves within one business day. This is the most common tier for financial analysts, marketing analysts, and operations analysts.

Level 3 is the Team Builder. Can build shared reports in a designated Curated workspace within their domain. Reports built here can be shared with the entire domain without per-report approval. Cannot create semantic models. All reports must Live-Connect to certified models. This is where most mid-market power users belong, and where Sarah should have been operating officially.

Level 4 is the Model Builder. Can create semantic models in domain sandbox workspaces. Models are subject to a formal promotion process before certification (which is Issue Eight’s topic). This tier is a small named group, typically three to five people in a mid-market organization, including central BI team members and one or two embedded power users per domain.

2. The Build-Rights Operating Agreement.

The four tiers are a starting point, not the deliverable. The deliverable is a written agreement that specifies four things for each tier.

Who is at this tier. Named people, not role descriptions. “Marketing analysts” is not who is at Level 3. “Sarah Chen, David Park, and Aisha Kumar” is who is at Level 3. Ambiguity here is where the whole framework starts to unravel.

What they can build. The specific artifact types (reports, dataflows, notebooks, semantic models, paginated reports) each tier can produce.

What they can share. What sharing is automatic, what requires approval, what the approval SLA is. In our workshops we push clients to keep the SLA under one business day; anything longer creates the shadow-work incentive that produces underground Sarahs.

How to move up. The specific criteria for graduating between tiers, and this is where most operating agreements collapse in practice. The tiers exist on paper. The paths between them do not.

We insist the agreement is signed by the executive sponsor, the head of the BI team, and one representative from each domain with members above Level 1. If the agreement is a document without formal sponsorship, it will be ignored the first time someone influential wants to build outside their tier. That usually happens within eight weeks.

3. The Enablement Model.

Tiers create structure. The enablement model creates movement. Without a way to graduate between tiers, the system becomes rigid, ambitious analysts leave or go underground, and the organization loses talent it should have institutionalized.

The enablement model in our engagements has three components. A defined training curriculum for each tier transition. Level 2 to Level 3 requires demonstrated proficiency in Live Connection, visual design conventions, and the organization’s naming standards, typically a four to eight hour curriculum with a knowledge check. Level 3 to Level 4 requires demonstrated proficiency in semantic modeling, DAX, and performance considerations, typically a longer curriculum with a portfolio review. A mentorship pairing during transition, usually two to three months, where someone at the target tier reviews the candidate’s work and formally recommends graduation. A named recognition moment, because graduation that is quiet or ambiguous does not feel earned, and the incentive to pursue it weakens.

The question we get in every workshop is: “What do we do about the person who is already doing Level 4 work informally?” The answer is: formalize it, backdated to when they started. Do not punish informal excellence. Recognize it, and then use it as the visible example of how the enablement model can be used to institutionalize the analytical talent the organization already has.

The Gotcha:

The most common failure mode is having tiers on paper but no path between them. Analysts stay stuck at Level 2, get frustrated, either leave or go underground. Six months later the tiers feel arbitrary, resentment builds, and the whole framework loses credibility with the exact people it was designed to serve. We treat the enablement model as more important than the tier definitions themselves. Any operating agreement can define tiers. The ones that hold are the ones with visible, achievable graduation paths that people are actively moving through. If nobody in your organization has graduated between tiers in the last two quarters, the system is not working, regardless of how many documents exist.

The Reddit Reality Check

A recurring thread, paraphrased: an IT director asks how to handle business analysts who “insist on building their own reports” despite the existence of a central BI team. Community responses split between enforcement (“lock down the tenant”) and capitulation (“let them do what they want, they’ll cause less trouble”).

Both are wrong. The analysts who insist on building are often the most valuable analytical talent in the organization. Locking them down loses them. Letting them do anything produces the underground Sarah scenarios from the Headache. The move that works is a graduated model that gives them a legitimate path to build at increasing levels of scope, with commensurate accountability. Ambitious analysts do not want unlimited freedom. They want a clear path to earn more of it.

What We’re Watching

OneLake security custom roles at the lakehouse level are now generally available and are a real enabler for finer-grained build rights. Historically, workspace-level roles (Admin, Member, Contributor, Viewer) were the primary control, which meant a Contributor who could build reports could also potentially see all data in all items in the workspace. OneLake security roles let admins grant read permissions only to specific tables and folders, with role assignment either explicit or automatic based on workspace role.

For a build-rights operating agreement that wants to distinguish “can build reports on top of certified models” from “can see raw source data,” this closes a gap that used to require workspace proliferation as a workaround. If your current workspace structure is more granular than it needs to be because you were using workspace boundaries to enforce data-level access, this feature is your invitation to consolidate. Which will make Issue Three’s workspace architecture recommendations easier to hold.

---

One question for the comments:

Who is the most productive person at your organization whose build rights don’t officially exist? Don’t name names. Just think about how their work would survive if they left tomorrow.

---

The Strategist’s Corner

If reading through the four tiers made you realize your organization has an informal Sarah, you are in the majority. In fact, most mid-market organizations have several. We deliver the fix as a Build-Rights Operating Agreement Workshop: a structured half-day session with your BI team, executive sponsor, and one representative from each active domain, ending with the tier definitions populated with real names, the operating agreement drafted, the enablement curriculum outlined, and the graduation criteria documented before anyone leaves the room. The follow-on engagement implements the tier permissions in your Fabric tenant and runs the first graduation cohort within one quarter. Book a 30-minute scoping call →

Issue Seven moves into the territory that Level 4 builders inevitably enter. When a semantic model becomes critical to business decisions, it stops being a report and starts being a data product. Ownership, SLAs, versioning, and the product-owner role that most mid-market organizations still do not have but urgently need.

Measure Twice. #6: Originally Posted on LinkedIn, July 15, 2026