SAP and Salesforce together hold a large fraction of operational data in mid-market and enterprise companies: ERP data in SAP, CRM data in Salesforce. When an AI agent needs to reason about a customer's contract status, invoice history, and open service tickets simultaneously, it needs to query both. Getting that integration right is harder than it looks, and the failures are not random. They follow patterns that are predictable and preventable.
This article is a technical walkthrough of the specific patterns that make SAP and Salesforce connectors stable. We are not covering the happy path. We are covering what breaks in production and how connector architecture prevents it.
Why SAP is not just another database
SAP ERP data is not structured like a relational database designed for direct querying. It is organized around business objects, and the tables that store those objects follow naming conventions that change across SAP versions and configuration namespaces. A material master record might live in MARA for general data and MARC for plant-specific data, with cross-references maintained through a separate key structure. A customer record spans KNA1 (general data) and KNB1 (company code-specific data).
A connector that treats SAP as a generic SQL source and constructs raw table queries will work in development against a specific SAP version and configuration. It will break when the production instance runs a different ERP version, or when a client-specific namespace modifies the field layout, or when the SAP admin creates a custom enhancement that adds fields to a standard table. These are not edge cases. They are normal conditions in any large SAP installation.
The right approach uses SAP's BAPIs (Business Application Programming Interfaces) and RFCs (Remote Function Calls) rather than direct table access. BAPIs are stable, version-tolerant interfaces to SAP business objects. A connector that queries customer data via BAPI_CUSTOMER_GETDETAIL2 instead of direct KNA1 table access gets version stability and authorization check integration for free.
Salesforce schema drift is a constant
Salesforce schema changes happen frequently in production orgs. Administrators add custom fields regularly. Managed package upgrades add entire field namespaces. Picklist values get renamed or deprecated. Record type configurations change what fields are visible in a given context. An integration that cached field definitions at setup time will serve stale field mappings to the agent after any of these changes.
The specific failure mode is usually subtle. If a picklist field's API name stays the same but its allowed values change, queries that filter on a deprecated value return no results rather than an error. The agent receives an empty result set and draws incorrect inferences, with no error signal. This is harder to catch in monitoring than a connection failure.
The mitigation is schema-aware connection management. At connection time, the connector should call the Salesforce describeSObjects API for the object types it will query and compare the live field definitions against the registered schema fingerprint. If a field has been removed or a picklist value set has changed, the connector surfaces a schema drift event rather than proceeding with a potentially incorrect query.
Credential patterns for production use
SAP and Salesforce both support service account patterns, but the right setup differs between them. For SAP RFC connections, the service account should be configured with authorization objects scoped to the specific BAPIs the connector will use. Authorization object S_RFC with function group restrictions limits the blast radius if the credential is compromised.
For Salesforce, connected app OAuth with a named credential is the standard. The connected app should be configured with a permission set that grants the minimum object and field permissions required. Using a named credential, rather than embedding the client secret in connector configuration, keeps the credential out of configuration management and CI/CD pipelines.
In both cases, the credential should be held by the connector infrastructure, not visible to the AI agent or its orchestration layer. Credential rotation should happen at the connector layer without requiring changes to agent configuration.
Cross-system identity resolution
A frequent practical challenge when combining SAP and Salesforce data is identity resolution: matching a customer record in SAP to the corresponding account in Salesforce. These systems typically use different primary key structures. SAP customer numbers do not automatically correspond to Salesforce account IDs.
The common approach is a mapping table maintained outside both systems, synchronized as part of the CRM-ERP integration. Some organizations store the SAP customer number as a custom field on the Salesforce Account object, which allows the connector to query Salesforce for the SAP ID and use it to look up ERP data. Others maintain an external identity map in a relational database that the connector queries as a join step.
Either approach works, but it must be treated as a first-class part of the connector configuration, not as ad hoc query logic inside the agent prompt. The mapping is a data dependency. If it drifts (SAP accounts merged, Salesforce account restructured), queries that rely on it produce wrong results. Tracking the mapping as a managed resource with its own schema fingerprint and validation step is the same principle applied to identity resolution as to field definitions.
What this means for agent prompt design
One consequence of building reliable SAP and Salesforce connectors is that agents can be designed to query context by business intent rather than by schema detail. Instead of constructing a query that specifies table names and field paths, the agent requests "customer financial standing" or "open opportunities above threshold X" and the connector translates that to the appropriate BAPI calls or SOQL queries.
This separation is not just an API design preference. It is what makes the integration maintainable when the underlying systems change. If the Salesforce admin restructures the opportunity object, the connector's query logic is updated in one place. The agent's reasoning about what data it needs remains stable. Without that boundary, every schema change in the source system potentially requires changes to agent prompts or orchestration logic.
