Teams often ask for “a CRM integration” when they need one of several very different jobs. They may want to migrate from a legacy CRM, refresh a staged migration before cutover, keep a specialist system feeding a central CRM, or allow two operational systems to edit the same records indefinitely. The same word hides very different failure modes.
Read-only describes what a connector may do to the source: it can retrieve authorized data but cannot change that source through the granted integration. One-way describes the direction in which information moves. Repeatable means the process can run again and resolve previously imported records. Continuous sync describes an ongoing schedule or event stream. Two-way sync lets changes travel in both directions. None of these properties automatically implies another, and a product should state each one separately.
Intelligent CRM’s current HubSpot and Pipedrive connectors illustrate the distinction. Both are designed as repeatable, one-way imports into Intelligent CRM and do not change the source CRM or enable continuous synchronization. HubSpot import supports Companies, Contacts, eligible Deals, fixed standard mappings, and up to 100 compatible non-HubSpot-defined custom properties per object; a Contact keeps one prioritized Account relationship, and activities, emails, notes, tickets, and products remain excluded. Pipedrive imports organizations, people, and deals, with activities and notes available as optional history. Those bounded examples are migration tools, not promises of ongoing bidirectional parity.
Compare three common connector operating models
The useful choice follows the business operating model. More directions and faster updates create more coordination obligations as well as more capability.
| Model | Primary job | Authority pattern | Main operational risk |
|---|---|---|---|
| Repeatable read-only import | Migration, rehearsal, or controlled refresh | Source is read-only; destination receives selected records | Users assume it is live sync or expect unsupported history |
| Continuous one-way sync | Keep a destination projection current from one authoritative source | Source owns synchronized fields; destination may own separate local fields | Lag, provider outages, and unclear handling of local edits |
| Two-way sync | Let both systems participate in an ongoing process | Authority must be defined by object, field, event, or state | Loops, conflicting edits, duplicate identities, and destructive propagation |
| Event handoff | Transfer a bounded business event between systems | Each system owns its part of the workflow | Retries create duplicate work without idempotency |
| Export and manual import | One-time transfer with human review | People control each movement | Transformation drift and limited repeatability |
Define the connector in several dimensions, not one label
Document source permissions, destination writes, direction, frequency, trigger, object coverage, field coverage, identity keys, conflict rules, deletion rules, and failure recovery. A connector described only as “read-only” answers one security question and leaves the operating model unknown. It might run once, run every hour, or respond to webhooks. It might preserve destination edits or treat the source as absolute authority. Buyers and administrators need the full contract.
Use precise language in user interfaces and rollout plans. “Repeatable one-way import; the source remains unchanged; no continuous synchronization” gives an administrator a much better mental model than “connected.” State what can be imported and what cannot. If activities are optional, say so. If emails or products are out of scope, say so before a customer expects a complete historical archive. Precision reduces support burden because users can distinguish a product boundary from a failed job.
Choose import when the job is migration or rehearsal
A repeatable import is well suited to a staged migration. A team can connect the legacy CRM, discover data, map owners and fields, import a representative population, validate the result, correct configuration, and run again before cutover. The source remains the operational system until the agreed transition. The destination can be tested without asking a connector to keep two systems permanently equivalent.
Repeatability matters because migration is rarely a single clean event. A rehearsal exposes ambiguous identities, unsupported fields, relationship gaps, currency constraints, and owner mappings that need attention. A later run should use durable source-to-local links and documented merge behavior rather than starting over. It still does not make the destination instantly current. The migration plan must define the final refresh, the write freeze or delta window, and the moment users stop making operational changes in the old CRM.
Choose continuous one-way sync for a durable source of truth
Continuous one-way synchronization fits a different architecture: one system remains authoritative for a domain while another needs a current projection. A billing platform may own invoices while the CRM displays status. A product system may own usage while the CRM receives customer-health inputs. The connector needs an update stream or schedule, checkpointing, idempotency, backfill, lag monitoring, and a clear response when the source is unavailable.
Local edits need a policy even when information moves in only one direction. Some destination fields should be read-only projections. Others may be local annotations that the source never touches. A field-level three-way merge can preserve destination changes during a repeatable migration, but a long-running projection may instead reject local writes or replace them deliberately. The correct approach depends on authority; neither should be hidden from users behind a generic sync icon.
Use two-way sync only when both systems must participate
Two-way synchronization is justified when teams genuinely operate in both systems and important changes must travel in both directions. It requires more than two one-way jobs. Define ownership for each object and field, map state transitions, prevent feedback loops, carry stable origin and version information, resolve concurrent updates, and decide whether one side can delete or merge records created by the other. Every retry must be idempotent.
Ask whether a narrower event handoff would solve the problem. A support system can send a “customer escalated” event to the CRM without becoming a co-owner of company identity. A CRM can send an approved “create onboarding project” command without synchronizing every project field back. Bounded events often preserve system responsibility more clearly than broad two-way record mirroring. Choose two-way sync because the operating process requires shared editing, not because it sounds more complete.
Treat identity and relationship order as core design
Any repeated movement needs durable identity. A provider record ID should link to one destination record within the workspace, independent of display name or owner. Exact normalized email or domain matching can help adopt a pre-existing destination record, but ambiguous matches need review or a separate record rather than a guess. No matching policy guarantees zero duplicates, especially when source records are already duplicated or identifiers are missing.
Relationships create dependency order. Companies or organizations generally need to exist before their people and deals can be linked; pipeline and stage metadata may be needed before deals are interpreted; users should be available before owner assignment. Activities and notes can be attached only when their referenced core records are known. The current Pipedrive import explicitly processes core records in dependency order. HubSpot similarly imports Companies before dependent records, retains one prioritized imported Account per Contact, and resolves supported Deal, pipeline, stage, owner, Contact, and Company context. A two-way system must maintain those dependencies continuously, not only during a batch.
Write deletion semantics before enabling repetition
Deletion is the most dangerous ambiguous state. A record missing from one read may be deleted, archived, filtered by permission, outside the selected scope, or temporarily unavailable. A safe importer should not infer destructive intent from absence unless the provider supplies a reliable tombstone and the migration policy authorizes deletion. Source-side removal and destination-side deletion are separate events and need separate rules.
The current HubSpot and Pipedrive importer designs preserve the deletion of a destination record after an earlier import: the durable identity link prevents a later run from recreating it and the job reports the outcome. Their field merge behavior also recognizes intentional local clearing. Those protections are appropriate for a non-destructive migration tool. A continuous two-way sync may need different behavior, but it should use explicit tombstones, retention windows, permissions, and recovery rather than assuming that “not returned” means “erase everywhere.”
Compare security scope with business scope
Read-only source permissions reduce one category of risk: a connector cannot use its authorized operation to edit the legacy CRM. They do not remove confidentiality, retention, or access concerns. The connector can still retrieve customer and commercial data, write it into the destination, store tokens, and expose imported records according to destination permissions. Review requested scopes, encryption, revocation, administrator authority, logs, and what happens when a credential becomes invalid.
Keep business scope equally narrow. Import only the objects, properties, history, and record populations needed for the approved purpose. HubSpot installation and Intelligent CRM connector management currently require appropriate source and workspace administrator permissions. Pipedrive imports are also workspace-admin controlled in the current interface. Administrative approval should be accompanied by a data inventory and retention decision; technical permission to read a field is not by itself a reason to migrate it.
Plan monitoring according to the operating model
A batch import needs discovery counts, a start and completion state, created and updated totals, skips, conflicts, failures, warnings, and a downloadable or reviewable exception path. A continuous sync additionally needs lag, checkpoint age, webhook health, backlog, rate-limit state, token health, and alerts that distinguish temporary delay from permanent rejection. A two-way sync needs loop detection and conflict metrics by direction.
Do not judge health only by a green connector badge. Reconcile representative records and aggregate totals. Confirm that a job marked complete did not skip an unsupported currency, inaccessible field, ambiguous identity, or relationship whose parent was absent. The current HubSpot flow exposes intentional skips, explicit conflict and preserved-deletion accounting, non-INR deal constraints, and job-level errors. Pipedrive presents created, updated, skipped, and failed totals, folding preserved conflicts or deletions into skipped results and warnings. Those outcomes are part of the product, not diagnostic clutter.
Make cutover authority visible to users
A migration fails when users do not know which system to edit. Publish the rehearsal period, final refresh, source write freeze, acceptance window, destination go-live, and legacy retention policy. If the connector remains available after cutover for a controlled rerun, name who may run it and which local edits its merge rules preserve. If it is disconnected, retain the import evidence and provider identity links required for audit and support.
For continuous or two-way models, show field authority close to the work. A user should know whether editing a value will be rejected, replaced, sent to the other system, or held as a conflict. Train teams on failure states and ownership rather than asking them to trust invisible automation. The architecture is successful when ordinary users can predict where a change belongs and operators can explain how it moved.
Choose a repeatable import instead of building permanent sync by default
A twenty-person sales team plans to leave its legacy CRM. It needs companies, contacts, open and recent deals, owners, pipeline context, and selected notes in the destination. For three weeks it wants to rehearse mappings while sellers continue in the source. The team initially asks for two-way sync because it fears data drift. Operations maps the actual need and finds no lasting workflow that requires destination edits to return to the retiring platform. It selects a read-only, repeatable one-way import, defines a final delta window, and uses a short write freeze for cutover. Unsupported history remains in a governed legacy archive rather than being represented as synchronized.
Two rehearsals expose owner and currency exceptions without changing the source. Durable identities let the second run update linked destination records, while tested merge behavior preserves deliberate local corrections. At cutover, the team performs discovery again, runs the final import, reconciles open deals and relationships, then declares the destination authoritative. It avoids the loops and conflict engine of permanent two-way sync while still controlling migration drift. A separate billing feed remains a continuous one-way integration because billing, unlike the retired CRM, continues to own that domain.Connector operating-model checklist
- State source permissions and destination write behavior separately
- Name the direction, frequency, trigger, and expected freshness
- List supported and unsupported objects, fields, and history
- Choose the authoritative system for every synchronized data domain
- Define stable identity, adoption, ambiguity, merge, and relationship rules
- Document source-side and destination-side deletion semantics
- Decide how local edits, clears, and concurrent changes are handled
- Use two-way sync only when both systems must remain operational editors
- Review OAuth scopes, token handling, revocation, access, and retention
- Specify import reports or continuous health and lag monitoring
- Test outages, retries, rate limits, conflicts, and missing parents
- Publish rehearsal, final refresh, freeze, acceptance, and go-live timing
- Tell users where each kind of change belongs after launch
- Verify the live connector version rather than relying on a generic integration label
Use the least complex movement that fits the operating job
Read-only import, one-way sync, and two-way synchronization solve different problems. A repeatable import is often the responsible choice for migration because it protects the source, supports rehearsal, and avoids inventing permanent shared authority. Continuous one-way sync is valuable when one system remains authoritative. Two-way sync earns its complexity only when both systems must participate in the same ongoing process.
Write down identity, field authority, deletion, conflict, security, monitoring, and cutover before selecting a connector model. Then verify the behavior with realistic records and failures. Clear boundaries are not a limitation; they are what let a team understand which data moved, which system owns the next change, and how to recover when the movement is incomplete.