SAP TechEd 2026: The beginning of the end of dashboarding as we know it?
I’m back from SAP TechEd 2026 in Berlin, so it’s time to reflect on everything I’ve seen, heard, and discussed over the past few days. As always, I tend to look at these developments primarily from a front-end perspective: what will all of this actually mean for the end user? Plenty has already been written about SAP Business Data Cloud, the lakehouse, the additions of Dremio and Reltio, and the future of SAP BW. So I’d rather focus on SAP Analytics Cloud (SAC) and how we’ll be working with analytics in the future.
The pieces of the puzzle are starting to come together
First, a few words about SAP Datasphere. I found some of the reactions I heard here and there, along the lines of “Datasphere is dead”, rather exaggerated. If anything, the opposite seems to be true. SAP continues to invest heavily in Datasphere, including efforts to achieve greater feature parity with existing BW functionality. Think of BEx features such as linked hierarchy nodes, hierarchy node variables, and text variables. These are particularly important for the front end and are among the features that set SAP Analytics apart. Also don’t forget the efforts of the past years to make seamless planning possible.
One thing I noticed at TechEd is how strongly people are pushing SAP for a clear roadmap and definitive answers on where each product fits. I understand that, but I also think such certainty is becoming increasingly unrealistic, especially with AI evolving at its current pace. Many of the ideas and concepts we’re seeing still have to prove themselves in practice, and SAP will inevitably have to adjust its plans along the way. I don’t necessarily see that as a bad thing. What’s important, though, is that SAP remains transparent about what is available today, what’s on the roadmap, and what’s still just a vision.
What did become clear to me is that the individual concepts, ideas, and technologies that still seemed relatively isolated from one another last year are now increasingly coming together and building on each other. A good example is SAP-RPT, SAP’s Relational Pretrained Transformer model. Unlike the Large Language Models (LLMs) we’ve all been using extensively, this model isn’t primarily designed for text, but for structured, relational data. Last year, SAP-RPT was introduced during the keynote as what was, at least to me, a rather abstract concept. This year, we saw a lab preview demonstrating how this Tabular AI model could be used within SAC Planning to detect outliers, perform regression analyses, and generate forecasts. I found this interesting, not so much because it immediately delivered something revolutionary, but because we’re now starting to see how these different AI technologies are finding their way into existing SAP applications.
Joule Work: a new way of working?
One of the most interesting developments for me was Joule Work. With this, SAP is introducing a new user interface that will sit alongside existing SAP S/4HANA applications and SAC stories. Think of an interface similar to ChatGPT or Claude, but integrated into your SAP landscape.
The ultimate vision is that Joule Work will eventually give you access to all your applications, data, and processes. You’ll be able to ask questions, perform analyses, initiate transactions, or execute complete workflows without constantly switching between different applications. Joule Work would therefore become much more than just a chatbot sitting on top of your applications. It would become a new workspace where you can carry out an increasing number of your daily tasks.
For SAC, this is still very much a long-term vision. In the shorter term, the focus is on adding more AI capabilities within SAC itself. I’ll get back to that later.
What I find interesting about Joule Work is that it’s not just about a chat interface. The idea is also that the interface can adapt to the task you’re trying to accomplish, dynamically presenting relevant information and interactive elements. That’s obviously quite different from simply having a chatbot that provides text-based answers.
There’s still a lot of work to be done before we get there. Joule Studio, the development environment in which you can build agents, applications, and workflows, was already available for extensive testing at TechEd. I had the opportunity to work with it both in the Developer Garage and during the hands-on workshops.
The version we used was still full of bugs and peculiarities. For example, it turned out to be surprisingly easy to get Joule to do things outside the scope of its intended task. With an agent that was supposed to create data products, we managed to get it to generate workflows and even complete applications, much to the amusement of the product managers present. Its language capabilities were also rather inconsistent: one moment Joule was perfectly happy communicating in Dutch, while the next it categorically refused to use anything other than English.
Of course, this was clearly an early version, so some instability is to be expected. I already found the tooling itself quite powerful. At the same time, experiments like these demonstrate that there’s still plenty of work to be done in terms of reliability, security, and governance. Especially when AI agents will eventually be able to perform actions independently within business systems.
Another interesting aspect is the development approach used in Joule Studio. You start with an intent, describing in natural language what you want to achieve. For example, building a data product. Joule then generates a specification and essentially interviews you to clarify and refine the requirements.
These specifications are stored in Markdown (.md) files, similar to how instructions and context files are used in other AI development tools. You can continue modifying them manually or through prompts until you’re satisfied. Joule can then build the objects, after which you can test, adjust, and eventually deploy them.
I find this approach to development particularly interesting. It doesn’t mean developers will no longer be needed, but their role is clearly shifting from manually building every individual component towards specifying, guiding, and validating what AI generates.
Could this be the end of dashboarding?
During the Joule Work presentations, I started wondering whether we might actually be witnessing the beginning of the end of dashboarding as we know it. After all, nobody really wants a dashboard for the sake of having a dashboard. A dashboard is simply a means of obtaining information that helps you do your job or make decisions.
Why would you still open an elaborate SAC story, navigate through different pages, apply filters, and perform analyses when you could simply ask Joule how your sales figures are doing, why margins have dropped, and which customers are responsible? And what if Joule could then generate the relevant charts, tables, and analyses on the fly, tailored precisely to your question? Or even better, have Joule prepare all of this for you before you start your working day. That would represent a fundamentally different way of consuming analytics.
Of course, SAP has experimented with this before. We already have Just Ask in SAC, for example, but in my experience it doesn’t work particularly well and comes with quite a few limitations. The SAC mobile app has also offered ways to interact with analytics through voice for quite some time, although I do wonder how many people have actually used those capabilities.
But technology is advancing at an incredible pace, and users are becoming increasingly accustomed to these types of interactions. I therefore think it’s only a matter of time before natural language interfaces start playing a serious role in how we consume business analytics. During the keynote, SAP even demonstrated a CarPlay app for Joule Work that allows you to discuss your KPIs while driving. Perhaps a somewhat contrived example, but it does illustrate the direction SAP is heading.
Still, I see a number of fundamental challenges. First of all, prompting isn’t always the most efficient way to work with data. If I want to add a dimension to an analytical table or quickly change a filter, I can do that with just a few mouse clicks. Typing or speaking a prompt, waiting for it to be interpreted, and then verifying whether the correct action was performed could take considerably longer. And of course, every interaction also consumes computing resources and tokens, although those costs will undoubtedly continue to decrease.
There’s also an important difference between asking a specific question and continuously monitoring a business process. A well-designed dashboard gives you an overview of multiple KPIs, relationships, and deviations at a glance. You don’t need to know in advance which question to ask. Sometimes you discover something interesting precisely because different pieces of information are presented side by side. That’s an important quality of dashboards that you can’t simply replace with a chatbot.
To make Joule Work truly suitable for analytics, it will therefore need interactive analytical capabilities similar to those we already have in SAC. Think of filtering, drilldowns, changing dimensions, and combining different visualizations. Not everything needs to, or should, be done through prompts.
Another question is how Joule Work will gain access to all existing analytical models, business logic, hierarchies, and authorizations. Making SAC’s analytical capabilities seamlessly accessible through Joule Work will be an important prerequisite if SAP wants to turn this vision into reality. But again, I don’t see this as an insurmountable challenge. So perhaps we’re not looking at the end of dashboards themselves, but rather the beginning of the end of the traditional dashboard environment as the default starting point for analytics.
And what about SAC itself?
Now, let’s turn to SAP Analytics Cloud itself. It took a bit of searching to find SAC-related content at this year’s TechEd, but it was definitely there. The Joule panel that I already had a chance to test at last year’s TechEd has been significantly expanded and, according to the roadmap, should still become available in SAC by the end of 2026.
With this panel, Joule can assist you in building and using stories. Think of adding widgets, adjusting filters, or performing a series of planning actions that would previously have required quite a few manual clicks. The panel floats on top of your SAC application and is context-aware. This means Joule takes into account what you’re currently looking at in your story. That sounds logical, but I immediately ran into an interesting limitation: parts of a story that weren’t visible couldn’t be accessed by Joule in the version demonstrated.
I’m curious to see how this will work in practice. After all, we’ve spent years trying to make SAC stories as efficient as possible, for example by using lazy loading and only loading components when they’re actually needed. If an AI assistant depends on that visible or loaded context to do its job, it could potentially conflict with our performance optimizations.
I also found it remarkable that there don’t seem to be any concrete plans yet to bring similar Joule capabilities to the Data Analyzer. When I tested it, the panel couldn’t interact with the Data Analyzer at all. That’s a shame, considering this is precisely the environment where users can interact freely with their data.
I also had the chance to test the recently added AI-assisted Prompt Insights widget. This allows a story designer to include a predefined prompt in a story, which can then perform an AI-powered analysis of, for example, the data displayed in a table.
In the version I tested, this was still quite limited. The prompt was predefined by the story designer, and the end user could only execute it, not modify it. Here too, I encountered the issue that the analysis was limited to the context available within the story. The AI couldn’t independently explore the complete underlying model to perform a deeper analysis. So this feels very much like a first step. The ability to provide predefined analyses can certainly be useful, but it’s still a long way from an AI assistant that can independently explore a dataset and ask the right follow-up questions.
Generating an SAC story with AI
One capability I was more enthusiastic about was the automatic generation of complete SAC stories. I seem to remember seeing this at last year’s TechEd as well, although I can’t recall whether we were already able to experiment with it ourselves. This year, we certainly could, and at first glance, it worked surprisingly well.
The approach is very similar to Joule Studio. First, you select a data source and describe what you want to achieve with your story. The AI then helps you turn this description into a set of requirements. Once you’re satisfied, you let the agent actually build the story. Afterwards, you can use the Joule panel to make further adjustments, or simply continue working in the story editor yourself.
Incidentally, I found the naming of one of the objects involved rather unfortunate. The description of the desired story is stored in something called an Insights Instruction. That sounds a little too similar to the Insights you can already save from the Data Analyzer. As if we didn’t already have enough confusingly similar terms within SAC.
And one more small peculiarity: Joule in SAC can now understand Dutch, but getting it to respond in Dutch was still a different story during my tests.
So where does this leave us?
What struck me most during this TechEd is that SAP is approaching the future of analytics from two directions at once. On the one hand, SAC is being expanded with AI capabilities intended to make building, analyzing, and planning easier. These are relatively concrete improvements within an existing application.
On the other hand, with Joule Work, SAP is working towards a fundamentally different way of working, where users no longer have to decide which application or dashboard to open, but instead receive the right information and functionality based on a question or intent. Over time, these two developments will increasingly need to come together.
I don’t expect dashboards to disappear anytime soon. For monitoring, structured reporting, and interactive analysis, good visualizations and well-organized interfaces will remain important. But I can certainly imagine a future where we open predefined stories much less frequently to answer specific questions, simply because Joule can provide us directly with the right information and visualizations.
That doesn’t mean the complexity will disappear, though. The underlying models, business logic, authorizations, and semantic definitions may become more important than ever. After all, an AI assistant confidently providing an incorrect answer based on misinterpreted business data is considerably more dangerous than a dashboard where you can still see which filters and dimensions are being applied.
And of course, we’ll have to see how well all of this actually works in practice. The demonstrations are interesting, but there’s still quite a gap between a successful demo at TechEd and a reliable production environment serving thousands of users.
Finally, a few words about TechEd itself
A few final thoughts on the conference itself. The logistical problems of the 2025 edition seem to have been almost completely resolved. There were hardly any queues, and plenty of seats were available at the sessions. A significant improvement over last year.
What I still find disappointing is the relatively small number of genuine technical deep-dive sessions. Think of topics such as performance tuning, modelling best practices, and concrete architectural decisions. I also found the number of customer cases rather limited. I even saw one customer telling virtually the same story in two different sessions.
Nevertheless, I found this year’s edition interesting from a content perspective, precisely because it’s becoming increasingly clear how the various developments are coming together. Where last year I mainly saw individual announcements and concepts, a more coherent vision of the future is now starting to emerge.
Will this actually mean the end of dashboarding as we know it? I’m not ready to make that prediction just yet. The potential is certainly there, but there’s also an enormous amount of work left to do before we can rely on all of this in practice.
SAP TechEd 2027 is already scheduled for November 2–4 in Barcelona. I’m curious to see how much of this vision we’ll actually see working by then.
HackingSAP.com - Nov 1, 2026 | SAP Analytics Cloud
Tagged | SAP TechEd
