CRM Integration Services in India

Why Does Your CRM Stop Being Trustworthy Three Months After Go-Live?

The launch went fine. Records moved across, the sync ran, the dashboards populated, everyone signed off. Then somebody searches for a customer and finds four of them. One has the open opportunity, one has the support tickets, one has the billing address, and the fourth has an unsubscribe on it that nobody can explain. Sales stops trusting the search box. Within a month people are back in spreadsheets, and the CRM is a place where data goes to be re-entered rather than a place anyone reads.

This is what makes CRM integration a different job from wiring two APIs together. The technical connection is the easy half. A competent engineer can move contacts from a form into Salesforce in an afternoon. The hard half is that a CRM is a shared model of who your customers are, and every system you connect has a slightly different opinion about what a customer is. Your marketing platform thinks in email addresses. Your billing system thinks in legal entities. Your support desk thinks in whoever raised the ticket. Your CRM thinks in Accounts and Contacts, and none of those four things line up cleanly.

So the failures cluster in the same places every time. Duplicates, because two systems disagreed about whether two records are the same person. Overwrites, because both sides could write the same field and nobody decided who wins. Loops, because a change in system A triggered a write to system B, which echoed back to A. Silent field truncation, because a picklist gained a value on one side and the other side had nowhere to put it. Consent that stopped travelling with the record, which is a compliance problem rather than a data quality one. And attribution that quietly detaches, so the pipeline report and the ad spend report tell different stories and finance stops believing either.

None of that shows up in a connector test. The sync is green. The records moved. What broke is meaning, and meaning has to be designed before it can be transported.

The cost is worth stating plainly, because it rarely appears on anyone's budget line. Sales reps spend time re-keying and de-duplicating instead of selling. Marketing sends to addresses that should have been suppressed. Forecast accuracy drops because opportunities sit on the wrong account. Somebody builds a spreadsheet to work around the CRM, then a second spreadsheet to reconcile the first, and the organisation now has three versions of the truth and a meeting every week to argue about which one is right.

Duplicates and Merges: The Hardest Problem in CRM Integration

If you only fix one thing, fix this. Duplicate handling is where CRM integration stops being a data movement exercise and becomes a judgement problem, and it is the reason two competent teams can build the same integration and get wildly different results.

Why exact matching fails immediately

Email address looks like a perfect key until you meet reality. People change jobs and keep the record. Shared inboxes like info@ and accounts@ get attached to a dozen humans. Plus addressing means sarah+newsletter@ and sarah@ are the same mailbox but not the same string. Gmail ignores dots in the local part, so s.mith@gmail.com and smith@gmail.com deliver to one person. Company matching is worse: Acme Ltd, Acme Limited, ACME LTD and Acme Ltd. are one company, and the last one has a trailing period that will defeat a string comparison forever.

Why fuzzy matching fails differently

Loosen the rule and you start merging people who should stay separate. Two engineers called David Chen at the same company. A father and son at a family business sharing a landline. Two branches of a franchise that are legally distinct and buy independently.

A false merge costs far more than a false duplicate. A duplicate is annoying. A bad merge destroys data that is hard to reconstruct. In HubSpot, merges cannot be undone. In Salesforce, merged records leave the losing record deleted with its fields discarded, and while you can recover from the recycle bin for a limited period, the field level survivorship decisions are gone.

The rule set that holds up in practice

We build matching in tiers rather than as a single rule. A deterministic tier handles the cases you can be certain about: matching on a normalised email, on a source system identifier, on a company registration number, on a verified domain. A probabilistic tier handles the rest with weighted scoring across normalised name, normalised domain, phone in E.164 format and address components, using a distance measure rather than equality. Then a threshold band in the middle where nothing merges automatically and a human decides. That band is where the value is. Teams that try to eliminate it end up with either duplicates or damage.

Normalisation does most of the work

Before any matching runs, both sides get normalised the same way. Lowercase and trim email. Strip plus addressing where the domain supports it. Reduce company names by removing legal suffixes and punctuation. Convert phone numbers to E.164 so that 020 7946 0000 and +442079460000 compare equal. Reduce free email domains to a flag rather than a match signal, because matching two contacts because they both use gmail.com is how you merge strangers. Most of the accuracy comes from normalisation, not from a clever algorithm.

Survivorship: what wins, field by field

