Balance data access with democratization
Self-service analytics and data governance are often treated as opposing priorities. Open access helps analysts move fast, while governance protects sensitive data and ensures compliance. Most organizations default to restriction, leaving analysts dependent on data teams.
Alation embeds governance in the access layer so analysts can discover and use data without tickets or delays, while policies, role-based controls, and audit trails run automatically. This ensures speed, trust, and compliance.
The problem with traditional data governance
The conventional governance approach restricts data access out of caution: locking down datasets until access is manually approved. The effect is the opposite of what governance intends: analysts who can't access governed data create shadow copies outside the governance perimeter, work from stale extracts, or simply make decisions without data. The risk doesn't disappear; it moves somewhere harder to see.
The alternative isn't ungoverned access. It's governance that works at the access layer — so analysts reach what they need, and data outside their permissions is protected without generating friction.
How Alation structures governed access
Access control in Alation isn't an afterthought; it's built into every object in the catalog. Whether you're working with data products, tables, schemas, or other catalog assets, you can configure precisely who sees what, at exactly the right level of granularity, directly in the product.
For data products specifically, Alation organizes access across three independently configurable levels:
App level: Server Admins control system-wide Data Products App settings and who can create Marketplaces and data products across the entire instance.
Marketplace level: Marketplace Admins control what's visible within a specific Marketplace, who can publish products, and who can view them. A Marketplace can be set to public (anyone can browse) or private (only assigned users).
Data product level: Individual data product owners control who can view or edit each product, regardless of their Marketplace role.
Each level uses a defined role hierarchy. A user holds one role per scope (App, Marketplace, and data product), and higher-level roles inherit the permissions below them.
Beyond data products, catalog objects — including tables, schemas, and other assets — carry their own access controls. Any object can be marked public or private, and access can be granted to individual users or groups at whatever level of granularity your organization requires.
The result: access decisions across your entire data catalog are precise, auditable, and easy to manage — without rebuilding permissions from scratch for every new user or team.
Outcome-based governance: Automate access at scale
Most governance in Alation requires no intervention after initial configuration. Permissions are applied automatically based on the roles and privacy settings already in place.
This is outcome-based governance in practice. Teams define what good looks like — which data is sensitive, who should access what, what standards must hold — and Alation operationalizes those decisions automatically. There's no manual follow-through required on every asset or every access event.
Access scoped to declared roles — When a data source, schema, or table is configured as private, that intent is enforced at the access layer. Users outside the defined scope cannot view or interact with the protected object. Governance limits exposure; it doesn't generate friction.
Sensitive data standards, continuously applied — When a column is classified as sensitive, that classification carries forward automatically: values are excluded from data samples for users outside the permitted tier. The context remains visible; the data does not.
Credential-enforced data access — With Dynamic Sampling enabled, analysts must authenticate with their own database credentials before profiling a table. They see exactly what their own permissions allow — not a shared service account view.
Protected view SQL — When Obfuscate Literals is enabled on a data source, literal values in view SQL — strings, numbers, dates — are replaced with placeholder variables on catalog pages. The query author sees the original; all other users see
, . Tableau permissions reflected in the catalog — For organizations using Tableau, Permission Mirroring ensures that users see only the Tableau objects in Alation's catalog that they have permission to view in Tableau. Governance doesn't need to be maintained separately in each system.
When steward approval is required
For data that sits outside an analyst's current access tier, Alation replaces the IT ticket with a structured self-service request.
When a data product is configured to require access approval, analysts can submit a request directly from the product's page in the Marketplace. They submit the request; the data product owner or Marketplace Admin reviews and approves or denies it. Approved access takes effect immediately. Every request and decision is logged in the audit trail.
This keeps governance teams as the decision-makers on sensitive data — without making them the operational bottleneck for every access event.
Governance that travels across your data stack
Analysts shouldn't have to leave their tools to understand whether data is trustworthy or policy-compliant. Through Alation Anywhere, governance context — trust flags, descriptions, and endorsements — surfaces directly inside Tableau, Slack, Microsoft Teams, and Google Chrome.
For organizations where analysts spend most of their time in BI tools, this means governance information is present at the moment a decision is made — not retrievable only in a separate catalog interface.
Built for large, distributed data estates
Governance complexity scales with organizational complexity. Alation's 120+ native connectors apply consistent access controls, stewardship assignments, trust flags, and lineage tracking across Snowflake, Databricks, legacy on-premises systems, and cloud data lakes — without requiring separate governance configurations per platform.
Roles and permissions can be assigned to groups rather than individuals, so governance administration scales as teams grow. In Alation Cloud Service, schema-level and table-level access settings can be configured independently of the parent data source — a table in a public schema can be marked private without changing the broader source's settings.