Tableau Agent KI in Tableau Prep: Ein Praxistest  

Einleitung

März 2026

Es gibt eine bekannte These im Datenmanagement: Rund 80 % der Ressourcen fließen meist in die Datenaufbereitung (Data Wrangling), während nur 20 % für die eigentliche Analyse der Daten verbleiben. Besonders zeitintensiv ist das Bewältigen technischer Hürden – etwa die Strukturierung unsauberer Daten und den damit verbundenen Entwicklungsarbeiten. 

Mit der Einführung des Tableau Agents (ehemals Einstein Copilot) versucht Salesforce diese Herausforderung zu adressieren. Es handelt sich hierbei um eine KI, die für Datenaufbereitung in der Tableau Prep Umgebung genutzt werden kann und als Übersetzer fungiert: Sie übersetzt geschäftliche Anforderungen in technischen Code und erleichtert Teile von Entwicklungsaufgaben. 

In diesem Blog demonstrieren wir anhand eines praxisnahen Beispiels, wie sich komplexe Aufbereitungsschritte durch KI beschleunigen lassen – und warum die Rolle des Analysten als Validierer („Human-in-the-Loop“) derzeit noch wichtig ist. 

Technische Voraussetzungen: Integration in den Einstein Trust Layer 

Bevor die KI operativ genutzt werden kann, ist ein Blick auf die Administration der Tableau Umgebung (Tableau Cloud oder Tableau Server) notwendig, um die für die Nutzung der KI notwendigen Einstellungen vorzunehmen. 

Die verschiedenen KI-Features von Tableau müssen in diesem Menü aktiviert werden. Damit der Tableau Agent in Prep zur Verfügung steht, muss die Tableau Site explizit mit einer Salesforce-Organisation (z. B. Data Cloud) verbunden werden. Dies stellt sicher, dass alle generativen Anfragen über den Einstein Trust Layer verarbeitet werden, was Datensicherheit und Compliance gewährleistet. Erst nach diesem „Handshake“ stehen die KI-Features in den Site-Einstellungen zur Aktivierung bereit. 

Das erste Szenario: Struktur aus unstrukturierten Daten gewinnen 

Unser erster Test konzentriert sich auf ein klassisches „Dirty Data“-Szenario. Unser Fokus liegt auf Marketingdaten, die uns in unstrukturierter Form vorliegen. Ziel ist es, diese Daten zu strukturieren, damit wir sie für spätere Analysen nutzen können. Wir erstellen hierfür ein neues Schema in der Tableau Cloud Web-Umgebung und binden Daten aus einer einfachen .csv-Datei an. 

Unser Datenset besteht aus mehreren Spalten, die unstrukturierte Daten enthalten. Im Folgenden werden wir diese Daten mit Hilfe des Tableau Agent bereinigen und strukturieren. 

Wir betrachten zunächst das Feld 

Kontakt_Info_Mix, 

in dem Adresskomponenten (Straße, PLZ, Stadt, Land) ohne festes Trennzeichen aggregiert vorliegen, z.B.: 

  • Datensatz A: 
    Münchner Str. 12; 80331 München (DE) 
  • Datensatz B: 
    456 High St | London SW1A 1AA | UK 

Unser Ziel ist die Extraktion der Postleitzahl und des Ländercodes in dedizierte Spalten, damit diese in einem Dashboard dediziert genutzt werden können. Wir nutzen den Tableau Agent, um die hierfür notwendige “RegEx”-Logik aufzubauen. 

Iterative Entwicklung: Die KI als Coding-Partner 

Wir öffnen zunächst den Tableau Agent über das folgende Symbol in der rechten oberen Ecke der Bearbeitungsoberfläche: 

Da wir den Tableau Agent im Kontext der Datenaufbereitung nutzen wollen, erstellen wir, nachdem wir unsere Daten angebunden haben, einen neuen Aufbereitungsschritt und markieren selbigen. Anschließend können wir unseren ersten Prompt an den Tableau Agent senden. Wir wollen zunächst versuchen, die 5-stellige Postleitzahl aus den unstrukturierten Daten zu extrahieren – zum Beispiel, um geografische Analysen auf Basis der Postleitzahl zu ermöglichen. 