Choosing which record survives is only the start. The interesting question is which value wins for each field. Most recent non-empty is a reasonable default for contact details. Most complete wins for address. The value from the system of record wins for anything that system owns. Consent is a special case: the most restrictive value always wins, because a merge that resurrects an unsubscribed address is a compliance incident rather than a data quality one. And the child records need a decision too. Activities, notes, opportunities and cases have to be reparented rather than lost, and in Salesforce a merge brings related records to the master while some fields on the losing records simply go.

Platform specifics that change the design

Salesforce gives you matching rules and duplicate rules as configuration, with fuzzy methods available on name and account fields, plus duplicate jobs for finding existing duplicate sets in bulk. The merge API handles a master and up to two others at a time, so mass cleanup is an orchestrated loop rather than a single call. HubSpot deduplicates contacts primarily on email and companies on domain, and will auto-associate on that basis whether you wanted it to or not. Dynamics 365 has duplicate detection rules and detection jobs, but for writes coming through the API duplicate detection is suppressed by default, which surprises teams who assume their published rules are protecting them. Knowing that difference before you build is worth more than any tool.

Salesforce Specifics: Limits, APIs, Events and Deploys

Salesforce is a multi-tenant platform with hard boundaries, and integrations that ignore them work in a sandbox with a hundred records and fail in production on the first real load. The constraints are documented and stable, so there is no excuse for meeting them by accident.

Governor limits and why your trigger dies at scale

Apex runs inside a transaction with caps on SOQL queries, DML statements, records processed per DML, CPU time and heap. The number that catches people is not the cap itself but the fact that a trigger receives records in batches. Code written as though it handles one record at a time issues one query per record, and at two hundred records it hits the query limit and the whole transaction fails. Bulkification is not an optimisation, it is a correctness requirement. The same applies to anything invoked by an integration: a synchronous callout chain that works for a single record will fall over the moment a data load arrives.

Choosing between REST, Bulk API 2.0 and streaming

These are not interchangeable and picking wrong is the most common architectural mistake we see. REST and SOAP are synchronous and suit interactive volumes, with sObject Collections and the composite endpoints letting you fold multiple operations into fewer calls, which matters because your org has a 24 hour API request allocation derived from edition and licence count. Bulk API 2.0 is asynchronous and built for volume, taking a CSV upload and processing it in the background with its own separate allocation, which is what a nightly load or a migration should use. Streaming is the other direction entirely: Change Data Capture and Platform Events push changes out to you rather than making you poll. If your integration polls Salesforce every five minutes asking what changed, you are burning your API allocation to discover that nothing did.

Platform Events and Change Data Capture

Change Data Capture emits an event whenever a record changes, with a header carrying the change type, the fields that changed and the user who committed the change. That last field is the single most useful thing in the payload for a two-way integration, because it lets you ignore echoes of your own writes. Platform Events are for the cases where you want to publish an explicit business event rather than a row change, and they let you decouple the publisher from the consumer. Both use a replay identifier so a subscriber that goes offline can resume from where it stopped, within the retention window the platform provides. Build the replay handling on day one. Reconnecting from the current position and silently losing an hour of changes is a bug that shows up as a data quality complaint weeks later.

Sandboxes, and the refresh interval nobody plans around

Developer and Developer Pro sandboxes contain metadata without production data and can be refreshed daily. Partial Copy carries a sample of data and refreshes less often. Full sandboxes carry everything and have a much longer refresh interval, which is the constraint that catches integration projects: if a Full sandbox refresh takes you out of a realistic test environment for weeks, the test plan has to account for it before the project starts, not when someone asks for a refresh. We plan sandbox usage in week one, including which environment carries data volumes realistic enough to catch limit problems.

Metadata deploys and the test coverage gate

Anything you build has to reach production through change sets, the Salesforce CLI with source-tracked deploys, or packaged metadata. Apex deployed to production has to meet the platform's test coverage requirement, and that requirement is checked at deploy time, which means the deployment fails at the worst possible moment if the tests were an afterthought. We write Apex tests alongside the code, keep metadata in version control rather than clicking in production, and rehearse the deploy in a sandbox that matches production configuration.

The integration user, and least privilege

Integrations should authenticate as a dedicated user with a profile scoped to exactly what they touch, using a connected app and OAuth rather than a shared password. Named credentials keep the secret out of your code. The dedicated user matters for a second reason: it makes every write attributable, so loop suppression, audit and troubleshooting all become straightforward. Running an integration as a departing administrator's account is how a sync stops one Monday for reasons nobody can explain.

