Salesforce integrations: ERP, telephony, data and AI services
One pattern per data flow, not one pattern for everything. REST, Platform Events, Change Data Capture, Bulk API 2.0, MuleSoft or custom middleware, with idempotency, retries and monitoring designed in.
We are Salesforce implementation specialists inside an AI-first engineering firm. We connect the CRM to finance, telephony, data platforms and the LLM services that increasingly sit next to them. We build those links to survive bad days.
Quote-to-cash across CRM and ERP
Accounts, products, prices, orders and invoices consistent in both systems, with a clear owner for every field.
Telephony in the console
Screen pops, click-to-dial, call logging and recordings linked to the case, with transcripts ready for summarisation.
Most integration failures come from using one pattern for everything. Polling REST for changes burns API calls; pushing a million rows through Platform Events burns allocations. Match the pattern to the flow.
Pattern
Best for
Latency
Volume
Effort
REST and SOAP APIs (request and reply)
Lookups and updates where the caller needs an answer now: credit checks, address validation, price lookups
Real-time
Low to medium, counted against API allocation
Low to medium
Apex callouts (outbound)
Salesforce calling ERP, pricing, LLM or MCP services from Flow or Apex
Real-time
Low to medium
Medium
Platform Events (publish and subscribe)
Decoupled notifications: order shipped, case escalated, agent finished a task
Near real-time
Medium to high, within daily allocation
Medium
Change Data Capture
Streaming record changes to warehouses and search indexes without polling
Near real-time
High, per selected object
Medium
Bulk API 2.0
Nightly loads, migrations, backfills of millions of rows
Batch, minutes to hours
Very high
Low to medium
MuleSoft
Many systems, reusable APIs, an integration team and enterprise governance
Real-time or batch
High
High, plus licence
Custom middleware (Node.js or Python)
A handful of flows, bespoke mapping, LLM steps inside the pipeline
Real-time or batch
Medium to high
Medium
Topology
What a typical mid-market Salesforce estate looks like once it is wired up
Each edge uses the pattern that suits its latency and volume. The ERP sits behind middleware that owns mapping and retries. The warehouse is fed by streams, not polling. AI services are tools the CRM can call.
Common targets
Systems we connect most often
ERP and finance
SAP, NetSuite, Dynamics, Sage and bespoke systems. Accounts, products, price books, orders, invoices and credit status, with the ERP as the system of record for money.
Telephony and CTI
Open CTI adapters for cloud contact-centre platforms: screen pop on inbound, click-to-dial, call outcomes on the activity, recordings and transcripts attached to the case.
Data warehouse and BI
Change Data Capture into Snowflake, BigQuery, Postgres or Azure, with a nightly Bulk API reconciliation. Clean inputs for reporting and for the features behind predictive analytics.
Marketing and e-commerce
Marketing Cloud, HubSpot, Shopify and custom storefronts. Consent and preferences kept in one place; orders and web behaviour arriving as events the sales team can act on.
LLM and agent services
Case summarisation, email drafting, document extraction and grounded answers from an enterprise RAG service, exposed as MCP tools and called from Flow, Apex or Agentforce.
Event platforms and legacy systems
Our own Eventify platform, ticketing tools and bespoke systems with no modern API. Attendees, leads and sessions land as Contacts, Leads and Campaign Members.
Resilience
Designed for the day the other system is down
Every integration works on the demo. The question is what happens when the ERP times out at month-end, the warehouse rejects a batch, or the same order arrives twice. We answer that in design, not in the incident review.
Writes are idempotent: upserts keyed on external IDs, so a retry cannot create a duplicate. Retries use exponential backoff with a cap, then land in a dead-letter queue that someone owns. Platform Event subscribers store the last replay ID so they can resume after an outage within the retention window. Every message carries a correlation ID from source to destination.
Monitoring is part of the build: a dashboard of flows, volumes, failures and lag, with alerts tied to the API allocation and the backlog. When something breaks, the person on call sees which record, which system and which step.
One system of record per field, documented
Upserts on external IDs; retries never duplicate
Exponential backoff, then a dead-letter queue with an owner
Replay IDs stored so subscribers resume after outages
Correlation IDs end to end for tracing
Stale-write protection using timestamps or versions
Dashboard and alerts for volume, failures, lag and API usage
Process
From system inventory to monitored production
A single well-documented integration takes 4–8 weeks. An estate with ERP, telephony, warehouse and an AI service runs 10–16 weeks, delivered flow by flow so value lands early.
Inventory
Systems, objects, fields, volumes, owners and the current failure modes. One week.
Contract
Pattern per flow, field mapping, system of record, error handling and the API budget, signed off.
Build
Middleware or Apex, Named Credentials, events, with contract tests against mocked endpoints.
Test
Volume tests at real data sizes, failure injection, replay drills, reconciliation reports.
Cut over
Historical backfill through Bulk API, then live flows switched on behind a feature flag. See data migration.
Monitor
Dashboards, alerts and a two-to-four week hypercare period, then handover or managed service.
What goes wrong
Integration failures we are usually called in to fix
Polling every minute for changes, exhausting the API allocation by lunchtime
Two systems both writing the same field, each "correcting" the other
Retries that create duplicate orders because nothing was keyed on an external ID
Triggers making callouts synchronously, so a slow ERP blocks users saving records
No dead-letter queue, so failed messages vanish and nobody notices for weeks
Credentials in custom settings instead of Named Credentials
Not necessarily. MuleSoft earns its licence when you have many systems, reusable APIs and an integration team to run it. For a handful of flows, custom middleware on Node.js or Python, hosted on Cloudflare Workers or Azure, is cheaper to build and run. We show you both costed before you decide.
How do you avoid hitting Salesforce API limits?
By choosing the pattern per flow. Change Data Capture and Platform Events push changes out without polling. Bulk API 2.0 moves large volumes in few calls. Composite requests batch related writes. We model daily call volume against your edition's allocation during design and alert well before the ceiling.
How do you stop two systems overwriting each other?
Every field has one system of record, written down. Writes use external IDs and upserts so retries are safe. Updates carry a timestamp or version, and the integration refuses stale writes. Conflicts are logged and surfaced, never silently resolved.
Can Salesforce call our AI services directly?
Yes. Apex and Flow can call an external LLM, RAG or agent service through a Named Credential, and Agentforce actions can do the same. We usually expose those services through an MCP server so the same tools work from Salesforce, a portal and an internal assistant.
How long does a typical ERP integration take?
Accounts, orders and invoices against an ERP with a documented API usually take 4–8 weeks including testing and cut-over. Custom or ageing ERPs, complex pricing or multi-currency add time. We give a range after a one-week discovery, not before.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.