Some changes in the SAP world initially look like little more than a new product launch or a new user interface announcement. Their true impact often becomes clear only a few years later.
The transition from SAP GUI to Fiori was one such example. It changed the way users interacted with SAP; transaction codes and complex screens were gradually complemented by role-based applications, launchpads, and simpler user experiences.
We may now be at the beginning of a similar — and potentially even more fundamental — shift with Joule Work, announced at SAP Connect in October 2026.
SAP CEO Christian Klein described Joule Work as “the new user interface for AI” and announced that the solution would begin rolling out to customers during October. SAP’s message is striking: for decades, people had to learn how SAP works; the new approach aims for SAP to understand what people are trying to achieve.
Could this simply be another compelling AI slogan?
A closer look at SAP’s architecture documentation suggests that the ambition goes much deeper. Alongside the traditional model — where users first find the right application, navigate to the right screen, and follow predefined steps — a new approach is emerging: “express your intent, and let the system bring together the relevant data, applications, and agents for you.”
That is why viewing Joule Work as merely another chatbot would miss a significant part of what SAP is trying to change.
At the most fundamental level, the question is this:
How much SAP will users need to know in the future in order to work effectively with SAP?
And immediately behind that comes an even more important question for SAP professionals:
If the way users work with SAP changes, how will the way SAP professionals work change as well?
For Years, SAP Taught Users How to Work the SAP Way
A significant share of SAP users have experienced at least two stages of this journey.
During the SAP GUI era, the user experience was largely system-centric. Users did not simply need to know how to create a purchase order; they also had to learn how SAP expected that task to be carried out. Which transaction code to use, which tab to open, which fields to complete, and in what sequence the process should proceed all became part of the user’s SAP knowledge.
For years, “knowing SAP” and “knowing the business process” therefore evolved as two closely connected capabilities.
Fiori introduced an important shift. Instead of presenting users with hundreds of options, the goal was to provide applications that matched their roles and responsibilities. The experience became simpler, more mobile, and more task-oriented.
But the underlying logic remained largely the same:
The user knew what they wanted to do, found the relevant application, and completed the task within a predefined interface.
A third phase began as Joule became embedded within SAP applications. Natural language entered enterprise software. Users could ask questions, request information, or initiate specific tasks.
Joule Work aims to take the next step: instead of placing AI inside the application, it brings applications, data, and agents together around an AI-powered workspace.
SAP’s own AI-native architecture describes the direction very clearly: rather than navigating from application to application, users are expected to express their intent, while the system dynamically shapes the experience around that intent.
This is where the real significance of the change lies.
What Was Announced in October 2026?
At SAP Connect, Joule Work was positioned as the primary user-facing layer of SAP’s “Autonomous Enterprise” approach.
In the model SAP presented, users can ask questions in natural language through Joule Work, delegate tasks to agents, and view content and outcomes from different business activities within the same working environment. Joule Studio, meanwhile, serves as the development layer that enables customers to build agents, applications, and workflows tailored to their own processes.
According to figures SAP has shared from its own internal use, Joule Work is used by around 110,000 employees, and the company says it has observed productivity gains of more than 20% in central functions such as finance, human resources, and procurement. These results come from SAP’s own working environment and should not be interpreted as an indication that the same gains will automatically be achieved in other organizations.
What is even more interesting, however, is what sits behind the architecture.
SAP does not want Joule Assistants merely to provide answers; it aims for them to perform tasks within existing business processes. SAP also states that these activities are intended to preserve existing data access, user authorizations, and audit trails, while allowing customers to determine how much autonomy agents should have depending on the process.
So the goal is not simply to answer:
“What is the status of this invoice?”
The next level is:
“Why is there a problem with this invoice, what actions are required, and carry out the steps that fall within my authorization.”
There is a significant difference between the two.
The Real Shift: From Screens to Intent
This is where Joule Work becomes particularly interesting.
Today’s enterprise software experience is still largely application-centric. You first need to know which application to use. You open the application, find the relevant data, and complete the task.
SAP’s target model, however, is intent-driven.
A user may no longer stop at saying:
“Show me the overdue purchase orders.”
Instead, they may ask:
“Identify the supply issues that could put production at risk over the next four weeks, prioritize them, and show me where I need to intervene.”
Answering the second request is not simply a matter of querying data.
The system needs to understand suppliers, open purchase orders, inventory levels, the production plan, delivery dates, the user’s area of responsibility, and potentially data from other systems at the same time.
That is why, in enterprise AI, business context is becoming at least as important as the language model itself.
SAP’s investment in the Knowledge Graph is closely related to this. According to figures published by SAP, the structure spans the context of more than 7 million data fields, 50 million tables, over 50,000 APIs, and hundreds of data products.
A general-purpose language model can explain what a “purchase order” is.
An enterprise SAP agent, however, needs to answer much harder questions:
Which company code? Which user? Which supplier? Which purchasing organization? Which stock position? Which contract? Which authorization?
This difference will be one of the key factors determining whether the Joule Work approach succeeds or falls short.
Does This Mean the End of SAP GUI and Fiori?
For an experienced SAP professional, this is one of the most natural questions to ask.
Based on what we know today, the answer is no.
SAP’s own product and UX statements make it clear that Joule Work is intended to work alongside existing application interfaces, rather than replace them. Depending on the need, users may still go directly into a traditional application or express their intent through Joule Work.
SAP GUI and Fiori are not disappearing in the short term, and knowledge of transaction codes and traditional applications will not suddenly lose its value. What may change, however, is how often users need to access those interfaces directly.
If routine information retrieval, gathering data from multiple systems, standard approvals, or other repetitive activities can increasingly be handled directly through Joule Work, the application itself may no longer be the first place where the user starts the task.
So rather than reducing the discussion to “Is Fiori dying?”, a more useful question is:
Could the SAP application remain the place where the transaction is executed, while Joule Work becomes the place where the transaction begins?
SAP’s current architectural direction is clearly aimed at making that possible.
Further Reading
Take a look at our guide on [7 Strategic Developments Shaping the SAP Ecosystem in 2026] to explore technological transformation, AI integration, and key future trends across the ecosystem.
How Could a Day in the Life of an SAP User Change?
Consider a procurement manager.
Today, they review open purchase orders in S/4HANA, check inventory levels in another application, export critical materials to Excel, analyze supplier performance in a separate report, and, if needed, send an email or assign a task to a colleague.
There is nothing inherently wrong with any of this. But a significant part of the work consists of carrying context from one system to another.
In an intent-driven model, the user might simply say:
“Show me the supply risks that could affect the production plan. Separate the critical ones and prioritize where I need to intervene.”
The system would then review the permitted data sources, evaluate the relevant relationships, make use of the appropriate agents, and present the results in a form that supports the user’s decision-making.
Some routine actions could be carried out automatically within predefined boundaries, while higher-risk decisions could remain with the human user.
Within SAP’s architecture, the “Jobs” approach is also designed to make agentic work traceable from the user’s perspective and to escalate important decision points to a human when needed.
But the boundary needs to be drawn carefully.
This scenario is not yet a fully standardized capability that works end-to-end for every SAP customer today. It represents the working model that SAP’s announced architecture and newly introduced products are aiming toward.
That distinction matters if we want to avoid creating unrealistic expectations around AI.
What Could Change for SAP Professionals?
This is where the discussion becomes especially interesting.
Functional Consultant
In SAP, simply knowing the screens and customizing steps may become less valuable over time, while understanding why a business process needs to work in a certain way may become more valuable.
An agent may be able to execute the order process.
But deciding which exception is acceptable, why a business rule exists, or when human approval is required is not purely a technical question.
The functional consultant’s role may therefore gradually shift from answering “Where do we do this in SAP?” toward answering “How should this process be designed?”
ABAP Developer
It is already clear that code generation will increasingly be supported by AI.
That does not make ABAP expertise irrelevant. But skills in API design, Clean Core, BTP extensibility, integration, agent skills, and enterprise architecture may become more important.
In the future, a strong developer may be defined not only by the ability to write code, but also by the ability to design capabilities that AI agents can use safely and reliably.
Security and GRC Teams
This may become one of the fastest-growing areas.
For years, when a user runs VA01, we have designed roles around who is allowed to perform which transaction.
But what happens when an AI agent performs the transaction on the user’s behalf?
- Under whose authorization does the agent operate?
- Which actions can it perform automatically?
- When should it request human approval?
- Which user should the resulting change be attributed to?
- What should appear in the audit log?
SAP states that Joule is intended to operate within existing authorization models and audit trails. SAP’s Joule architecture also aims to associate actions with the user and role that triggered them.
As the technology matures, it would not be surprising to see topics such as Agent Access Management become increasingly
A Small but Important Detail for Türkiye: Does Joule Really Support Turkish?
One of Christian Klein’s messages at SAP Connect was that people should be able to interact with SAP in their own language.
For Türkiye, however, there is a small but important distinction.
The Joule Work mobile application supports a Turkish-language interface. In SAP Help Portal’s current documentation, Turkish is listed among the supported languages.
However, not every Joule touchpoint offers the same language coverage.
For example, Joule in the SAP BTP cockpit currently supports eight languages, and Turkish is not one of them.
SAP’s broader Joule documentation also shows that support for specific AI capabilities in Turkish is not necessarily the same thing as full interface-language support.
So, in projects in Türkiye, simply saying “Joule supports Turkish” is not enough.
Which Joule product? Which touchpoint? Which AI capability?
Language support should be verified at the project level.
This small detail points to a broader principle that applies across the SAP AI landscape: a capability described at the marketing level is not always identical to what is actually available in a specific product, version, or user experience.
Where Could the Real Turning Point Be Over the Next Few Years?
Today, the relationship between people and AI in the SAP world can be described roughly like this:
The user goes to the application, and AI assists.
The near-term future SAP is aiming for looks different:
The user expresses intent, and AI coordinates the relevant applications, data, and agents.
At a more advanced stage, in some routine business processes, people may stop initiating every single step and instead become the ones who manage exceptions and make critical decisions.
At that point, the term “Autonomous Enterprise” should not be interpreted as a company operating without people.
Processes such as financial posting, payments, production planning, recruitment, or procurement have legal, financial, and operational consequences.
So greater autonomy does not mean less need for control.
Quite possibly, the opposite is true:
As AI agents become more capable, authorization, traceability, data quality, observability, security, and human approval will become even more important.
SAP’s approach of allowing customers to define different levels of autonomy for different processes also reflects this reality.
That is why, over the next few years, the SAP agenda is likely to include not only the question “What can this agent do?” but increasingly also:
“How much of this process are we willing to leave autonomous?”
Conclusion: What Is Changing Is Not the Screen, but the Relationship Between People and the System
The major shift from SAP GUI to Fiori was largely about how users saw and interacted with SAP.
Joule Work goes further.
The division of work between SAP and the user is being redefined.
Instead of knowing which screen to start from, the user describes what they want to achieve. The system then tries to translate that intent into an outcome by bringing together data, context, applications, and agents.
If this model becomes widely adopted, the value of an SAP professional will no longer come only from knowing “where to do something in the system.”
The SAP professionals who understand the process, know what the data means, can design the architecture, configure authorizations correctly, and judge why an AI-generated outcome is right or wrong will become more valuable.
What makes Joule Work important is not that it introduces a new screen.
It may be one of the first steps toward moving the screen itself away from the center of how people work with SAP.
Frequently Asked Questions
Joule Work is SAP’s new work layer that allows users to express what they want to achieve in natural language instead of navigating through different SAP applications one by one. The goal is not simply to provide question-and-answer functionality, but to understand the user’s intent and bring together the relevant data, applications, and AI agents.
Not in the short term. SAP GUI and Fiori will continue to be used. What may change is how often users need to access these interfaces directly. Joule Work may become the starting point for certain tasks, while SAP applications continue to serve as the core systems where transactions are executed.
In today’s model, users first know which application to use, open the relevant screen, and complete the process step by step. In an intent-driven model, users describe what they want to achieve, and the system identifies the relevant data, applications, and agents needed to support the process. In other words, the focus shifts from “Which screen should I go to?” to “What outcome do I want to achieve?”
Some repetitive tasks may become automated, but this does not reduce the importance of SAP expertise. Process design and business rules may become more important for functional consultants; API design, Clean Core, and integration for developers; agent authorization and governance for Security/GRC teams; and connectivity, identity, observability, and technical governance for Basis teams.
SAP’s approach is designed for Joule and related agents to operate in alignment with existing user authorizations, data access rules, and audit trails. However, organizations will still need to define which actions can be performed automatically, where human approval is required, and how agent activity should be monitored. Agent authorization may become one of the key SAP Security and GRC topics in the coming years.
Rather than reducing the role of Basis teams, these developments may broaden their scope. For AI agents to operate securely and reliably, identity and access management, APIs and integrations, BTP connectivity, logging, performance, traceability, and error handling become even more critical. It will no longer be enough for an SAP environment to simply be operational; it will also need to be visible and governable enough for agents to work safely within it.