SAP veterans know the pattern: unclear responsibility costs double later.

Anyone who has managed an SAP landscape knows the problem: unclear responsibilities lead to chaos in the authorization concept, security gaps, or operational friction. This exact pattern repeats itself in modern analytics platforms – just faster and with greater impact. Databricks Unity Catalog is a powerful tool for governance, security, and central data management. But without a clean clarification of the Unity Catalog admin hierarchy before the first click, problems arise that can only be corrected later with significant effort.

This article is aimed at platform engineers, analytics architects, and SAP-experienced data owners who want to set up Unity Catalog in a structured way. You'll learn what roles exist, how storage credentials and external locations work, and get a hands-on guide for your first setup – including concrete code snippets and a downloadable checklist.

---

Why the Unity Catalog admin hierarchy should be clarified before the first click

Unity Catalog is far more than a classic data catalog. It's the central governance layer for your entire Databricks platform – across workspaces, clouds, and data sources. Starting without a clear distribution of roles puts you at risk of:

• Permission chaos: If it's unclear who manages catalogs, schemas, or external locations, ad hoc permissions emerge that are hard to trace later.
• Security gaps: Storage credentials and external locations without central control open the door to uncontrolled data access.
• Operational inefficiency: Missing responsibilities lead to back-and-forth questions, delays, and coordination loops – exactly what a modern platform is supposed to avoid.

SAP-experienced teams know this from practice: a clean separation between central administration, platform operations, and business-unit responsibility is the foundation for stable, scalable systems. The same is true for Unity Catalog. Databricks' metastore admin role and its distinction from account and workspace admins must be clearly defined from the start.

---

Role matrix: Account admin, metastore admin, workspace admin

Unity Catalog has three central administration roles, each covering different areas of responsibility. The overview below shows who does what – and where typical misunderstandings lurk:

Account admin

• Scope of responsibility: The entire Databricks account level
• Typical tasks: Managing workspaces, users, groups, metastores; assigning metastores to workspaces; billing and account settings
• Business or technical? Technical-organizational (IT leadership, platform ownership)
• Common mistake: The account admin also takes on operational metastore management – this leads to bottlenecks and a lack of delegation

Metastore admin

• Scope of responsibility: A specific metastore (central governance unit)
• Typical tasks: Managing catalogs, schemas, storage credentials, and external locations; permissions at the metastore level; governance rules
• Business or technical? Technical-business hybrid (data governance lead, platform engineer)
• Common mistake: No metastore admin is explicitly assigned – responsibility then remains unclear or defaults to the account admin

Workspace admin

• Scope of responsibility: A single workspace
• Typical tasks: Managing workspace users, clusters, jobs, notebooks; integrating catalogs into the workspace; local permissions
• Business or technical? Technical-operational (team lead, data engineer)
• Common mistake: The workspace admin tries to create catalogs or external locations – this doesn't work without metastore admin rights

SAP comparison: Central vs. decentralized

In SAP systems, you're familiar with the separation between basis administration (technical platform), authorization administration (central security), and business-unit responsibility (operational use). Unity Catalog follows a similar pattern:

• Account admin = SAP basis + license management
• Metastore admin = authorization administrator + data steward
• Workspace admin = business-unit IT or team lead

This analogy helps you understand the roles intuitively and keep responsibilities cleanly separated.

---

Storage credentials & external locations

A central building block of the admin hierarchy is the management of storage credentials and external locations. Without these two components, you can't securely integrate external data – and this is exactly where the first pitfalls typically appear.

What are storage credentials?

Storage credentials are the access details Databricks uses to reach external cloud storage, for example Azure Data Lake, AWS S3, or Google Cloud Storage. They are stored centrally in the metastore and form the basis for all external locations.

Important: storage credentials are managed exclusively by the metastore admin. Workspace admins have no access at this level.

What are external locations?

External locations are named paths to external storage locations that are based on storage credentials. They define where data physically resides – and who is allowed to access it.

Example:

• Storage credential: azuredatalakecred
• External location: abfss://raw-data@storageaccount.dfs.core.windows.net/sap-exports/

External locations allow permissions to be controlled granularly: not every user needs access to the entire storage, only to defined areas.

Why is this critical for governance?

Without clean management of storage credentials and external locations, you get:

• Sprawling, uncontrolled storage access
• Unclear data ownership
• Security risks from uncontrolled credential usage
• Difficulties during audits and compliance reviews

SAP comparison: think of RFC connections in SAP. Here too, you centrally define which systems are allowed to communicate with each other – not every developer creates their own connections.