Nachdem die vom Tableau Agent vorgeschlagene Formel übernommen und ein neues Feld erstellt wurde (1), offenbart sich eine wichtige Lektion für Data Engineers. Der Agent identifiziert zwar das korrekte Muster, doch die Vorschau zeigt NULL-Werte (2). Um dieses Problem verstehen und beheben zu können, können wir zunächst die vom Tableau Agent bereitgestellte Erläuterung der erstellten Formel (3) betrachten. 

Erfahrene Tableau-Entwickler können hier feststellen, dass die vom Tableau Agent genutzte Funktion REGEXP_EXTRACT in Tableau zwingend eine sogenannte „Capturing Group“ (gesetzt durch Klammern) erfordert, um einen Wert nicht nur zu finden, sondern auch zurückzugeben. Die KI lieferte die korrekte Syntax für das Matching, aber nicht für die Extraktion 

Im ersten Versuch liefert der Tableau Agent somit zwar einen guten ersten Ansatz, jedoch noch keine fertige Lösung. Dies kann insbesondere für Tableau-Benutzer ohne tieferes technisches Wissen eine Herausforderung darstellen. 

Verfeinerung und Ergebnis: Präzision durch Context Prompting 

Um das Ergebnis zu korrigieren, präzisieren wir unseren Prompt. Wir instruieren den Agenten nicht nur „Was“ extrahiert werden soll (5 Ziffern), sondern auch „Wie“ (konkrete Extraktion eines Beispiels). Ziel ist die Generierung einer korrekten Formel, selbst wenn dem Benutzer die tieferen technischen Kenntnisse fehlen. 

Das Ergebnis: Der Agent korrigiert die Formel selbständig. Durch das Setzen der Klammern (Capturing Group) werden die Werte nun korrekt extrahiert. Postleitzahlen, die nicht dem Muster entsprechen, bleiben korrekterweise leer (NULL), was die Robustheit der Logik bestätigt.

Dieses Beispiel zeigt, dass eine präzisere Formulierung von Prompts die Wahrscheinlichkeit erhöht, dass der Tableau Agent auf Anhieb korrekte Ergebnisse liefert. Dies ist besonders vorteilhaft, da kein tiefgehendes technisches Wissen erforderlich ist.

Verschachtelung und Fehlerbehandlung

Im nächsten Test testen wir die Fähigkeit des Tableau Agenten, Funktionen zu verschachteln. Wir möchten den Ländercode extrahieren und fehlende Werte direkt durch einen Platzhalter ersetzen. Dies ermöglicht uns nachfolgend die Durchführung von Auswertungen auf Ebene der Länder.

Basierend auf unseren Erfahrungen aus dem ersten Beispiel definieren wir den Prompt so detailliert wie möglich und liefern direkt geeignete Beispiele, um dem Tableau Agenten zu helfen, ein korrektes Ergebnis zu generieren:

Der Agent generiert eine performante und korrekte Kombination aus IF, REGEX_MATCH,  REGEXP_EXTRACT. Als Ergebnis werden Ländercodes extrahiert und ein „-“ eingefügt, wenn die Information fehlt. Die KI übernimmt nicht nur die Mustererkennung, sondern auch die korrekte Syntax der Klammern für die verschachtelten Funktionen – eine häufige Fehlerquelle bei der manuellen Eingabe.

Textbereinigung: Mehrere Schritte in einem

Ein weiteres, gutes Beispiel zeigt sich bei der Bereinigung der Kundennamen, was uns für die strukturierte Analyse auf Kundenebene hilft.

Die Anforderung ist mehrstufig:

  1. Entferne Anreden (Herr, Frau, Dr.).
  2. Korrigiere die Groß-/Kleinschreibung (Proper Case).
  3. Entferne überflüssige Leerzeichen.

Der Agent löst dies mit einer einzigen, mehrfach verschachtelten Formel.

Dies manuell zu schreiben, würde tieferes Verständnis der String-Funktionen erfordern. Der Agent liefert das Ergebnis in Sekunden.

Typisierung

Zum Schluss bitten wir den Agenten, das Textfeld „Eingangsdatum“ in ein echtes Datum zu konvertieren. Dies ist oft bei der späteren Entwicklung von Visualisierungen hilfreich, da native Datumsfelder in vielen Fällen präziser verwendet werden können.

Auch hier erkennt die KI den Kontext und führt die Typ-Konvertierung ohne manuelles Menü-Klicken durch.

Fazit: Vom „Writer“ zum „Reviewer“