Dynamics 365 and Dataverse: Where the Model Differs

Dynamics 365 sits on Dataverse, which is closer to a relational database with a security model bolted on than to either of the other two platforms. That difference works in your favour for integration, provided you use it.

Alternate keys make upserts genuinely idempotent

Dataverse lets you define an alternate key on a table using one or more columns, then address a row by that key instead of by its internal identifier. Combined with the Web API upsert, this gives you an integration that can be replayed as many times as you like without creating a second row. If you build one thing before anything else in a Dynamics integration, build the alternate key on your source system identifier. Almost every duplicate problem in Dynamics traces back to an integration that had to search first and then decide, because searching and deciding is not atomic and two concurrent runs will both decide to create.

Service protection limits and the 429 you should expect

Microsoft publishes service protection limits per user per web server, covering the number of requests in a five minute sliding window, the combined execution time in that window, and the number of concurrent requests. Exceeding them returns a 429 with a Retry-After header, and the correct behaviour is to honour that header rather than to spread the same work across more threads. Teams that respond to throttling by increasing parallelism make the problem worse. The right answers are batching through $batch, spreading long-running work across a longer window, and using an application user rather than piling everything onto one named account.

Plugins, the execution pipeline and depth

Business logic in Dynamics often lives in plugins registered against pipeline stages, running before validation, before the operation or after it, synchronously or asynchronously. Synchronous plugins run inside the caller's transaction and are subject to a two minute execution ceiling, so a plugin that calls an external service is a design decision with consequences for every integration write. The execution context also carries a depth counter, and the platform stops runaway recursion once depth passes its limit. Relying on that limit as your loop protection is a bad idea, because it stops the loop by failing the operation, which means data is left half written.

Choice columns and integer values

Dataverse choice columns store integer values behind their labels, and integrations that map on the label break the first time somebody edits the text. Map on the integer, read the option set metadata at deploy time, and fail the build when a mapped option no longer exists rather than discovering it in production.

Solutions and environment strategy

Customisations travel as solutions, managed for anything promoted between environments and unmanaged only in development. Layering matters: an unmanaged change in production sits on top of everything and cannot be removed cleanly, which is how a Dynamics environment becomes undeployable. We keep development in its own environment, promote through test, and deploy with Power Platform pipelines or Azure DevOps rather than by exporting a zip file and hoping.

Field Mapping, Picklist Drift and the Slow Corruption of a Schema

Field mapping sounds like the boring part. It is the part that decays, and the decay is invisible until somebody runs a report and the numbers are wrong in a way nobody can explain.

Picklist drift

The scenario repeats across every platform. An administrator adds a new value to a dropdown in the CRM because a sales manager asked for it in a meeting. The integration has a mapping table that does not know about the new value. Now every record with that value either fails validation, which at least is visible, or silently falls into a default bucket, which is not. Six months later the pipeline report shows a category with an implausible count and nobody can reconstruct what happened.

The mechanical fix is to read the option set or property definition from the platform API at build time and at deploy time, compare it against the mapping, and fail the pipeline when there is a value with nowhere to go. That turns an invisible data quality problem into a build failure on the day the change was made. The organisational fix is a named owner for picklist changes on both sides, which is harder and matters more.

Type coercion and the values that look fine

Currency stored as a decimal on one side and a string with a symbol on the other. Dates stored as dates in one system and as date-times in UTC in another, which shifts a record by a day for anyone in a timezone behind UTC and produces the classic bug where a close date drifts backwards every sync. Booleans represented as true and false in one place and as Yes and No in another. Multi-select fields stored as semicolon-delimited strings in Salesforce and as arrays elsewhere. None of these are hard. All of them are silent when they go wrong.

Blank, null and the difference between them

The single most damaging mapping decision is what an empty incoming value means. If it means clear the target field, then any source system that does not populate a field will wipe it on the other side. We default to ignoring blanks and treating clearing as an explicit instruction, then list the exceptions where a genuine clear has to propagate.

Getting this backwards is how a company loses three years of account notes in one overnight run.

Field limits and truncation