Practical checklist: Preparing storage

Before you create your first catalog, the following points should be clarified:

• Storage strategy defined: Where does SAP data live, where does non-SAP data live? Which areas are "managed," which are "external"?
• Credential ownership clarified: Who manages storage credentials? This should sit with the metastore admin.
• Naming conventions established: Consistent naming for credentials and locations makes operations easier.
• Permission model sketched out: Who is allowed to access which external locations?
• Documentation in place: Storage paths, credentials, and mappings should be documented centrally.

---

First setup: Creating a catalog, schema, and managed table

Now it gets practical. You've clarified your roles and prepared storage credentials and external locations – time for the first setup.

Step 1: Create a catalog

A catalog is the top organizational level in Unity Catalog. It groups schemas and tables and defines permissions at a high level.

-- Create catalog (as metastore admin)
CREATE CATALOG IF NOT EXISTS sapanalytics
COMMENT 'Catalog for SAP and non-SAP data';

Note: only the metastore admin can create catalogs. Workspace admins can use existing catalogs, but cannot create new ones.

Step 2: Create a schema

Schemas structure the data within a catalog – comparable to database schemas in classic systems.

-- Create schema
CREATE SCHEMA IF NOT EXISTS sapanalytics.finance
COMMENT 'Schema for financial data from SAP and external sources';

Step 3: Create a managed table

Managed tables are fully managed by Databricks – including storage and lifecycle.

-- Create managed table
CREATE TABLE IF NOT EXISTS sapanalytics.finance.costcenters (
  costcenterid STRING,
  costcentername STRING,
  department STRING,
  createdat TIMESTAMP
)
COMMENT 'Cost centers from SAP';

Important: for managed tables, Databricks automatically determines the storage location. You don't need to worry about storage credentials or external locations.

SAP comparison: Transport system and namespaces

In SAP, you're familiar with namespaces and transport routes for organizing objects in a structured way. Catalogs and schemas in Unity Catalog serve a similar function: they create order, enable permission separation, and simplify operations.

---

Managed vs. external tables from an SAP batch perspective

One of the most common questions during setup: when do I use managed tables, and when external tables? For SAP-experienced teams, this is easy to explain through the lens of data provisioning.

Managed tables: Platform-managed data storage

Managed tables are fully managed by Databricks. This means:

• Databricks determines the storage location within metastore storage.
• Databricks manages the lifecycle, for example automatic deletion on DROP TABLE.
• Databricks handles governance and optimization, such as Delta Lake features.

When does this make sense?

• Data created and processed within the platform
• Transformed data that doesn't need to be shared externally
• Data where Databricks should hold ownership

SAP comparison: managed tables are like SAP-internal tables that live within the SAP schema and are managed by the SAP system. They're part of the controlled data estate.

External tables: Connected, externally owned data storage

External tables point to data that lives outside Databricks – for example in an Azure Data Lake or S3 bucket. This means:

• The storage location is explicitly defined via an external location.
• Databricks reads the data but doesn't manage it.
• On DROP TABLE, only the metadata is deleted – the data remains intact.

When does this make sense?

• SAP exports used by other systems
• Data that is externally managed and archived
• Data where ownership sits outside Databricks

SAP comparison: external tables are like external data sources connected via RFC or an interface. SAP uses the data but isn't responsible for its lifecycle.

Decision guide: Managed or external?

• Managed: When Databricks should hold data ownership and you want full governance control
• External: When data is managed externally or used by multiple systems

Tip: many teams start with external tables for SAP exports and use managed tables for transformed, platform-internal data. This creates clear responsibilities and simplifies operations.

---

Practical checklist for a clean setup

Before going into production, tick off the following points:

• Roles clarified: account admin, metastore admin, and workspace admins are named and briefed
• Metastore ownership defined: who is responsible for catalogs, schemas, and governance?
• Storage paths documented: all external locations and storage credentials are recorded centrally
• Credential strategy agreed: who is allowed to create and manage storage credentials?
• Naming conventions defined: consistent naming for catalogs, schemas, tables, credentials, and locations
• First catalog/schema cleanly created: a test setup has been carried out and documented
• Managed-vs.-external decision made deliberately: for every data area, it's clear which variant is used
• Permission model sketched out: who is allowed to access which catalogs, schemas, and tables?

Would you like this checklist as a handy PDF? Download our Unity Catalog setup checklist and use it as a template for your team.

Want to set up your Unity Catalog professionally from the start? Download our setup checklist or get in touch – we'd be happy to guide you toward a fact-based, future-proof analytics platform.