Salesforce to SAP Order Handoff Without Replacing Either System

Salesforce and SAP each do their job well. The trouble starts when a commercial commitment has to become an operational record. Someone exports an opportunity, re-keys values into SAP, or relies on a point integration nobody fully owns. When a record fails, the failure is often invisible until a customer asks where their order is.

Replacing either system is rarely justified by the handoff alone. What the handoff needs is a clear direction of flow, explicit validation, a place for exceptions and an audit trail. That is orchestration work, and it can sit between the two systems without changing either.

This article builds on the Salesforce-SAP integration pattern and walks through one run from start to finish. It avoids asserting a universal field mapping, because every Salesforce org and SAP landscape is configured differently.

Salesforce is a listed Nexus trigger source. The trigger polls new or updated records using a SOQL query you define, for example records that have reached an agreed stage. Each detected record starts a run with its data as input.

Polling has practical advantages here. The query is explicit and versioned with the workflow, so anyone can see which records qualify. The run records which records it processed, which prevents duplicate handoffs when a record is edited again.

Salesforce also appears in the actions library, with AddContactToCampaign available as a pre-built action. For reads or updates outside the pre-built action groups, the HTTP Request node can call the Salesforce API under a vault-backed credential.

• 01SOQL poll defines which records qualify
• 02Each record starts one recorded run
• 03Duplicate handoff prevented by run history
• 04Direct API available for operations outside the pre-built action groups

Rules + Code checks the record against what SAP will need: required values present, customer reference known, pricing and quantities within policy, currency consistent. The checks are written in one of the eight supported code language families and versioned with the workflow.

Records that fail validation do not go to SAP with a hope that SAP will reject them cleanly. They go to a named reviewer on the commercial or finance side, with the specific reason. The reviewer corrects the source record or approves an exception, and the run records that decision.

This is where most handoff quality comes from. SAP should receive records that are already known to be acceptable, not records that are merely present.

SAP is part of the actions library, including SAP Products, and reading an invoice is available as a pre-built operation. The SAP RFC node can call approved BAPI and RFC functions where a prebuilt action does not fit.

The call runs with defined inputs and outputs. The SAP response, including any document number or error, is captured. Errors take explicit branches: retry transient failures, route business rejections to a reviewer, and never report success on a failed call.

SOAP Request and HTTP Request nodes are also available where the SAP landscape exposes those interfaces and the SAP team prefers them.

Once SAP has accepted the record, the run can write the reference back to Salesforce so sales can see operational status without asking. Direction of flow stays explicit: Salesforce is authoritative for the commercial commitment, SAP for the operational record.

If the write-back fails, the SAP record is still valid and the failure is visible for follow-up. The execution record shows exactly which side succeeded.

Scheduled reconciliation runs can compare the two systems and flag drift, again with recorded decisions.

For any order, the execution record shows the triggering Salesforce record, the validation results, any reviewer decision, the SAP call and response, and the write-back. A finance controller can answer how an order entered SAP without reconstructing it from logs in two systems.

Nexus runs on-premises, in private or sovereign cloud, or air-gapped, and reaches Salesforce and SAP over the paths you allow. Nexus provides 1,480+ pre-built actions across 43 product families. Additional operations can use APIs, protocols, databases or Rules + Code in the same governed run.

The handoff becomes a governed process, and both systems keep their roles.