Der Praxistest zeigt deutlich: Der Tableau Agent ist kein Autopilot, der blindes Vertrauen rechtfertigt, sondern ein leistungsstarker Co-Pilot für Data Engineers.

Die strategischen Vorteile:

  1. Time-to-Value: Die Erstellung komplexer Logik wird massiv beschleunigt.
  2. Qualitätssicherung: Da der generierte Code als transparenter, editierbarer Berechnungsschritt im Flow landet, bleibt die volle Kontrolle beim Analysten.
  3. Skill-Transfer: Die Erklär-Funktionen des Agenten helfen weniger erfahrenen Nutzern, komplexe Syntax schneller zu verstehen und anzuwenden.

Für moderne BI-Teams bedeutet dies einen Rollenwechsel: Der Analyst verbringt weniger Zeit mit dem Schreiben von Syntax und mehr Zeit mit der Validierung von Logik und Datenqualität.

Auch wenn die KI erste gute Ergebnisse generiert, müssen diese stets durch den Benutzer validiert werden (Human-in-the-Loop). Der Tableau Agent liefert einen ersten Entwurf, doch der Analyst muss den generierten Code auf fachliche und technische Korrektheit prüfen. Ziel ist die Beschleunigung des Entwicklungsprozesses und der Abbau technischer Hürden, nicht die alleinige Aufgabenerledigung durch die KI.

Wir stellen jedoch fest, dass KIs wie der Tableau Agent weiterhin in Entwicklung sind, da derzeit noch nicht alle Funktionalitäten durch die KI abgedeckt werden und die Ergebnisse stark von präzisen Prompts abhängen.

Aktuelle Einschränkungen:

  • Präzisionsabhängigkeit: Die KI fungiert als Co-Pilot, erfordert aber iterative, präzise Prompts für technisch korrekte Formeln (z.B. REGEXP-Syntax).
  • Begrenzter Funktionsumfang: Der Agent konzentriert sich auf Berechnungsschritte; komplexere Prep Flow-Aktionen wie Pivotieren, Aggregieren oder Verbinden müssen noch manuell erfolgen.

Zukunftspotenzial:

Künftige Iterationen könnten durch verbesserte Context-Awareness (automatische Korrektur von Syntax-Fehlern), erweiterte „Flow“-Steuerung (Umsetzung komplexer Anweisungen wie „Aggregiere Verkaufsdaten“) und multimodale Inputs (Text, Skizzen, Dokumente) die Präzision erhöhen und die Hürden abbauen.

 

Data Products Setup

I’ll start with Data Products setup. If you’re new to the concept, this recent video is a great starting point, but here’s a short summary. A data product is a well-described, easily discoverable, and consumable collection of data sets.

Creating a Data Product in Datasphere

Note that in this article I create Data Products in the Data Sharing Cockpit in Datasphere. This functionality is expected to move into the Data Product Studio, but that had not taken place at the time writing.

Before creating a Data Product in Datasphere, I need to set up a Data Provider profile, collecting descriptive metadata like contact and address details, industry, regional coverage, and importantly define Data Product Visibility. Enabling Formations allows me to share the Data Product with systems across your BDC Formation – Databricks, in this case.

With the Data Provider set up, I can go ahead and create a Data Product. As with the Data Provider, I’ll need to add metadata about the product and define its artifacts – the datasets it contains. Only datasets from a space of SAP HANA Data Lake Files type can be selected. Since this Data Product is visible across the Formation, it is available free of charge.

For this demo, the artifact is a local table containing ten years of Ice Cream sales data. Since this is a File type space, importing a CSV file directly to create a local table isn’t an option (see documentation).

I used a Replication Flow to perform an initial load from a BW aDSO table into a local table.

Once Data Product is created and listed, it becomes available in the Catalog & Marketplace, from where it can be shared with Databricks by selecting the appropriate connection details.

Jump into Databricks

To use the shared object In Databricks, I need to mount it to the Catalog – either by creating a new Catalog or using an existing one.

Databricks appends a version number to the end of the schema – ‘:v1’ – to maintain versioning in case of any future changes to the Data Product.

Once the share is mounted, the schema is created automatically, and the Sales actual data table becomes available within it. From there, I can access the shared table directly in a Notebook.

Creating a Data Product in Databricks

To create a Data Product in Databricks, I first need to create a Share – which I can either do via the Delta Sharing settings in the Catalog:

Or directly out of the table which is going to become a part of the Share:

Since a single Share can contain multiple tables, I have the option to either add the table to an existing Share, or create a new one:

To publish the Share as a Data Product, I run a Python script where I define the target table for the forecast and describe the Share in CSN notation, setting the Primary Keys. Primary Keys are required for installing Data Products in Datasphere.

Jump back into Datasphere

Once the Databricks Data Product is available in Datasphere, I install it into a Space configured as a HANA Database space – since my intention is to build a view on top of the table and use it for planning in SAC.

There are two installation options: as a Remote table for live data access, or as a Replication Flow, in which case the data is physically copied into the object store in Datasphere.

Since I want live access, I install it as a Remote Table:

and build a Graphical view of type Fact on top:

Forecast calculation

With my Data Products set up and Sales actual data are available in Databricks, I create a Notebook to calculate the Sales Forecast.

The approach combines Sales and Weather data to train a Linear Regression model. I import the Weather data *https://zenodo.org/records/4770937 from an external server directly into Databricks, select the relevant features from the weather dataset, and combine them with the Sales actual data:

* Klein Tank, A.M.G. and Coauthors, 2002. Daily dataset of 20th-century surface
air temperature and precipitation series for the European Climate Assessment.
Int. J. of Climatol., 22, 1441-1453.
Data and metadata available at http://www.ecad.eu

Using the “sklearn” library, I build and train a Linear regression model:

Once trained, the model predicts the Sales forecast for Rome in June 2026 based on the weather forecast, and I save the results to my Catalog table:

Seamless planning data model

Seamless planning concept is built around physically storing planning data and public dimensions directly in Datasphere, keeping them alongside the actual data.

Since the QRC4 2025 SAC release, it has also been possible to use live versions and bring reference data into planning models without replication.

In this scenario, I build a seamless planning model on top of the Graphical view I created over the Remote table. This lets me use the forecast generated in Databricks as a reference for the final SAC Forecast version.

 

The model setup follows these steps:

Create a new model:

Start with data:

Select Datasphere as the data storage:

From there, I define the model structure and can review the data in the preview.

For a deeper dive into Seamless Planning, I recommend this biX blog.

Process Flow automation

Multi-action triggers Datasphere task chain

The final step is automating the entire forecast generation by using SAC Multi-actions and a Task-Chain in Datasphere – so that my user can trigger the calculation with a single button click from an SAC Story.

The model setup follows these steps:

Create a new model:

Triggering Task Chains from Multi-actions is a recent release. This blog post walks through how to set it up.

For details on how to trigger a Databricks Notebook from Datasphere, I recommend referring to this blog.

With everything in place, I create a Story, add my Seamless planning Model, and attach the Multi-action:

Running the Multi-action triggers the Task Chain, which in turn triggers the Databricks Notebook.

I can monitor the execution details in Datasphere:

and in Databricks:

Once the calculation completes, the updated forecast appears in the Story:

The end-to-end calculation took 2 minutes 45 seconds in total. The Task Chain in Datasphere is triggered almost instantly by the Multi-action, the Databricks Notebook execution itself took 1 minute 29 seconds, with the remaining time spent on Serverless Cluster startup.   

 

From here, I can copy the calculated forecast into a new private version:

adjust the numbers as needed, and publish it as a new public version to Datasphere:

Conclusion

With SAP Business Data Cloud, it is possible to build a forecasting workflow that feels seamless to the end user — even though it spans multiple systems under the hood.

Companies using BW as the main Data Warehouse and Databricks for ML calculations or Data Science tasks can benefit from using the platform, as the data no longer needs to be physically copied out of BW.

What this scenario demonstrates is that once wrapped as a Data Product, BW sales data can be shared with Databricks via the Delta Share protocol. Databricks, in turn, can then create its own Data Products on top of the calculation results and share them back with Datasphere as a Remote Table.

A Seamless Planning model in SAC sits on top of that Remote Table, giving planners live access to the generated forecast. A single Multi-action in an SAC Story ties it all together, triggering a Datasphere Task Chain that kicks off the Databricks Notebook — completing the full cycle in under three minutes.

As SAP Business Data Cloud continues to mature, scenarios like this one are becoming achievable – leaving the complexity in the architecture and not in the workflow.

Ansprech­partner

Ilya Kirzner
Consultant
biX Consulting
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.