← Back to problem statement & principles · → Try the interactive decision tool

Reference: full decision map & tables

Decision map

flowchart TD
    A["New integration request"] --> Z{"Does a Capability API
already exist for this data/domain,
OR could more than one consumer
ever need it — app, web, partner,
OR another backend system?"}

    Z -- "Yes — reusable / already exists" --> F{"Which layer is
being built or reused?"}
    Z -- "No — genuinely bilateral,
one-off, operational sync only" --> B{"Confirm: no external-facing
consumer today or foreseeable
(app, web, partner, AI agent)"}

    B -- "Confirmed — true A2A" --> C{"Is at least one endpoint SAP,
with a native adapter or
accelerator advantage?
(IDoc / BAPI / RFC / prebuilt content)"}
    B -- "Consumer surfaces later
→ re-route to Capability API" --> F

    C -- "Yes" --> D["Build in SAP CI
A2A — no external consumer,
no API catalog entry needed"]
    C -- "No
e.g. Salesforce ↔ Workday" --> E["Build in MuleSoft
A2A, platform-agnostic default"]

    F -- "Capability API" --> G{"Source system = SAP,
and SAP CI already has /
can cheaply build native
OData or REST exposure?"}
    G -- "Yes" --> H["Build connectivity in SAP CI
(OData / REST)
↓
Front with MuleSoft
API Manager proxy
governance, auth, catalog entry"]
    G -- "No
e.g. Salesforce-origin" --> I["Build natively in MuleSoft"]

    F -- "Orchestration API" --> J["Always MuleSoft
composes multiple Capability APIs,
platform-agnostic by design"]

    F -- "Experience API" --> K["Always MuleSoft
web / mobile / partner /
MCP-agent channel"]

    classDef sap fill:#0a6ed1,stroke:#075aad,color:#ffffff,font-size:13px;
    classDef mule fill:#00a3e0,stroke:#0080b0,color:#ffffff,font-size:13px;
    classDef both fill:#6b46c1,stroke:#553497,color:#ffffff,font-size:13px;
    classDef q fill:#f7f8fa,stroke:#8a94a3,color:#1a1a1a,font-size:13px;
    classDef start fill:#1a1a1a,stroke:#000000,color:#ffffff,font-size:13px;

    class A start
    class Z,B,C,F,G q
    class D sap
    class E,I,J,K mule
    class H both

Legend: 🔵 SAP CI builds  ·  🟦 MuleSoft builds  ·  🟣 SAP CI + MuleSoft (build + front)  ·  ⬜ Decision point

---

Reference table

Scenario	Build in	Notes
SAP ↔ SAP internal sync	SAP CI	Native IDoc/ALE/change-pointer support, no external consumer
SAP ↔ Salesforce backend replication (no app/web consumer)	SAP CI	SAP-side leverage still applies even though Salesforce is the other endpoint
Salesforce ↔ Workday (or any non-SAP pair)	MuleSoft	No SAP-native advantage exists for either endpoint
Capability API over SAP (billing, etc.)	SAP CI + MuleSoft	SAP CI exposes OData/REST; Mule API Manager fronts it for governance/catalog
Capability API over Salesforce (CRM, etc.)	MuleSoft	Mature native Salesforce connector, no reason to route through SAP CI
Orchestration API (cross-capability business process)	MuleSoft	Always — stays platform-agnostic regardless of what built the capabilities beneath it
Experience API (web, mobile, partner, MCP/agent)	MuleSoft	Always — channel-facing layer, never built in SAP CI

Capability registry — the enforcement mechanism

A short, living list of business capabilities and their APIs. Anyone proposing an A2A flow checks this list first. Already listed → mandatory reuse. Not listed and genuinely uncertain whether a second consumer will ever exist → default to registering it, since retrofitting a private pipe into a governed API later is far more expensive.

Capability	Capability API owner	Known consumers
Billing	MuleSoft (fronting SAP CI OData)	Mobile app, Web, Salesforce
Customer / CRM	MuleSoft (native Salesforce connector)	Mobile app, Web, SAP (if needed)
Workforce Management	MuleSoft	Web, field ops app
— add rows as new capabilities are registered —

---

← Back to problem statement & principles · → Try the interactive decision tool