Text fields have different maximum lengths across platforms, and an integration that truncates without complaining is corrupting data politely. Long descriptions, addresses with several lines, and anything pasted from a document are the usual casualties. Validate length before writing and route the overflow somewhere rather than trimming it. Salesforce also limits how many fields per object can carry history tracking, so if your audit story depends on field history, you need to choose which fields matter rather than assuming everything is tracked.

Attribution Data and Why Your Pipeline Report Disagrees With Your Ad Spend

Marketing attribution lives or dies on whether the source information stays attached to the record through every hop. It usually does not, and the breakage happens in predictable places.

Where the source data gets lost

The first touch is captured on a form fill with UTM parameters and a click identifier. Then the contact fills in a second form, the integration updates the record, and the source fields get overwritten with the newer, less interesting values. Or the record gets merged and the surviving record keeps its own blank source field. Or a lead converts and the custom source fields were never mapped to the contact and account, so the history is sitting on a converted lead nobody queries. Each of these is a one-line decision in the mapping document, and each of them silently detaches your reporting from reality.

First touch and last touch are different fields

Store both, write first touch once and never again, and let last touch update freely. HubSpot maintains its own original source properties on the contact, which are set at creation and behave differently from properties you populate yourself, so an integration that writes over them is fighting the platform. On the Salesforce side, campaign influence gives you a model for multi-touch, but it only works if campaign membership is actually created when the touch happens rather than reconstructed later from a spreadsheet.

Offline conversions close the loop

The reason this matters commercially is that ad platforms optimise on the conversions you send back. Storing the click identifier on the record at capture, then sending a conversion event when the deal closes, is what lets the platform learn which clicks produce revenue rather than which produce form fills. That requires the identifier to survive every merge, conversion and sync in between, and it requires the upload to happen inside the platform's lookback window, which is bounded and worth checking against current documentation for whichever ad platform you use before you design around it.

Reconciliation as a habit

The practical test is simple. Take last month's closed won opportunities, trace each one back to a first touch, and count how many you cannot. If the answer is more than a few, the attribution chain is broken somewhere specific and findable. We run that check as part of the build rather than leaving it as a reporting problem for someone else to discover.

Should You Build the Integration or Buy an iPaaS?

There is no universally right answer, and the deciding factor is not technical. It is who maintains the thing after the project ends.

The case for a platform

Workato, Boomi, MuleSoft, Tray and Celigo all give you connectors, retry handling, an error console and a visual view of what ran. The real value is that a revenue operations lead can look at a failed run, read the error and retry it without opening a ticket with engineering. If your integration is owned by an operations team rather than a development team, that alone justifies the licence. Native connectors have a place too: the packaged Salesforce integration inside HubSpot handles straightforward field sync perfectly well, and building a custom replacement for it is usually a waste.

The case for code

Custom code gives you version control, tests, code review, and behaviour you can specify exactly. Complex survivorship logic, multi-tier matching and anything with genuine business rules in it tends to be easier to express in a language than in a canvas of connected boxes. There is no per-task billing, so a high volume sync does not get more expensive as you grow. And there is no ceiling: when a platform cannot express something, you are stuck, whereas code just gets a new function.

The case for warehouse-first, which is increasingly the right one

If your data already lands in Snowflake or BigQuery, the identity resolution can happen there where you have full SQL, proper testing with a tool like dbt, and history you can query. The CRM then becomes a destination rather than a participant in a mesh of point-to-point syncs. Reverse ETL tools such as Hightouch and Census exist for exactly this shape. It is more infrastructure up front and it fixes the duplicate problem at the root, because matching runs once in a place designed for it instead of separately inside every connector.

How we usually decide

Low volume, standard objects, operations-owned: buy the platform. Complex matching, real business logic, engineering-owned: write the code. Existing warehouse and more than three systems in play: do identity resolution in the warehouse and push out. We will tell you which of those you are before we quote anything, including when the answer is that your native connector is fine and the real problem is your matching rules.

How We Run CRM Delivery From India

This work touches your production customer data, so the delivery model matters as much as the engineering. Here is how it runs, including the parts that are inconvenient.

The overlap window, honestly

A standard Indian working day of 09:30 to 18:30 IST gives London roughly 09:00 to 14:00 local, which is a comfortable four to five hours depending on the time of year. Sydney gets about 14:00 to 17:30 their time, so their afternoon. Auckland gets an hour or two at the end of their day and less again during their summer. For US Eastern the honest answer is that a standard IST day is almost entirely outside your working hours, and for Pacific it is entirely outside them. Nobody should pretend otherwise.

