Varad
If you have started planning a Joule rollout across your SAP landscape, you have probably already discovered that the documentation assumes you know more than you actually do. Activating Joule in a single sandbox system is one thing. Rolling it out properly across development, quality assurance, and production is a completely different exercise, and the gap between those two experiences catches a lot of Basis teams off guard. This guide walks through what an actual three system Joule rollout looks like, where teams typically stumble, and how to plan a landscape strategy that holds up once you are staring down a production cutover deadline.
Most of what gets written about Joule online focuses on what it can do once it is running. Conversational queries, generative summaries, AI agents that handle invoice disputes or expense validation on their own. That is the exciting part. But none of it works reliably unless the underlying landscape plumbing between your SAP Business Technology Platform subaccounts and your S4HANA systems is configured correctly, and configured consistently, across every stage of your landscape.
Why Landscape Strategy Matters More With Joule Than With Most BTP Services
A lot of BTP services are relatively forgiving if you cut corners in non production environments. Joule is less forgiving, mainly because it sits directly on top of business data and depends heavily on identity propagation working correctly. If your development system, quality system, and production system are not each wired up with their own clean subaccount structure, you end up with confusing failures that are hard to diagnose. Users get partial functionality. Some Joule skills respond and others silently fail. Authorization errors show up that have nothing to do with the actual role assignments.
The other reason landscape discipline matters so much here is that Joule configuration touches several different layers at once. You are dealing with BTP subaccounts, Cloud Identity Services, principal propagation through the cloud connector, OData service activation, Fiori catalogs, and authorization roles, all of which need to be consistent across DEV, QAS, and PRD or you will spend weeks chasing inconsistent behavior between environments.
The Three System Landscape Explained
Most enterprise SAP customers run on a classic three system landscape: a development system where configuration and customization happen, a quality assurance system where changes get validated before they touch anything customers depend on, and a production system that runs the actual business. Joule needs to be activated and configured separately in each of these, even though a lot of the underlying setup, like activating the right business catalogs, only happens once in development and then moves downstream through transports.
Development System
This is where the real configuration work happens. You activate the OData services that Joule skills depend on, generate the technical and business catalogs needed for Fiori based authorization, and capture all of that in transport requests. Every catalog and authorization object that QAS and production will eventually need gets created here first. Trying to configure things directly in QAS or production instead of transporting them downstream is one of the more common mistakes teams make, usually because someone is in a hurry to get a demo working and forgets to go back and do it properly through the transport layer afterward.
Quality Assurance System
QAS exists to catch the problems before they reach production, and with Joule that mostly means catching authorization gaps and connectivity issues. After transports land in QAS, you still need to manually verify that ICF services tied to the OData activations actually came alive, because transport import does not always trigger that automatically. This is one of those small details that trips people up because everything looks correct on paper, the transport shows as successfully imported, yet the service simply does not respond until someone manually activates it through transaction SICF.
Production System
Production is where the stakes go up considerably. By the time you get here, your catalogs and authorization roles should already be flowing in cleanly through transports rather than being configured fresh. What does need direct attention in production is the cloud connector and principal propagation setup, since these involve certificates and connectivity parameters that are specific to each environment and cannot simply be copied over from QAS. Anyone who has dealt with a CERTRULE mismatch during a production cutover knows exactly how much time this single step can eat if it is left until the last minute.
Subaccount Structure: One of the First Decisions You Will Make
One of the earliest architectural decisions in a Joule rollout is how many BTP subaccounts to create for non production environments. The common approach is to set up two separate subaccounts, one tied to development and one tied to quality assurance, so that the subscriptions and services for each environment stay cleanly separated and easy to manage independently.
Where this gets a little more nuanced is around Cloud Identity Services. Because CIS only needs a single connectivity service and identity management benefits from being centralized, many teams choose to run one shared CIS tenant across both non production subaccounts rather than duplicating it. This keeps user provisioning and authentication consistent without doubling the administrative overhead of maintaining two separate identity tenants for environments that do not need that level of separation.
There is an alternative path worth knowing about if your landscape is smaller or your team prefers fewer moving parts. Instead of standing up a dedicated CIS subaccount, you can fold Cloud Identity Services directly into the individual development and quality subaccounts. The tradeoff is that you then need to create the remote function call for the identity service from the development subaccount pointed specifically at the quality system whenever you configure the source system connection inside IAS. It works fine, but it does require a bit more manual care when wiring up the connection since you are pointing identity services across systems rather than keeping that relationship centralized.
Getting Authorizations Right Across All Three Systems
Joule depends heavily on the standard Fiori based role model that most SAP customers already have in place. If your finance users already have the roles they need for their daily Fiori apps, they are usually most of the way toward having what Joule requires too, since Joule rides on top of those same authorization structures rather than introducing an entirely separate permission model.
That said, do not assume this transfers automatically without verification. Pull a full list of the relevant roles from your security team early in the project rather than partway through testing, and confirm that those roles are actually exposed to BTP consistently across development, quality, and production. It is common for a role to exist correctly in one system and be missing a key authorization object in another simply because of drift that built up over time, long before anyone was thinking about Joule.
A practical tip that saves real time later: loop your security team into the project formally rather than treating authorization as something you will sort out yourself along the way. Getting their buy in early, and having them validate role exposure across all three systems before user acceptance testing begins, prevents a lot of last minute scrambling when business users start reporting that Joule only partially works for them.
Principal Propagation and the Cloud Connector
This is the part of the setup that tends to bite teams hardest in production, mainly because it cannot be fully tested until you are actually pointed at the production backend. Principal propagation needs to be configured correctly in the cloud connector for both your non production and production environments, and the configuration is not identical between them because the certificates and connectivity parameters are specific to each target system.
During a production cutover, build in dedicated time to verify the relevant parameters and certificates rather than assuming that what worked in QAS will simply carry over. Checking the CERTRULE configuration and confirming certificate validity against the production system ahead of go live, rather than during go live, is one of the simplest ways to avoid an unplanned fire drill in front of business stakeholders.
Practical Tips for a Smoother Rollout
Treat the development system as the single source of truth for every catalog, role, and OData activation, and resist the temptation to configure anything directly in QAS or production. Everything downstream should arrive as a transport, not as a manual fix.
After every transport import into QAS or production, manually check that the related ICF services are actually active rather than trusting that the import alone took care of it. This single verification step catches a surprising number of issues before they reach end users.
Get your security team involved from week one rather than week eight. Authorization gaps are by far the most common cause of partial Joule functionality, and they are far easier to catch with a coordinated review than through scattered user complaints after go live.
Schedule dedicated time before production cutover specifically for cloud connector and principal propagation verification. Do not bundle this into the same window as your final transport imports, since troubleshooting certificate issues under deadline pressure is a worse experience for everyone involved.
Document your subaccount and CIS tenant structure clearly, especially if you choose the shared tenant approach for non production environments. Future team members, or even future you six months from now, will need to understand why the landscape was built this way without having to reverse engineer it from BTP cockpit screenshots.
Where This Is Heading
SAP’s broader direction with Joule is moving quickly toward agentic capabilities and tools like Joule Studio that let teams build and deploy their own custom agents on top of the existing platform. None of that changes the fundamentals covered here. If anything, it raises the stakes for getting your landscape foundation right the first time, since every custom agent or workflow built on top of Joule inherits whatever landscape inconsistencies already exist underneath it.
Getting a three system Joule landscape right is not glamorous work. It is transport requests, ICF activation checks, and certificate verification, the kind of detail oriented Basis work that rarely gets mentioned in product announcements. But it is exactly this groundwork that determines whether your Joule rollout feels solid and dependable to end users or becomes a source of confusing, inconsistent behavior that erodes trust in the tool before it has a chance to prove its value. Take the time to get development, quality, and production aligned properly, and everything SAP builds on top of Joule going forward will have a much better foundation to stand on.
