Migrating your valuable customer data and integrating it with Salesforce can be a complex and time-consuming process. Oblytech’s Data Migration & Integration services ensure a smooth and secure transition, helping your organization get the most from Salesforce’s CRM capabilities.
A load is the act of writing a set of records into Salesforce, and its design depends on three facts: how many records there are, how often the source changes while the load is running, and how quickly the receiving team needs the records to be complete. A one-off historical load of a few hundred thousand accounts has different needs from a nightly feed of orders, and a provider that proposes the same method for both is probably reusing a template. The first design decision is therefore the pattern of movement, not the tool.
Three patterns cover most of the work. A bulk batch load moves a large set of records in a defined run, usually outside working hours, and suits historical data and periodic refreshes. A record-level synchronization moves changes as they happen, and suits data that users edit in both systems or that must be current for a process. An event-driven flow sends a notification when a record changes and lets the receiver decide what to do, which suits cases where several systems need to react to the same change.
| Pattern | Fits when | Typical failure | Protection to specify |
|---|---|---|---|
| Bulk batch load | Historical data, periodic refresh, large volume with a defined window | The source changes during the run and the two sides disagree | A frozen source snapshot and a delta pass afterwards |
| Record-level synchronization | Users need current data in both systems during the same working day | A failed call is lost, or two edits overwrite each other | Retry rules, a failure queue and a defined field owner |
| Event-driven flow | Several systems must react to one change without being tightly coupled | Events arrive out of order, or a consumer silently stops | Sequence checks, consumer monitoring and a replay method |
The pattern decides what can go wrong, which is why the protections should be specified with the pattern rather than added later. A batch with no frozen snapshot will produce a reconciliation problem that no amount of testing will reveal in advance. The cutover and reconciliation decisions that surround these patterns are covered in the data quality and migration route, and the load work sits inside the wider Salesforce implementation program.
Integrations fail in predictable ways. A network call times out after the receiving system has already saved the record. A message is delivered twice. A required field is empty in the source for a reason nobody documented. The design question is not whether these failures will happen but whether the integration can recover from them without creating duplicates or losing changes. Recovery depends on two features: idempotency and traceability.
Idempotency means that sending the same record twice produces one record, not two. The usual mechanism is an external identifier, which lets the receiving side find an existing record and update it. Traceability means that every record crossing the boundary carries enough information to show where it came from and when it was last changed. Without both, a failed message becomes an investigation, and an investigation takes longer than the business is willing to wait.
Buyers should ask a provider to describe, for each flow, what happens when the receiving system is unavailable for an hour, a day, and a week. The answers reveal whether the design includes a queue, whether messages are held or dropped, and who is told. Vague answers usually mean that the failure path has not been designed.
Two-way integration is the most common source of hidden conflict. When the same field can be edited in Salesforce and in another system, the integration must decide which edit wins, and that decision should be taken per field rather than per record. A customer’s billing address may be authoritative in a finance system, while the account owner is authoritative in Salesforce. Treating the whole record as shared produces overwrites that users cannot explain.
The practical way to settle this is to write a field authority table before any flow is built. Each row names the field, the system that owns it, the systems that may read it, and the process that changes it. Where two systems need to write the same field, the table should record the precedence rule and the escalation path when the rule fails. The table is also the most useful artifact for the team that inherits the integration later. Which flows should exist at all is a prior question, and the Salesforce integration architecture page covers system authority and ownership at that level.
Many programs keep the old and new systems alive for a period, and the integration is what makes that period survivable. During coexistence, some users work in the old system, some in the new, and reports must draw from both. The integration should carry only the data that the coexistence period requires, and it should have a defined end date. An integration that was meant to be temporary and is still running a year later often has no owner and no documentation.
Where the coexisting system is a ServiceNow process, the Salesforce and ServiceNow integration boundaries must be agreed first, because a boundary that moves during coexistence is a frequent cause of duplicate work. Coexistence also changes the order of work. Records that are migrated early can be updated in the old system, and those updates must reach the new one or be reconciled. The approach should be agreed before the first load, not discovered in the first week of use.
An integration that nobody watches will eventually stop without anyone noticing. Monitoring should show the volume of records sent and received, the number of failures and their causes, the age of the oldest unprocessed message, and the time since the last successful run. Each of these measures needs an alert threshold and a named person who receives the alert. A dashboard that nobody reads is not monitoring. Where the same flows feed workflows on the ServiceNow side, the integrations and workflow orchestration page covers ServiceNow integrations and workflow orchestration, which is relevant where the same flows feed that platform.
Ownership is equally important. Each flow should have a business owner who decides what the data means, a technical owner who maintains the flow, and a support route for users who see inconsistent data. These roles are often split across the client’s teams and the provider’s team, and the split should be written down, with the handover point clearly named.
Choose the simplest pattern that meets the business need for timeliness. Many first releases work well with a scheduled batch and a single record-level flow for the data users must see during the day. Event-driven designs add value when several systems depend on the same changes, and they add complexity that a first release may not justify.
Test the failure paths as well as the success path. Disconnect the receiving system during a test run, send a duplicate record, change a field in both systems at once, and confirm that each case produces the outcome the field authority table specifies. Keep the results with the test evidence for the release.
Yes, if the identifiers, the field authority and the flow contracts are documented independently of the tool that runs them. Integrations that exist only as configuration inside one product are harder to move.
Before comparing tools, list every flow the release will need, the direction of each, the pattern you think it requires, and the system that owns each field it touches. Those four items will show quickly where the design is still vague. You can discuss your data migration and integration design.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.