--- title: "SAP and Salesforce: AI Integration Clash" author: "Daniel Gorld" author_role: "Consulting Director, cbs CX — The cbs Group Salesforce Consultancy" author_url: "https://cx-waves.com/about" publisher: "CX-Waves" canonical_url: "https://cx-waves.com/nodes/sap-salesforce-ai-integration-clash" date_published: 2026-06-01 date_modified: 2026-09-20 language: en --- # SAP and Salesforce: AI Integration Clash Source: Daniel Gorld, CX-Waves — https://cx-waves.com/nodes/sap-salesforce-ai-integration-clash (published 2026-06-01, updated 2026-09-20) ## What are the conflicting AI strategies of Salesforce and SAP and how do they impact enterprise integration projects? * **Salesforce Strategy: Open API Access (Headless 360)** Salesforce has adopted an "open platform" approach with Headless 360, making all platform data, workflows, and business logic accessible via APIs, MCP tools, or CLI commands. This strategy allows AI agents to directly interact with the Salesforce platform without human intervention, effectively repositioning Salesforce from a system of record to a system of execution. * **SAP Strategy: Restricted API Access (Joule-centric)** In contrast, SAP's updated API policy v4/2026 prohibits direct use of SAP APIs by "semi-autonomous or generative AI systems that plan, select, or execute sequences of API calls." Agentic use cases are funneled exclusively through Joule, SAP's proprietary AI system, positioning Joule as the mandatory orchestration layer for all AI interactions with SAP systems. * **Impact on Integration: Architectural Clash** This divergence creates a significant architectural clash for enterprises using both platforms. Salesforce enables direct agent action, while SAP mandates mediation through its own AI, forcing companies to implement a supplementary layer (Joule) for any cross-platform agentic workflows involving SAP data, increasing complexity and potential latency. * **Impact on Integration: Licensing and Compliance Risks** Companies are at risk of breaching SAP's terms of use if their AI architectures involve direct API calls from third-party agents to SAP. This necessitates a legal and licensing review of existing and planned AI integrations, as non-compliance can lead to formal constraints and contractual violations. ## Two Platforms, Two Strategies - and Your Integration Project Is Caught in the Middle Salesforce and SAP have implemented divergent strategies regarding AI integration, with significant implications for enterprises utilizing both systems. While both companies envision an "Agentic Enterprise," their recent platform decisions in April and May 2026 illustrate fundamentally different approaches to how AI agents should interact with their respective ecosystems. This strategic split has direct consequences for integration projects and architectural design. ## What Salesforce Announced: The Platform Becomes Infrastructure On April 15, 2026, Salesforce unveiled Headless 360 at its TDX developer conference, marking a major platform shift. This initiative makes all elements of the Salesforce platform—data, workflows, and business logic—directly accessible via APIs, MCP tools, or CLI commands. The core idea is that an AI agent can interact with Salesforce without requiring a browser, user interface, or human navigation. This shift represents a significant structural change. For 25 years, Salesforce operated primarily as a system designed for human users. Headless 360 transforms it into a system capable of being operated by agents. The release includes over 60 new MCP tools and more than 30 preconfigured coding skills, compatible with various MCP-enabled agent frameworks like Claude Code, Cursor, and Windsurf. This means an external agent can directly trigger a Salesforce Flow, create a record, or run a report with a single, deterministic, and auditable call, eliminating the need for proprietary middleware. Analysts view this move as Salesforce repositioning itself from a system of record to a system of execution. ## What SAP Decided: The Boundary Stays Closed Conversely, SAP introduced an updated API policy at the end of April 2026. Section 2.2.2 of API Policy v4/2026 explicitly prohibits the use of SAP APIs for "interaction or integration with (semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls." This policy means that any third-party agent, including those from Agentforce, directly accessing SAP APIs is in violation of the terms of use. The only sanctioned method for agentic interactions is through the Agent-to-Agent (A2A) interface provided by Joule, SAP's internal AI system. SAP CEO Christian Klein clarified during a Q1 investor call that the policy's intention is to safeguard SAP's proprietary domain knowledge and prevent performance degradation from unregulated agent traffic, rather than to restrict customer data access. Despite this, the policy text remains unchanged. The DSAG, a major SAP user association, has formally objected to the policy, seeking clarification, particularly in light of the EU Data Act which since September 2025 grants customers greater rights over their data in connected systems. At Sapphire 2026, SAP presented Joule not as a barrier, but as an interface within its vision of an "Autonomous Enterprise." The company showcased over 50 Joule assistants orchestrating more than 200 specialized agents across various business functions, including finance, supply chain, HR, procurement, and customer experience. Joule Work, a new user experience layer designed to operate across diverse landscapes—including non-SAP systems—is scheduled for general availability in Q4 2026. SAP's message emphasizes its intent to serve as the central orchestration hub, not merely a data backend. ## The Legitimate Argument — and the Commercial Calculus SAP's stance is supported by legitimate operational concerns. Systems like S/4HANA manage critical processes such as financial closes, supply chains, and payroll, where even slight inaccuracies are unacceptable. An uncontrolled AI agent executing numerous API calls in a loop could significantly degrade the performance of a multi-tenant platform. This constitutes a valid operational risk, making SAP's argument for infrastructure protection defensible. However, this policy creates a notable asymmetry. SAP's own products, such as Joule, Business Data Cloud, and Agent Gateway, are exempt from these restrictions. Consequently, third-party AI offerings like Microsoft Copilot, Salesforce Einstein, and other agentic vendors that have developed SAP connectors now face formal limitations. SAP's internal AI products, however, remain unrestricted. Analysts and consultants have observed that this policy effectively intertwines competitive positioning with governance. While the fairness of this assessment is debatable, the critical fact for organizations designing their AI architecture today is this inherent asymmetry. ## What This Means for Projects — A Practitioner’s View From a project execution standpoint, this strategic divergence is a concrete architectural challenge rather than an abstract discussion. In specific industries like manufacturing, essential data—such as inventory levels, production orders, supplier terms, and quality records—typically resides within SAP. When an Agentforce agent operating in a service or sales context requires this data to function effectively, it encounters a pre-established architectural constraint. This situation presents three immediate consequences for current and future projects. Firstly, any AI architecture that relies on direct API calls from Agentforce into SAP must undergo a thorough review, both legally and from a licensing perspective, regardless of its technical feasibility. Secondly, routing requests through Joule introduces additional complexity and potential latency. Organizations opting for A2A via Joule must account for an extra layer, with its own governance requirements, operational overhead, and cost implications. Thirdly, the most robust solution, independent of the policy debate, involves establishing a strong integration layer to extract data from SAP into a managed, agent-readable downstream source. This approach is not merely a workaround but represents an optimal architecture for heterogeneous system landscapes. This broader pattern highlights a growing trend: as enterprise platforms integrate their own AI layers, determining which agents are authorized to access specific data, and under what conditions, will become a standard design consideration in implementation projects. This concern intersects licensing, architecture, and process design, making it a critical consulting challenge. ## What Decision-Makers Should Do Now SAP’s API Policy v4/2026 is a pivotal strategic development that impacts every AI roadmap decision concerning SAP environments. It is not merely a technical footnote for IT architects. Three critical steps are recommended for decision-makers. First, conduct a comprehensive audit of all current and planned AI integrations. Identify any patterns that involve direct access to SAP APIs, whether today or in future roadmaps, and evaluate them against the new policy. Second, clarify the licensing implications with SAP and your licensing advisor before establishing architectural dependencies on potentially non-permitted patterns. Third, design your integration architecture to ensure agents consume data from a stable, governed downstream source, rather than directly from the ERP system. This strategy not only reduces reliance on any single vendor’s access policies but also enhances the long-term resilience of the architecture. Salesforce is actively opening its platform, while SAP is deliberately securing its boundaries. Both are strategic decisions. The crucial question for enterprises is whether their AI architecture is aligned with these divergent strategies before their first production agent encounters these limitations.