There are two ways to deal with that, and both cost something. Shifting the team later, so the day runs into the evening in India, buys a genuine morning overlap with the US East Coast. That is a real imposition on the people doing it and needs to be agreed rather than assumed. The alternative is to run written-first and treat overlap as a bonus, which works well for build work and badly for anything requiring live decisions. We agree the window and any shift pattern with you before work starts, and we write it down.

What written-first actually means here

Every decision that shapes the integration lands in a document before it lands in code: the object model table, the field mapping, the matching rules, the survivorship rules. Those documents are the interface between your team and ours, and they are how a question asked at 17:00 in New York gets answered by 09:00 the next morning without a meeting. Daily written handover covering progress made, anything stuck, and any call that needs your input, posted where your team already reads.

Sandboxes, access and the production question

Build happens in your sandbox or development environment using a scoped integration user, never with an administrator credential shared over chat. Salesforce access through a connected app with the profile limited to the objects in scope. HubSpot through a private app with only the required scopes. Dynamics through an application user with a security role built for the integration. Production access is separate, requested explicitly, and used in a scheduled window. Where your policy requires it, we work through your VPN or jump host and on your device standards.

Review gates before anything touches live data

Code review by your engineers, not just ours. A dry run in a sandbox with production-like volumes, because a matching rule that behaves on two thousand records can behave differently on two hundred thousand. A sampled comparison of before and after for any bulk update. And for merges, an approval step with a human in it, because merges in most platforms are difficult or impossible to reverse.

Cutover, and the day after

Cutovers get scheduled in your business hours, not ours, which usually means an early start or a late finish for the India team. There is a written rollback plan, a delta load for anything that changed during the freeze, and a defined period of monitoring after go-live with someone watching the error queue. Commercial arrangements including notice, team composition and support terms are agreed with you directly and written into the MSA before work starts.

Risks We Name Before You Sign

Some of these will apply to you. It is better to hear them now than in week six.

Your existing data quality sets the ceiling

If the source system has thirty percent duplicates and half the company names are typed inconsistently, no matching rule will produce a clean result. Cleanup is a workstream with its own effort, and it needs someone on your side who can make decisions about which record is right. We can automate the mechanics. We cannot decide which of two conflicting addresses is your customer's actual address.

Discovery usually finds more systems than you listed

Almost every engagement turns up an integration nobody mentioned: a Zapier automation someone in marketing built two years ago, a spreadsheet upload that runs monthly, an old connector still writing to a field that was supposed to be retired. These have to be found before you build, because an unknown writer will fight your integration and win at unpredictable intervals.

Licences and edition limits are real constraints

Custom objects, API allocations, sandbox types, marketing contact tiers and various platform features are gated by edition and licence count. Discovering mid-build that a design needs a subscription tier you do not have is an avoidable delay. We check entitlements in week one and design inside them, or tell you plainly what a design would require.

Time zones cost coordination, not quality

The overlap arithmetic above is the honest version. Build work does not need overlap. Decisions do, and decisions that wait a day accumulate. The projects that run smoothly are the ones where one person on your side can decide, or where decisions get batched into the overlap window deliberately rather than arriving one at a time.

Vendor platform changes will happen mid-project

API versions get deprecated, connectors change behaviour, and a platform release can alter something you depend on. We pin API versions explicitly, subscribe to the release notes for the platforms in scope, and treat a deprecation notice as a scheduled piece of work rather than an emergency.

Where This Sits Alongside Our Other Work

CRM integration rarely arrives alone. Where the CRM is one node in a wider estate that includes an ERP, a billing platform and a warehouse, the design question is broader than any single connector and belongs with our enterprise integration services. If the CRM is one of several systems being moved off ageing infrastructure at the same time, sequencing matters, and that work overlaps with cloud migration services in India, particularly where the system feeding the CRM is the thing that actually needs replacing.

Once the sync exists, keeping it honest is a testing problem as much as a build one, and the contract between your CRM and everything writing to it is worth covering properly through API testing services in India, particularly the schema and error path cases that break quietly. And if what you need is engineers inside your team rather than a scoped engagement, hiring dedicated .NET developers in India suits a Dynamics and Dataverse estate, while Node.js developers in India fit teams building middleware around HubSpot and Salesforce APIs.