Glossary
What is governed self-service data access?
Governed self-service data access is a pattern where business users reach enterprise data directly, without writing queries or waiting on IT, while access rules, business definitions, and audit trails are enforced by the platform serving the data. The self-service part means the user picks an operation and runs it. The governed part means the rules around that operation are not optional.
The distinction that matters is between self-service BI and governed self-service for data access. Self-service BI tools like Power BI and Tableau put dashboards in the hands of business users. Governed self-service for data access sits one layer down: it governs how the BI tool, the AI agent, and the partner API all reach the underlying data through one shared path.
Why self-service alone is not enough
Most enterprises already practice self-service. Excel exports run from CRM into a shared folder. Ungoverned BI workspaces let analysts build their own datasets. Departmental "data marts" hold copies of production data with definitions that drift over time. People get answers; the question is what those answers cost.
Two costs recur. The first is the cross-department-consistency problem: when every department maintains its own copy of the data with its own definitions, Sales, Marketing, and Finance report different numbers for the same metric. Leadership cannot tell which is right.
The second is the audit problem. When data leaves the system into Excel files, into personal BI workspaces, into copies that nobody tracks, there is no log of who saw what. For any data subject to compliance, the gap is no longer a convenience problem; it is a defensibility problem.
What governed self-service requires
Three properties move the pattern from convenient to defensible.
Pre-defined operations with typed parameters
The user picks an operation IT has approved and supplies parameters. No hand-written SQL, no runtime query generation. The business logic is fixed; only the parameters change.
Role-based access enforced at the layer
Who can call which operation and which rows they see are decided once, in the access layer. The same rules apply whether the user is in BI, in a Power App, or in an AI assistant.
Audit and lineage automatic
Every call is logged with who asked, which operation, which parameters, and what came back. The log is a property of the platform, not something each consumer has to build.
The access-layer-below-BI distinction
Self-service BI tools are visualization. They turn a dataset into a dashboard a user can read. They are excellent at what they do, and they keep doing it.
Governed self-service is the access layer below the BI tool. It governs what data the BI tool reads in the first place, applies the access rules and metric definitions once, and serves the same governed operations to other consumers: the AI agent answering a sales question, the partner API reading a customer's own data, the Power App showing a record to a service rep.
The BI tool, the AI agent, and the partner API all see the same definition of "active customer" because they all read it from the same place. The user does not pick which definition to trust; there is only one.
How dhino delivers governed self-service
dhino Fetch is governed self-service for data access. IT defines templates that carry the operation, its access rules, and its business definitions. Business users pick a template, supply parameters, and get the result. The marketing segmentation scenario walks through this end to end.
For a longer treatment of the pattern, see how to build governed data segments without waiting on IT.
Give your business users a governed path
Tell us where self-service is leaking today: Excel exports, drifting BI definitions, ungoverned data marts. We will show you what a governed access layer changes.