Source mapping
Which systems hold which entities, and which one is authoritative.
Integrations & data migration
A core system cannot work alone — and it cannot work on data nobody trusts.
We connect Salesforce to the systems the organization already runs, define clear interface contracts, and migrate historical data through a controlled process with full reconciliation.
Data Flow Topology
How data enters, is governed and is consumed
Every stable integration starts with deciding which system is authoritative for each entity. Everything else — protocol, frequency and tooling — follows from that.
Data Flow Topology
Source systems
Where the data comes from
- ERP & finance systems
- Website, forms & campaigns
- Contact center & service channels
- Operational systems
Contract & control layer
What is governed before entry
- Interface contractfields, format, ownership
- Identity key & idempotency
- Validation & data quality
- Retry, logging & monitoring
Salesforce & consumption
Where data becomes a decision
- Core data model
- Automation & processes
- Reports & dashboards
- Agentforce on governed data
System types
What can be connected
- ERP
- Finance & accounting systems
- Websites & forms
- Marketing automation
- Telephony & CTI
- WhatsApp & messaging channels
- Service systems
- BI & data warehouse
- Operational systems
- HR systems
- Document & e-signature systems
- Internal APIs
- Webhooks
The connection itself is almost never the hard part. The hard part is deciding who owns each field, what happens when two systems update the same value, and how a failure is detected before users detect it.
Integration patterns
Chosen by failure tolerance, not by convenience
| Pattern | When it fits | Typical example | What to watch |
|---|---|---|---|
| Request–Reply | You need an immediate answer before the process continues | Stock or credit check while creating an order | Direct dependency on target-system availability |
| Fire and Forget | The update matters but does not block the process | Pushing a status update to a reporting system | Needs retry and monitoring |
| Batch Sync | High volume, low sensitivity to freshness | Nightly catalog or pricing sync | Freshness gaps between systems |
| Event-Driven | Several consumers for the same business event | Publishing 'order approved' to multiple systems | Requires schema and event-ordering management |
| Data Virtualization | Viewing data without copying it | Showing billing history from an external system | Performance depends on the external source |
Request–Reply
- When it fits
- You need an immediate answer before the process continues
- Typical example
- Stock or credit check while creating an order
- What to watch
- Direct dependency on target-system availability
Fire and Forget
- When it fits
- The update matters but does not block the process
- Typical example
- Pushing a status update to a reporting system
- What to watch
- Needs retry and monitoring
Batch Sync
- When it fits
- High volume, low sensitivity to freshness
- Typical example
- Nightly catalog or pricing sync
- What to watch
- Freshness gaps between systems
Event-Driven
- When it fits
- Several consumers for the same business event
- Typical example
- Publishing 'order approved' to multiple systems
- What to watch
- Requires schema and event-ordering management
Data Virtualization
- When it fits
- Viewing data without copying it
- Typical example
- Showing billing history from an external system
- What to watch
- Performance depends on the external source
Data migration
Ten controlled steps
Data profiling
Measuring completeness, duplication, irregular formats and missing history.
Cleansing rules
What is fixed automatically, what needs a business decision and what does not migrate.
Mapping
Field by field, including transformations and default values.
Identity key
A unique business key per entity to prevent duplicates on repeat loads.
Trial load
A full load into a test environment at real volumes.
Validation
Count, sum and sample checks against the source.
Reconciliation
A formal comparison and an approved gap list.
Final load
A planned cutover window with a defined rollback point.
Ongoing control
Data-quality metrics that keep running after go-live.
Life after go-live
An integration is a system you have to operate
Integration Operations Loop
- 01
Monitoring
Measuring successes, failures and response times per interface.
- 02
Alerting
A failure crossing a threshold raises an alert to a named process owner.
- 03
Handling & fix
Controlled retry, documented manual correction and root-cause analysis.
- 04
Adjustment
Updating the interface contract or the business rule, and recording the change.
↻ The cycle repeats — each round feeds the prioritization of the next
Continue from here
Related services & guides
- CRM architecture
- Data Cloud & data unification
- Development & automation
- Salesforce implementation
- Guide: Salesforce integration patterns
- Guide: Salesforce data migration
- Guide: Connecting Salesforce to ERP
- Guide: Integration error handling
- Guide: Defining a source of truth
- Guide: Preventing duplicates in Salesforce
FAQ
Integrations & data — questions we hear often
When do you choose real-time integration and when batch?
The decisive question is what happens if the data arrives an hour late. If the consequence is a wrong decision in front of a customer, real time is required. If the consequence is a slightly less current report, batch is cheaper, more stable and easier to maintain. A common combination is real time for core entities and batch for enrichment and corrections.
What is an interface contract and why is it critical?
An interface contract defines in writing which system is the source, which fields move, in what format, what happens on failure, what uniquely identifies a record and who owns changes. Without one, every update on one side breaks the other and nobody knows why. It is the document that prevents most real-world integration failures.
How do you prevent duplicates during migration?
You define a business identity key for each entity before loading, run data profiling to see the real scale of duplication, decide an explicit merge rule, and run a trial load into a test environment. Only after the trial passes full reconciliation is the final load executed.
What do you do when the source system is unreliable?
You do not hide the problem behind an integration. You define the acceptable quality range, filter or flag records that fall outside it, and define a correction process on the source side. Moving broken data into Salesforce simply transfers the distrust to the new system.
How long does a data migration take?
Duration is driven by source quality, not volume. A million clean records with a clear key are far faster than a hundred thousand records with duplicates and partial history. That is why profiling happens early, before any timeline is committed.
Do we need a dedicated integration platform?
Not always. For a handful of stable interfaces, an approach based on APIs and platform events is enough. A dedicated platform justifies itself when there are many systems, complex transformations, centralized monitoring requirements or a need to reuse logic across processes.
Next step
Plan an integration or migration
We will map the systems, the sources of truth and the required quality level — and build a plan you can actually deliver.