Atlan for SAP: Ground Your Agents in the System of Record

● Generally Available

This release turns SAP's notoriously opaque data into a governed, machine-readable context layer for AI. SAP is the system of record for most large enterprises — and the hardest source to ground agents in, thanks to cryptic tables, coded field names, and configuration-driven logic. SAP ECC and SAP S/4HANA are now GA with two new capabilities that give agents (and the people who supervise them) two things they've never had over SAP: provenance — where a number truly comes from — and a map of the human layer, where SAP data is actually created and consumed.

CDS View Column-Level Lineage

Provenance

What's new: Column-level lineage is now generally available for SAP CDS (Core Data Services) views. Trace every column in a CDS view back through its transformations to the exact source table columns that feed it.

What you can do:

• Follow a single field end to end, from the semantic CDS layer down to the underlying SAP table columns.
• Run precise impact analysis — see exactly what breaks downstream if a source field changes.
• Debug and validate at the column, not just the object, level.

Why it matters for agents: This is the provenance backbone of the context layer. When an AI agent surfaces a metric, it can cite the precise origin and transformation path of every value — making the output auditable and trustworthy, and letting governance and quality signals propagate accurately across the SAP estate.

Fiori Apps as a New Asset Type

The Human Layer · First to market for Atlan

What's new: SAP Fiori apps are now a native asset type in Atlan, with asset-level lineage from Fiori apps → CDS views → upstream SAP tables.

The problem this solves: Fiori is the modern SAP UI — where business users actually work, reading, entering, and changing data every day, with near-zero visibility into the data beneath the screen. This release connects the app the user sees to the data it actually touches.

What you can do:

• See, for any Fiori app, the chain of CDS views and source tables it draws from.
• Give business users and stewards a clear map from the interface to the underlying data.
• Trace where sensitive or business-critical data is exposed and modified at the point of use.

Why it matters for agents: Fiori is the human layer of the context graph — where data is created and consumed. Mapping it lets an AI agent understand what an app does in data terms, and lets governance follow data all the way to the screen.

On the roadmap: column-level lineage for Fiori apps · popularity & usage signals for Fiori apps.

What's Next

Next: SAP Business Data Cloud (BDC). Zero-copy data sharing across Snowflake, SAP Databricks, Google BigQuery, and Microsoft Fabric. Context that follows your data across platforms without ever moving or duplicating it — so lineage, meaning, and governance stay intact wherever SAP data is consumed. Connectors for SAP Datasphere and SAP Analytics cloud, complementing our ERP and BW connectors.

More context ingestion from the SAP ecosystem, coming soon:

• Field-level help text as glossaries — SAP's own field documentation, automatically converted into governed business glossary terms and linked to the exact columns they define. The semantic layer that gives agents authoritative meaning for every SAP field.
• Master data as data products — your unique SAP configuration, packaged into governed data products: material types, customer and vendor account groups, and Business Partner groupings, roles, and categories. Context that reflects how your enterprise actually classifies its master data.
• SAP long text as knowledge files — SAP's free-text long texts (notes, descriptions, and documentation) harvested and published as knowledge files, ready to ground agents — for retrieval in agent studios and RAG workflows.

Beyond that — context from across the SAP application landscape (actively working with customers on outcomes and use cases for the below):

• SAP Signavio — business process context (how work actually flows).
• LeanIX — enterprise architecture and application portfolio context.
• SAP IBP — integrated business planning and supply chain context.
• SAP Concur — travel, expense, and spend context.
• SAP SuccessFactors — people and HR context.

The Bigger Picture: SAP + the Leading Non-SAP Context Layer

Pair the deepest context layer for SAP with the leading context layer for everything outside it — cloud warehouses, lakehouses, BI, transformation, and AI tooling — and the whole enterprise becomes legible to AI in ways neither side can deliver alone. An agent can trace a metric from a BI dashboard, through the cloud warehouse, across a zero-copy SAP share, into the CDS view and its source table — with provenance at every hop.

