Salesforce, the ERP and the claims system agree on who the customer is.
Integration problems show up as a customer with two addresses or an invoice that never reached the CRM. We connect operational systems to each other and to your data platform, and we decide up front which system owns each field.
CRMSalesforce · Dynamics 365ERP and billingorders · invoicesClaims systemTriZetto Facets
02 · Integration layer
APIs and middlewareretries · dead-letter queuesCDC and connectorsFivetran · Openflow · Fabric mirroring
03 · Data platform
Data platformSnowflake · Databricks · FabricIdentity resolutioncontact · login · customer · member
04 · Activation
Reverse ETLscores · segments · attributes
SnowflakeDatabricksMicrosoft FabricSalesforce
in short·15-second read
Data integration connects source systems so data moves between them and into a central platform reliably.
Cohash integrates CRM, ERP, healthcare claims and SaaS data using managed connectors such as Fivetran and Snowflake Openflow, change data capture, Microsoft Fabric mirroring, APIs and reverse ETL. We define system-of-record rules and identity matching so the same customer or member resolves to one record.
you probably need this if
The CRM and the ERP both think they own the address field, so your customer now has two of them.
Invoices sometimes never reach the CRM and nobody is alerted.
The warehouse is a day behind because every table is reloaded in full each night.
terms on this pageETLdefinitionStands for extract, transform, load. It's a job that copies data out of your source systems, reshapes it and drops it into a warehouse, often overnight.explained in a field note →Change data capturedefinitionStreaming every insert, update and delete out of a database's log as events, so other systems see changes as they happen.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Data Integration, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · data integration3 open
openThe CRM and the ERP both think they own the address field, so your customer now has two of them.
recurringInvoices sometimes never reach the CRM and nobody is alerted.
blockedThe warehouse is a day behind because every table is reloaded in full each night.
exposure
Source-to-platform ingestionChange data captureApplication-to-application syncSystem-of-record rulesIdentity resolutionReverse ETL
startrehearsehandover
Map
Design
Build
Operate
we are here
ready to hand over
Changes land through the day and deleted records are marked deleted.
Each member now resolves to one record with every system ID on it.
Integration inventory and target architecture
System-of-record register by field
chapter 01 · where it hurts
Why teams reach out
The CRM and the ERP both think they own the address field, so your customer now has two of them.
Invoices sometimes never reach the CRM and nobody is alerted.
The warehouse is a day behind because every table is reloaded in full each night.
chapter 02 · what we change
How we solve it
Source-to-platform ingestion
Change data capture
Application-to-application sync
System-of-record rules
Identity resolution
Reverse ETL
chapter 03 · how it runs
Our approach
Map
Design
Build
Operate
chapter 04 · where you end up
What changes
Changes land through the day and deleted records are marked deleted.
Each member now resolves to one record with every system ID on it.
Integration inventory and target architecture
System-of-record register by field
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Managed connectors for SaaS and databases, Snowflake Openflow or Fabric mirroring where they fit, and custom extracts for systems without good connectors.
We read changes from operational database logs with CDC. The warehouse reflects them within minutes, and nightly full reloads go away.
We connect CRM, ERP and billing via APIs or the middleware you already run, with retries, dead-letter handling and alerts when things stick.
We keep a field-by-field register of which system owns each value. Without it, two integrations end up overwriting each other.
We write matching rules that tie a CRM contact, a CIAM login and an ERP customer, or a member across Facets and partner systems, to a single key.
We push scores, segments and enriched attributes back out of the warehouse into Salesforce or Dynamics 365, in front of the people who act on them.
capability 01 / 06in production
Source-to-platform ingestion
Managed connectors for SaaS and databases, Snowflake Openflow or Fabric mirroring where they fit, and custom extracts for systems without good connectors.
We pieced these together from Data Integration situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Salesforce data reaching the warehouse in one nightly full extract
composite · not a client story
Beforethe situation
Account and Opportunity data comes over in a nightly full extract via the Bulk API. The job now runs into the business day. Records deleted in Salesforce never make it across, so closed accounts keep turning up in reports.
What we dothe work
We move high-change objects to Change Data Capture and persist the last replay ID, so a dropped subscriber resumes inside the 72-hour window. Deletes arrive as soft-delete flags. A scheduled job counts records per object on both sides and flags any gap for resync.
Afterwhere you end up
Changes land through the day and deleted records are marked deleted. Event streams drop things sometimes. Reconciliation catches that before a sales manager does.
case file 02
Four IDs for one member across Facets, the service CRM and the portal
composite · not a client story
Beforethe situation
Member data sits in TriZetto Facets, in the service CRM and in the member portal's CIAM tenant. Each system minted its own ID. Matching relies on name and date of birth, and call center agents regularly open the wrong record.
What we dothe work
Field ownership comes first, beginning with address, phone and email. Subscriber ID plus member suffix drives deterministic matching. Whatever is left goes through probabilistic matching into a data steward's queue. A cross-reference table keeps every system's ID for each member.
Afterwhere you end up
Each member now resolves to one record with every system ID on it. Conflicting updates are settled by the ownership rules instead of by whichever system wrote last.
How operational systems sync with each other and with the data platform
CRM, ERP and claims systems exchange records through APIs or middleware, with a system-of-record rule for each field. CDC, mirroring and connectors copy changes into the platform, identity resolution links records to one key, and reverse ETL pushes results back.
ERP and billing → CDC and connectors: log-based CDC
Claims system → CDC and connectors: claims extracts
CDC and connectors → Data platform: change data
Data platform → Identity resolution: match records
Identity resolution → Reverse ETL: resolved keys
Reverse ETL → CRM: write back fields
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Map
Systems, interfaces, data owners and current failure points catalogued.
step 02
Design
We agree integration patterns, system-of-record rules, matching logic and error handling with the people who own each system.
step 03
Build
Integrations go live in priority order. Each one has monitoring and reconciliation checks.
step 04
Operate
We hand the support team alerting, reconciliation reports and runbooks for every integration.
you keep
What you're left with
We write these for your Data Integration setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Data integration engineer
Data engineer
EDI developer (X12)
Change data capture engineer
CRM data integration developer
due diligence · data integration
Questions to ask any partner, including us.
Put these to anyone bidding on your Data Integration work. The ones who've done it answer differently from the ones who've read about it.
Q1
For each shared entity, which system owns each field, and who signed that off?
Two-way syncs without field-level ownership overwrite good data with stale data. Ask to see the system-of-record register before anything is built.
Q2
How are deletes and record merges in the source carried downstream?
Many connectors handle inserts and updates well and deletes badly. Merged CRM accounts and hard deletes are where warehouse counts drift.
Q3
Say the CDC subscriber is down longer than the source retains changes. What then?
Salesforce keeps change events for 72 hours, and database logs roll over too. There should be a documented resync path that doesn't need a full reload.
Q4
Once this is live, how will you reconcile counts and totals between source and target, and how often?
A job that ran is not the same as data that matches. Scheduled reconciliation is what catches silently dropped records.
Q5
Which of our integrations run as named service identities, and who owns those credentials?
Auditors keep finding the same thing in Salesforce and ERP systems, integration users with admin profiles and passwords nobody has changed in years.
01Do we need middleware like MuleSoft or Azure Integration Services?
Not always. A few point-to-point syncs can live on platform-native tools. Once many systems swap the same entities, middleware pays off. We count your integrations and look at your team's skills first.
02How fresh can warehouse data be?
That depends on the source and how we connect it. Scheduled connectors are slowest, CDC gets changes over within minutes, streaming goes further. Freshness costs money, so we only buy as much as the business needs.
03Can you integrate our identity data with the CRM?
Yes. Linking CIAM identities, workforce directory data and CRM records is a regular part of our work, and it is where duplicate customers usually start.
04Do you work with healthcare data standards?
Yes. We map payer data to FHIR resources for CMS interoperability APIs, alongside the warehouse integration.
05Can you use Salesforce Change Data Capture instead of nightly extracts?
Yes, for objects that change a lot. Salesforce holds change events on the event bus for 72 hours. Our subscriber saves the last replay ID and picks up from there after a disconnect. Anything longer than that needs a resync through the API, and we build that path in from day one.
related
Often paired with
Projects on Data Integration usually end up touching one of these, so they're worth a look.
