The report that lies quietly

Two managers open the same dashboard and read different numbers, and nothing on the screen says so. The reporting layer trims rows to what each user is allowed to see, silently, at query time. The report is never wrong, exactly. It is quietly partial.

RuleMake report populations explicit: document what each role should see, and assert the counts so a trimmed result announces itself.

Neverdebug an empty report as a data problem first. In this layer, no data returned is usually a security answer wearing a data costume.

◆ The trim you cannot seesecurity applied at query time, invisibly.

The delivered reporting layer applies row-level security when the query runs. Every analysis is filtered to the rows the requesting user’s roles and data assignments allow, and the output carries no indicator that trimming happened. The same analysis returns different rows for different users, or no rows at all, and looks identical doing it.

The design is defensible: managers should see their own hierarchy and not their peers’. The silence is the problem. A number with an invisible filter on it reads as the number, and decisions get made on the partial view without anyone knowing a fuller one exists.

◆ How it presentsthe symptoms teams chase before finding the cause.

Symptom	What is actually happening
The report returns no data	The user’s roles grant no rows for that query. A security question, reported and chased as a data one.
Two managers disagree about one dashboard	Each sees only their own hierarchy. Both numbers are trimmed; neither screen says so.
Totals shrink after a role change	The data never moved. The person’s data assignments did, and every saved report quietly re-trimmed.
The analysis works for the author only	Built and tested under a broad role, consumed under narrow ones. The author sees the whole; everyone else sees a slice.

◆ The owned answerexplicit security, asserted populations, loud trimming.

In an owned warehouse the security model is a first-class artifact: written down, versioned, and testable. Each role maps to a documented population, and the tests assert the counts: this role sees this many cost centers, this many workers, this many invoices. When a report’s population deviates from the assertion, the pipeline fails loudly, before the number reaches a meeting.

The difference is not more security or less. It is the same trimming made explicit: a report can state which population it covers, and a viewer entitled to a subset sees that stated, not silently substituted. What people are entitled to see stays a policy decision. Whether anyone can tell what they are seeing stops being one.

Use case

Problem

Row-level security trims report results invisibly at query time, so identical analyses disagree between users, empty results carry no explanation, and shared dashboards quietly diverge.

What we build

A warehouse with an explicit, documented, testable security model: each role maps to an asserted population, with count checks run on every load.

What you get

Reports that state their population, security that is versioned and tested, and trimming that fails loudly instead of lying quietly.

Do your managers all see the same dashboard?

We build the security model that makes the answer provable.

Talk to us

Terms on this page

ERP: Enterprise resource planning, the system of record for operations and finance.
OTBI: Oracle Transaction Business Intelligence, the embedded reporting tool inside Fusion.
row-level security: Filtering query results to the rows a user is allowed to see.
role: A bundle of permissions assigned to a user, driving what queries return.
data assignment: The scoping that ties a role to particular organizations or sets of data.
hierarchy: The tree of who reports to whom. Managers see their own branch.
population: The full set of rows a report is meant to cover.
count check: An automated test asserting how many rows a role should see.