The estate is opening. The connective tissue is here. The result is a single, trustworthy map of how the business really runs — and the foundation for enterprise AI you can actually rely on.

🎉 What's new

Snowflake semantic views are now cataloged directly into Atlan as an open context layer home for the metric definitions that Cortex Analyst, Talk-to-Data and more agents depend on.

Atlan ingests the full hierarchy: the semantic view plus its logical tables, dimensions, facts, and metrics as discoverable, governable assets.

Because these views are the same objects Cortex Analyst runs on, cataloging them closes the gap between your governed metric definitions and the agents querying them.

And Atlan Context Studio lets you build and deploy new agents and semantic views from Atlan with the context they for agents that return accurate, governed answers

✨ Let's dig deeper

Here's what this looks like in practice and how it connects to Context Studio.

• Search for any semantic view and open its asset profile to see its logical tables, dimensions, facts, and metrics in one place.
• Feed these cataloged views directly into Context Studio, where they act as the primary execution surface. Context Studio either attaches to an existing semantic view or generates and updates its definition, with Atlan staying the source of truth.
• Apply the same governance you use elsewhere, like certification, ownership, README, and tags, to make a view trusted before it powers a production agent.
• Note: if your crawler role lacks the required grants, semantic views are skipped without failing the workflow, so an existing crawl won't break.

👏 Give it a shot

To start using semantic views:

1. Check the Snowflake permissions on your Atlan<>Snowflake connection
2. Run or schedule a metadata sync for your Snowflake connection.
3. Use global search and filter by asset type → Semantic view.
4. Open a semantic view to explore its Entities, Relationships, and Metrics tabs.
5. From there, point a Context Studio context product at the view to power an AI analyst.

📘 Full setup guide here. 

Finally, if you are at Snowflake Summit this week, come say hello and learn more about Snowflake+Atlan together!

🎉 What's new

Introducing Knowledge Folders and Knowledge Files to close the gap between your structured data context and the procedural knowledge that actually governs how your business works.

Before this, your SOPs, policies, and compliance docs lived scattered across SharePoint, Confluence, and Google Drive, invisible to agents at the point of use. 

Now you can upload the definitive versions directly into Atlan as governed, first-class catalog assets. 

A Knowledge Folder is a domain-scoped container (e.g., "Finance SOPs"). 

A Knowledge File is the individual document inside it. 

Context agents process each file automatically, extracting glossary terms, attaching business rules, and generating skill files with full lineage back to the source. 

That output flows into Context Repos via Context Engineering Studio, making your unstructured knowledge available to your MCP-connected agents, Atlan's native conversational search, and anything you deploy downstream.

Consider a customer support agent. It knows the order schema, the churn model, the interaction history. But it guesses when a VIP customer asks about a refund outside standard policy because none of the escalation path, the tier-specific SLA, the product defect window live in a database. They live in a PDF or shared doc.

Upload that PDF as a Knowledge File. Context agents extract the rules and make them available downstream. Now the answer is grounded and cites the source.

✨ Let's dig deeper

• Upload once, governed forever: Drag and drop your PDF or Markdown files into a Knowledge Folder. They become searchable catalog assets with lineage, metadata, and access control.
• Context agents extract automatically: After upload, context agents process knowledge files and synthesize glossary terms, business rules, and skills. Everything traces back to the source document.
• Flows into your Context Repos: Extracted knowledge becomes available via Context Engineering Studio. It feeds your Context Repos, conversational search, and any MCP-connected agent downstream.
• You decide what governs agent behavior: You choose which document is the definitive version. Nothing governs agents without your sign-off.

👏 Give it a shot

If your team has SOPs, policy docs, or compliance guidelines that your AI agents should know about, this is where to start.

Click + New > Knowledge Folder from the top right of Atlan. Create or select a folder, drag and drop your PDF or Markdown files, and upload. Open any file's profile page to preview content, review extracted terms, and trace lineage to downstream skill files and context repos.

