When we talk to SAP customers that are new to the Microsoft Power Platform, the conversation tends to start with a fair amount of skepticism. Indeed, when it comes to discussions around opening up SAP environments to external platforms like Power Apps, Power Automate, or Power BI, we often hear a pause…followed by questions such as:
"Why not just stick with SAP’s own technology solutions?"
"What are the security risks?"
"How difficult will the integration be and will it impact upgrades?"
"Will this disrupt critical business processes or workflows?"
While we've debated the "Why Power Platform?" topic extensively in this space, the integration and security concerns are completely understandable. SAP systems are, in so many ways, the digital backbone of a business—responsible for managing critical processes, data, and operations. So, the idea of “opening the gates” to another platform can sound risky, especially when those gates have been firmly closed for years.
Therefore, in this guide, we’ll look to demystify the process of connecting Microsoft Power Platform to SAP. Whether you’re looking to build low-code apps that interact with your SAP data, automate manual tasks, or supercharge analytics with Power BI, we’ll show you how seamless—and secure—these connections can be.
Welcome to Microsoft Power Platform & SAP: Connectivity 101. Let’s break down the barriers and help you embrace the best of both worlds.
Understanding SAP Connectivity Options
Before we dive into Power Platform specifics, it's first helpful to understand the basics of SAP connectivity. At its core, SAP systems support two primary communication protocols: Remote Function Calls (RFCs) and web services based on the REST-based OData protocol. There are also a few SOAP services (or enterprise services in SAP parlance) lying around, but those are mostly used for application-to-application (A2A) style integration.
RFCs and BAPIs
Remote Function Calls (RFCs) are SAP’s traditional communication mechanism, allowing both internal and external systems to execute remote-enabled functions hosted in SAP environments. Most of these RFCs are written in ABAP and widely used for synchronous data exchange and process integration, especially in older SAP Business Suite systems like ECC.
Before web services came on the scene in the early 2000s, SAP relied on RFCs as the standard method for system integration. Building on this foundation, SAP introduced a specialized flavor of RFC-based APIs known as Business Application Programming Interfaces (BAPIs), which provide a more structured and standardized (not to mention backwards-compatible) way to interact with SAP business objects.
As you can see in Figure 1 below, SAP has a large catalog of BAPIs available for would-be consumers like the Power Platform. If you search within this catalog, you can find APIs to:
Maintain master data objects like materials and customers
Post journal entries and other financial transactions
Create transactional documents like sales orders or purchase orders
And so much more
Figure 1: Working with SAP Standard BAPI Functions
OData APIs
OData-based REST APIs represent a more modern and flexible approach to SAP connectivity. These APIs, often hosted on the SAP Gateway framework integrated into SAP NetWeaver, provide a standardized way to expose SAP data and processes as web services. OData is particularly useful for integrating with modern platforms, as it’s widely supported and adheres to open standards. Indeed, any programming environment with an HTTP client can consume OData services.
OData APIs are the lifeblood of SAP Fiori apps and a huge part of SAP's modern S/4 HANA development strategy: the so-called ABAP RESTful Application Programming model (or RAP). These days, it's easier than ever to build and expose OData APIs using Core Data Services (CDS) and related technologies.
OData APIs also play a vital role in SAP's clean core and side-by-side extension philosophy. These days, you're seeing OData APIs being consumed more and more outside of SAP backend systems (whether they're on S/4 HANA or ECC) via the SAP Business Technology Platform (SAP BTP) and/or other cloud platforms like Microsoft Azure and AWS.
Figure 2: Consuming OData Services from SAP BTP Applications
RFCs vs. OData APIs
Whether you utilize RFCs/BAPIs or OData services (or both) for your integration needs is mostly a matter of preference—and availability. If you're running a legacy SAP ECC system for example, then there may not be many standard OData services lying around. Of course, you can always create your own OData services using SAP Gateway, but if those services are essentially just wrappers around BAPIs, that might be overkill.
On the other hand, if you're running a more modern S/4 HANA system or a heavy adopter of SAP Fiori technology, then you probably have plenty of OData services that you can leverage. In fact, we would encourage you to explore the Business Accelerator Hub to discover all the services you have at your disposal.
One final note on this topic: while RFCs and BAPIs are time-tested and reliable, they do come with some baggage. For context, it's worth mentioning that SAP's RFC protocol is based on the old mainframe CPIC protocol. So, there are some SAP proprietary details to work through here. We'll unpack all this in the upcoming sections.
Microsoft SAP Connector Overview
Microsoft provides two primary connectors: the SAP ERP Connector and the SAP OData Connector. These connectors are purpose-built to support the key communication methods we discussed earlier—RFCs/BAPIs and OData—enabling seamless integration with SAP backend systems.
SAP ERP Connector
The SAP ERP Connector is designed for scenarios where you want to consume RFCs or BAPIs from within the Power Platform. This connector allows you to execute SAP business logic, retrieve data, or trigger transactions directly from Power Platform tools like Power Apps, Power Automate, and Copilot Studio.
Figure 3 illustrates how to access the SAP ERP connector from within the Power Apps Studio. Here, you simply create a connection to your backend SAP system and then choose the target RFC function or BAPI you want to consume. Once the bindings are set, the SAP ERP connector takes care of all the low-level RFC protocol details, passing you back a PowerFx-friendly JSON representation of the RFC response. From there, it's business as usual within Power Apps or whatever Power Platform service you're connected to.
Figure 3: Working with the SAP ERP Connector in Power Apps
SAP OData Connector
As the name suggests, the SAP OData Connector enables you to consume REST-based OData services hosted in SAP Gateway or SAP HANA. It also supports consumption of OData services hosted in SAP SuccessFactors.
As you can see in Figure 4 below, the SAP OData Connector enables you to consume OData services hosted in the cloud or in your on-premises SAP systems. Apart from the SAP connection details, this connector works in much the same way as the more generic OData connector and is easily integrated into PowerFx expressions and bindings.
Figure 4: Working with the SAP OData Connector in Power Apps
Power BI Connectors
If you're wanting to consume SAP data directly from Power BI to create custom reports and dashboards, you have several connectors to choose from:
SAP BW Connector: This connector is used to consume BW cubes from your SAP Business Warehouse systems. See this link for more details.
SAP HANA Connector: This connector is used to consume various HANA development objects (e.g., calculation views). See this link for more details.
OData Connector: Power BI also provides a generic OData connector that can be used to consume OData services hosted in SAP.
Zooming out from individual Power BI reports, Microsoft also offers a suite of SAP Connectors that enable large-scale data replication using tools like Azure Data Factory or Microsoft Fabric. This is a much broader topic and beyond the scope of this article, but Ulrich Christ published some excellent content on this topic here. You can also see a live demo of Microsoft's SAP CDC connector in the video link below.
Connecting to On-Premises SAP Systems
Microsoft’s approach to connecting on-premises SAP systems to the Power Platform closely mirrors the architecture that SAP customers have already blessed with SAP BTP. As you can see in Figure 3 below, just as SAP’s Cloud Connector provides a secure bridge between on-premises systems and the SAP cloud (BTP), Microsoft’s On-Premises Data Gateway does the same for Power Platform services such as Power Apps, Power Automate, and Power BI.
Figure 3: SAP vs. Microsoft Power Platform Connectivity: Side-by-Side Comparison
Looking closely at Figure 3, you can see that both solutions follow a similar architecture—outbound-only TLS-encrypted tunnels ensure secure communication between on-premises SAP systems and cloud services. This means no inbound ports need to be opened in your corporate firewall. Data flows securely back-and-forth through this encrypted channel, ensuring that sensitive SAP information remains protected at all times.
Building on SAP NCo
If you're already working with services like Power BI, it's possible that you already have an On-Premises Data Gateway instance installed within your landscape. In that case, the only requirement to connect to SAP is to install the SAP Connector for .NET onto your gateway host(s) as described in this article.
Security Overview
When connecting Microsoft Power Platform to SAP systems, addressing security concerns is a top priority. Fortunately, both of Microsoft's standard SAP connectors support robust authentication options that align with SAP’s enterprise-grade security standards. In this section, we'll break this down and also touch on some other relevant security topics.
SAP Authentication Options
Both the SAP ERP and SAP OData connector support two different authentication options:
Basic Authentication: In this scenario, a connection is created using a system account (i.e., communication user in SAP parlance) which processes requests anonymously behind the scenes. For example, we might have a PP_USER user account setup in SAP that's used to process API requests from Power Apps.
Principal Propagation: In this scenario, we're talking about single sign-on (SSO) where the user that's logged onto Power Apps is mapped to their corresponding user account in SAP. Behind the scenes, the SSO is facilitated in SAP using the SAP Secure Network Communications (SNC) technology that's used for SSO with the SAP GUI client. See the connector overview articles for more details on how this works.
Since nothing makes SAP security teams more nervous than having to provision system (i.e., communication user) accounts with elevated permissions to call APIs on behalf of a wide variety of users, we normally recommend going with the principal propagation option when building interactive apps in Power Apps. Of course, for behind-the-scenes workflows in Power Automate, you always have the option of provisioning an SAP communication user account with limited authorizations.
A key takeaway from all this is that the Microsoft SAP connectors DO NOT open up widespread access to APIs from SAP backend systems. In particular, we should note that:
SAP system connections are established through secure tunnels (whether in the cloud or on-premises).
SAP security administrators have fine-grained control through SAP's role-based authorization concept (RBAC) over what users connected from the Power Platform are able to see and do.
Access to APIs (both RFCs and OData services) can be enforced as per usual using SAP authorization objects and the activation of services within the Internet Communication Framework (ICF).
Additional security controls can be established through the use of API management services - which we'll cover next.
API Management
In addition to the built-in security controls within the Power Platform and corresponding SAP connectors, you can apply further protections to backend APIs using tools like SAP API Management (SAP APIM) as part of the SAP Integration Suite or Azure API Management—the latter of which plays very nicely with the Power Platform.
With API management, you can enforce policies to restrict access, ensuring the Power Platform can only interact with APIs secured through API management. Figure 4 below illustrates how all these pieces come together within Azure APIM.
Figure 4: Controlling Access to SAP APIs Using Azure API Management
Data Loss Prevention
A common concern we hear from customers is, “How do we restrict access to SAP connectors in the Power Platform?” It’s a valid question—SAP systems hold critical business data and processes, so unrestricted access isn’t an option. Fortunately, Microsoft provides built-in data governance tools like Data Loss Prevention (DLP) policies to address this specific concern.
DLP policies allow administrators to enforce strict controls over which connectors can be used and by whom within specific Power Platform environments. By classifying SAP connectors—like the SAP ERP and OData connectors—as “business-specific” or “blocked” connectors, organizations can ensure that only authorized makers and developers have access to SAP systems. This prevents the connectors from being used in untrusted environments or alongside non-approved services, mitigating the risk of unauthorized data leaks.
Figure 5: Restricting Access to SAP Connectors Using DLP Policies
In practice, DLP policies act like a gatekeeper for SAP connectivity. They ensure that access is tightly managed and aligned with governance standards, giving organizations confidence that their SAP systems won’t become a free-for-all. With this level of control, businesses can empower their developers to innovate while keeping SAP data secure and protected.
Looking at the Big Picture
As we've seen here today, when it comes to connecting SAP systems with the Microsoft Power Platform, Microsoft provides you with all the tools you need to integrate SAP systems confidently and securely.
Sometimes, customers tell us, “There are too many connection options—it’s overwhelming!” But here’s the thing—that variety is actually one of Microsoft’s biggest strengths. Think of these connectors like tools in your tool bag—each one has a specific job to do. Need to automate an SAP process? There’s a tool for that. Want to build an app that taps into SAP’s business logic? Got you covered. Looking to analyze SAP data with Power BI? Easy.
As you can see in Figure 6 below, the beauty of this approach is that you’re never stuck trying to force one tool to do everything. You can pick the right option for the task at hand, giving you the flexibility to get the job done without compromising on security, performance, or simplicity.
Figure 6: Power Platform + SAP Landscape Overview (© Microsoft)
To drill in deeper on these topics, we would highly encourage you to check out Microsoft's blueprint document Architecting SAP Extensions with Microsoft Power Platform.
Closing Thoughts
Bringing SAP and Microsoft Power Platform together isn’t just about integration—it’s about unlocking new possibilities for your business. With a wide range of secure connection options, Microsoft provides the tools you need to extend the reach of your SAP systems and break down barriers that exist between systems across the organization (and beyond).
In the end, it’s not about replacing SAP—it’s about extending it. By leveraging the Power Platform, you can get more out of your SAP investments, empower your teams, and build a foundation for the future of business transformation.