Admin access is required to upload; all roles can preview and search

See more at Knowledge Folders | Context Engineering Studio

🎉 What's new

If you use AWS, your AI/ML teams may be building together in AWS SageMaker Unified Studio. And your context layer lives in Atlan.

As of today, those two are the same thing.

The AWS SageMaker Unified Studio (SMUS) connector is now generally available - built jointly with the AWS team. Every published asset, data product, project, and glossary term from SMUS now flows into the Atlan Context Layer, and the context you govern in Atlan flows back into SMUS automatically. Business stewards and AI/ML teams work on the same governed context, without leaving the tools they already use.

This is what it looks like when a hyperscaler builds natively on the Context Layer for AI.

✨ Let's dig deeper

🔁 Context flows both directions - not just into Atlan Crawl SMUS domains, data products, projects, published & subscribed assets, glossaries, terms, and key column metadata into Atlan. Reverse-sync descriptions you enrich in Atlan back to SMUS projects, published assets, and columns — so the governed context your data stewards define surfaces automatically in the workspace where your AI/ML teams build.

🔗 See how data products are reused across teams Lineage from any published asset surfaces every project that subscribes to it. Cross-team dependencies that were previously invisible become discoverable in a single view, making impact analysis and reuse decisions far easier.

🧭 Fits the domain model you already operate Attach SMUS projects and assets to your existing Atlan Data Domains. No parallel taxonomy, no duplicate ownership, no forced rework of how your business is organized.

🛡️ Enterprise-ready out of the box IAM-based authentication, a supplied CloudFormation template, preflight checks, and on-demand or scheduled crawls — built for production from day one.

🚀 Give it a shot

Setup is self-serve and most teams are connected in a single session.

In Atlan, head to New Workflow → AWS SageMaker Unified Studio. 

Deploy the supplied CloudFormation template in your AWS account, paste the IAM role ARN into Atlan, run the preflight check, and trigger your first crawl!

For more information, see

• 📘 Connector documentation for setup, supported assets, and reverse-sync configuration
•  📝 Joint AWS + Atlan blog for architecture and design rationale

Why Atlan + AWS:
SageMaker Unified Studio gives your AI/ML teams the workspace. Atlan gives them the context that makes the work trustworthy.

The definitions that drift, the lineage that goes untracked, the governance that gets bypassed — that gap is where AI projects lose credibility before they reach production. With SMUS as a first-class citizen in the Atlan Context Layer, the governed context your stewards maintain is the same context your AI/ML teams build on. It doesn't drift, because it only lives in one place.

Atlan is not just another connector in your AWS stack. SMUS connects to Atlan because the Context Layer for AI is where enterprise context compounds — and compounded context is what makes AI work at scale.

Have setup questions or want to talk through scoping? Reach out to your Atlan CSM or Account Manager. For product-related questions, you can also reach out to Bindu Neeharika at bindu.reddy@atlan.com to help you get from CloudFormation template to your first crawl ⚡

Your AI agents are only as smart as the context they can reach.

Over the last few months, Atlan MCP has matured into the production bridge between your governed context layer and every AI tool your team uses, and is already powering AI analysts, internal GPTs, and Cursor workflows with early adopters.

🎉 Your context, natively in more tools

Atlan MCP now ships native in Claude (Desktop, Web, Code), ChatGPT, Cursor, Windsurf, VS Code, n8n, Microsoft Copilot Studio, Glean, and Databricks. Connect once with OAuth or API key. No local install, no replicated setup.

Meanwhile, inside Atlan's UI, Conversational AI is now Generally Available!

✨Remote MCP, production-ready

Hosted per-tenant at https://mcp.atlan.com/mcp.

🔧 A deeper toolbox — 28+ tools and growing every day

- Read: semantic search, column-level lineage, SQL on connected sources, docs with citations
- Write: descriptions, owners, tags, certificates, custom metadata
- Create: glossaries, terms, domains, data products, DQ rules
- Govern: archive, restore, purge; schedule and update DQ rules

📝 Policy-aware by default

New partner integrations such as with Cyera (classification) and Immuta (enforcement) mean sensitivity and access rules can travel with every agent query.

Every agent reads from the same governed context layer. One shared brain. Context stays yours.

🚀 Give it a shot!

Explore the MCP docs

🎉 What’s new

Conversational AI in Atlan lets everyone explore their data estate in plain language instead of hunting through filters and asset pages. Ask questions like “What powers our revenue dashboard?”, “How do we define active customer?”, or “Who owns this table?” and get grounded answers with lineage, glossary, ownership, and quality signals surfaced for you — inside Atlan, your data tools, and collaboration apps.

✨ Let’s dig deeper

Find and understand assets in natural language  

Search across tables, columns, dashboards, schemas, and glossaries by describing what you’re looking for, not its exact name. Conversational AI returns the most relevant assets plus key context like descriptions, usage, and tags.

Trace lineage and assess impact without leaving chat  

Ask “What feeds this dashboard?” or “What breaks if I change this column?” to see upstream sources, downstream consumers, and critical dependencies before you make changes.

Summarize definitions, docs, and signals in one place  

Get quick explanations of metrics and business terms, along with summaries of table readmes, column definitions, and data quality or freshness signals so you can decide if a dataset is safe to use.

Find owners and subject-matter experts instantly  

Use ownership metadata to identify who’s responsible for a table, dashboard, or term, so you know exactly who to tap when you need deeper context or approvals.

Use it where you already work  

Start a conversation from the Atlan homepage or Copilot on any asset page, use the browser extension in tools like Snowflake and Databricks, or ask questions directly from Slack or Microsoft Teams once they’re connected.

Stay in conversation, with answers you can verify  

Refine results with follow-up questions; Conversational AI remembers context within the session. Every answer comes with citations that link back to source assets in Atlan so you can quickly inspect and trust what you see.

 👏 Give it a shot

Configure it in Labs: Conversational AI is being rolled out in phases. Once it has been rolled out to your tenant, users can start using it right away. If you’re an admin, you’ll also see the Conversational AI option in Admin settings → Labs → Atlan AI, where you can configure its behavior and add custom instructions.

Ask your first questions: Open Chat from the Atlan homepage to search across your catalog, or use Copilot on any asset page to ask context-aware questions scoped to that asset.

Use it where your team already works: After Slack or Microsoft Teams is integrated with Atlan, you can ask questions directly in those tools too.

Start with something simple like “Show me trusted tables for MAU”, “How do we calculate ARR?”, or “What’s upstream of the customer 360 view?” — and let Conversational AI handle the rest.

🎉 What’s new

The Atlan Lakehouse is the context store underneath your AI agents — the open, Iceberg-native layer where your enterprise's context lives, gets governed, and ships to any agent platform.

We're excited to announce that Atlan Lakehouse is now generally available – the foundation of the Context Layer for AI, enabled by default for all Atlan tenants. You can run SQL queries, create dashboards, and build AI applications directly on your Atlan context, using any Iceberg REST–compatible client, without managing separate pipelines or exports.

✨ Let’s dig deeper

• Make your context queryable by anyone — not just Atlan users. Connect Lakehouse to your existing BI tools – Tableau, Power BI, Looker – and build governance scorecards, domain coverage heatmaps, and enrichment dashboards that update automatically as your catalog changes. No manual data maintenance, no exports, no staleness: the people who need to see governance progress can see it in the tools they already use.
• Decommission your extraction pipelines – your context layer is already running. Teams that previously built custom pipelines on top of Atlan APIs – with multiple components, failure points, and API rate-limit concerns – have migrated to Lakehouse and decommissioned those pipelines entirely. Instead of engineering a context layer from scratch, you get a stable, always-current store you can query directly.
• Score your assets for AI-readiness, in a single query. Lakehouse combines asset-level context — enrichment coverage, data quality scores, certifications, lineage — with Atlan's own usage signals: which users are active, which assets are being queried, which features are driving adoption. Teams have used this to score assets for AI-readiness, track governance progress over time, and understand whether the context their teams are creating is actually being used — all in a single query layer, without stitching together separate exports.

👏 Give it a shot

• Connect to the Atlan Lakehouse from your preferred Iceberg REST–compatible client, explore the context that resides in the Lakehouse, and run a few starter queries (e.g., counting assets by connector, surfacing verified assets, or listing active users).
• Plug Lakehouse into your existing reporting or AI stack – connect your BI tool to build context dashboards, or wire it into your AI agents so they can reason over your catalog, governance, and usage data using SQL instead of custom integrations.

Lakehouse is the foundation. Over the coming weeks, work with your Atlan team and look for more updates here on how Context Engineering Studio, Conversational AI, and MCP connect to it – so you have a full picture of what the Context Layer for AI looks like end to end.

Check out the documentation for more:

• Atlan Lakehouse overview
• Enable agents to query the Atlan Lakehouse using the /atlan-lakehouse agent skill

🎉 What’s new

The Atlan Lakehouse makes all of your Atlan context available through an open, Iceberg REST–compatible catalog so you can easily build AI applications and drive analytical reports on your data estate. Today, it stores detailed metadata about all assets across your data estate, as well as usage analytics data on how users interact with Atlan.

We're excited to announce a new gold namespace in the Atlan Lakehouse – a curated namespace in the Lakehouse catalog that consists of standardized, refined tables that make it easier than ever to build AI apps and reports on asset metadata.

✨ Let’s dig deeper

• The Lakehouse namespace that contains asset metadata today (entity_metadata) is effectively a bronze layer for Atlan metadata: comprehensive and highly detailed, but harder to work with when you just want to analyze asset metadata.
• The new catalog-native gold namespace gives you a small set of refined, analytics-ready tables with just the fields you need, making it much easier to build AI apps and reports on asset metadata.
• The entity_metadata namespace remains the raw, bronze source of truth for catalog metadata, while the gold namespace is the curated consumption tier you use for reporting, dashboards, and AI.
• The gold namespace follows a star schema design, with:
  • A core assets table (fact table) that lists every asset in the data estate along with common attributes like name, type, status, owners, and certification, and
  • Complementary domain-specific tables (dimension tables) that contain detailed columns for specific areas such as data quality, data products, and glossary analytics.

👏 Give it a shot

Make sure the Atlan Lakehouse is enabled in your workspace, and then connect to it from your preferred Iceberg REST–compatible client. You'll be able to see a new gold namespace alongside the existing namespaces in the catalog!

Check out the documentation for more:

• Atlan Lakehouse overview
• gold namespace reference
• Best practices for querying the gold namespace efficiently
• Enable agents to query the Atlan Lakehouse using the /atlan-lakehouse agent skill

Note: Ensure your users can view and select from the tables in the gold namespace by granting them the correct platform-native RBAC permissions.

🎉 What’s new

As a data leader, you'll want to understand how your teams are adopting and using Atlan.

We've added a new usage_analytics namespace/schema to Atlan Lakehouse that exposes product telemetry captured from Atlan’s UI – every page view, user action, and identity snapshot – so you can understand how your teams interact with Atlan and measure adoption, engagement, retention and beyond.

Previously, you had to rely on custom charts and exports to understand who was active, which features were used, and how engagement changed over time. Now, curated product usage tables live directly in your Lakehouse, so you can analyze product usage using the same SQL and tools you already use and trust.

✨ Let’s dig deeper

In practice, this means you can turn raw Atlan activity into clear, visual insights about how your teams work with data:

• Track active users over time by workspace, role, or team so you can see whether onboarding and enablement actually stick.
• Understand feature adoption by looking at which core workflows (like search, lineage, glossary, or queries) are used most, and where usage drops off.
• Monitor engagement patterns (daily, weekly, monthly activity) to spot healthy teams, identify dormant groups, and time interventions before adoption slips.
• Build retention views that show how frequently users come back after their first week or month, and which behaviors correlate with long-term value.
• Join usage analytics with your own business data (for example, teams, departments, or customers) so you can see which parts of the organization get the most value from Atlan.

Because everything lives in your Lakehouse, you can plug these tables into your favorite compute platform or data visualization tool, so you can build reports and AI applications to understand how Atlan usage evolves across teams, features, and time.

👏 Give it a shot

You can start exploring usage analytics data for your Atlan tenant today:

• First, make sure Lakehouse is enabled for your Atlan tenant
• In your Lakehouse environment, look for the usage_analytics namespace/schema alongside your existing Atlan metadata schemas
  • Use your preferred compute platform to run SQL queries against the usage_analytics tables to inspect active users, features, or time ranges
  • Connect your BI or reporting tool to your compute engine to build dashboards that visualize active users, feature adoption, and retention for your Atlan tenant
  • If you use Claude as your AI assistant, run the same usage analytics queries conversationally using the atlan-usage-analytics skills repository so you can ask questions in natural language instead of writing SQL.
• Check out sample queries for product usage analytics in our use case documentation.

📘 Learn more

Visit the docs to learn more about the usage_analytics schema, including tables, use cases, and sample queries you can use to drive product usage analytics use cases.

🌊 Introducing Atlan Lakehouse

Atlan captures rich context about assets across your data estate, including definitions, tags, ownership, usage, and lineage, which you can use to answer core governance and adoption questions with confidence. 

Historically, teams have had to wait hours or days to export this metadata from Atlan, load it into their compute platform, and only then start building reports or AI applications to understand how their data estate is being used.

Atlan Lakehouse is a new way to work with Atlan. We now store this rich context about your data estate in an open, interoperable lakehouse that’s instantly accessible from your preferred engines, so you can build dashboards and AI applications on Atlan context immediately, without custom exports or pipelines.

🎉 What's new

You can now enable Lakehouse for your Atlan tenant via Atlan’s App Marketplace and start building dashboards and AI applications on your Atlan context in minutes.

✨ Let’s dig deeper

Atlan Lakehouse is an Apache Iceberg–based data lakehouse that contains everything Atlan knows about your data estate, exposed through an Iceberg REST catalog that your engines can query like any other source.

Just like the rest of Atlan’s platform, Atlan manages the infrastructure behind the scenes so you can focus on connecting your warehouse and building reports, dashboards, and AI applications. Once Lakehouse is enabled, you can instantly power AI and advanced analytics with rich Atlan context:

• Treat metadata like data
  Unify technical, business, governance, and operational signals in a high-performance repository that can feed AI models, contextual search, and agentic workflows across your stack.
• Answer governance and adoption questions easily
  Answer questions like “What percentage of assets are documented or tagged?”, “Which domains have the most stale tables?”, or “Where are critical data quality gaps?” directly from Snowflake or other supported engines – without building export jobs.
• Use your preferred Iceberg REST–compatible engine
  Use any Iceberg REST-compatible engine (for example Snowflake, Spark, Trino) so Atlan context shows up alongside your existing data sources and follows the same analytics patterns you already use.

👏 Give it a shot

If you are an Admin on Atlan, you can enable Atlan Lakehouse for your tenant:

1. In Atlan, go to Workflows > Marketplace.
2. Find the Atlan Lakehouse app tile.
3. Click Enable. We'll notify you when your Lakehouse is ready.

Once your Lakehouse is ready, you can connect any Iceberg REST-compatible engine and start building dashboards and AI applications on your Atlan context.

📘 Learn more

Visit the docs to learn more about popular use cases, including sample queries you can copy and paste to jump-start governance dashboards, adoption reports, and AI applications.