All integrations
CRM source integration

Factory Labs + Salesforce: The Migration Path

How Factory Labs reads from and migrates off Salesforce. Bulk API + Data Loader compatible imports, JSONB-backed custom field mapping, side-by-side operation during transition. The Salesforce integration is a migration path, not a long-term sync.

Updated 2026-05-17 · Official Salesforce site

Factory Labs's Salesforce integration is intentionally different from the other integrations on this page: it is a migration path, not a steady-state sync. Most customers using it are moving off Salesforce, and the integration is built to make that move clean rather than to perpetuate a two-system architecture.

If you are looking for a long-term "Salesforce + Factory Labs" sync, that is not what we ship. The architectural premise is that you pick one system of record. The Salesforce integration exists to bridge the gap during cutover.

For the head-to-head decision, see Factory Labs vs Salesforce.

What we support

The Factory Labs Salesforce integration covers:

  • Bulk API + REST API for reading Salesforce data into Factory.
  • Data Loader CSV imports for the "export from Salesforce, import to Factory" pattern that does not require API credentials.
  • Side-by-side read during a phased migration: Factory can read from Salesforce as a data source while migration is in flight.
  • Standard and custom objects: Account, Contact, Lead, Opportunity, Case, Task, Activity, and any custom object with a defined schema.
  • Custom fields: standard Salesforce custom fields (Foo__c) map automatically to Factory's JSONB-backed custom field surface.

What the integration does

Migration tool (one-time)

Factory's migration utility reads from Salesforce via Bulk API, maintains a Salesforce-ID → Factory-UUID mapping, and imports the data into Factory in dependency order (Accounts first, Contacts second, Opportunities third, Activities last). Foreign key references resolve correctly because of the ID mapping table.

The utility handles:

  • Standard object imports (Accounts, Contacts, Opportunities, Cases, Tasks, Activities).
  • Custom object imports (Professional and Enterprise tiers).
  • Custom field mapping to JSONB without schema migrations.
  • Attachments and notes.
  • Owner and team assignments.

The migration playbook covers the operational sequence and the three failure modes (lift-and-shift, custom-object fundamentalism, frozen-in-place workflows).

Side-by-side read (transitional)

During a phased migration, Factory can read from Salesforce as a live data source for objects that have not yet migrated. This lets some teams use Factory as their primary surface while others remain on Salesforce, with the data appearing consistently in either view. The pattern is intentionally short-lived; we do not recommend running both systems indefinitely.

Direct CSV import (no-API)

For teams that cannot or do not want to grant Factory API access to Salesforce, the same migration utility accepts Data Loader CSV exports directly. The mapping logic is identical; only the data source is different.

How the migration works in practice

Typical sequence for a 32-seat distributor:

  1. Inventory. Build the object decision matrix (migrate / leave behind / merge / move-to-ERP) and the workflow decision matrix (rebuild / retire / replace). Usually 1-2 days.
  2. Export. Pull Salesforce data via Data Loader or Bulk API into the migration utility. Hours.
  3. Map. Custom fields map automatically; review the JSONB layout that lands in Factory. 1-2 hours.
  4. Import. Run the migration into a Factory sandbox. 1-3 hours depending on data volume.
  5. Smoke check. Pick 20 accounts at random (10 active, 10 historical) and validate each in both systems with the rep who owns them.
  6. Rebuild workflows. Recreate only the Salesforce workflows that survived the workflow decision matrix.
  7. Cutover. Tuesday morning. Salesforce read-only, Factory live. Maintain Salesforce read-only for 60 days for historical lookup, then export to S3 and shut down.

Total elapsed time: 4 weeks is typical. Faster for vanilla Salesforce Pro deployments, longer for heavy Apex / custom-object estates.

What this means for your team

For sales reps:

  • After cutover, the account page shows live ERP data instead of a Salesforce custom object.
  • Lead and opportunity pipelines look familiar with custom fields where they expect them.
  • Salesforce reports they relied on are reproduced in Factory's reports module with the same numbers.
  • Salesforce remains read-only for 60 days for historical lookups.

For sales ops:

  • The reconciliation report comparing Salesforce opportunities to ERP orders is no longer needed; the opportunity is the order, viewed differently.
  • The Boomi or MuleSoft instance previously bridging Salesforce to the ERP can be turned off two weeks after cutover.
  • Custom object schema management is gone; custom fields live in JSONB and are added through the UI.

For leadership:

  • The Salesforce license bill ends at contract renewal (or earlier if Salesforce allows mid-term reduction).
  • The middleware bill ends.
  • The reconciliation overhead in sales ops is reclaimed.

Pricing notes

The Salesforce integration (read + migration utility) is included in every Factory Labs plan. Custom object migration is included in Professional and above. White-glove migration assistance is part of Enterprise.

For a 32-seat distributor, the migration utility plus self-serve approach typically replaces a $40,000-100,000 partner-led migration project.

Frequently asked questions

Can we run Factory Labs and Salesforce indefinitely with the integration? Technically yes, but we strongly recommend against it. The point of moving to an ERP-native CRM is to eliminate the second-system reconciliation work; running both indefinitely defeats the architectural benefit. The integration is built for transition periods of weeks, not years.

What about Salesforce Service Cloud cases? Cases migrate as Factory Labs cases. The mapping preserves case status, owner, contact, account, and the full activity timeline. Service Cloud-specific routing rules are rebuilt in Factory's automation engine; most are simpler in the new system.

Does the integration handle Salesforce Apex triggers? The migration utility does not port Apex. Apex triggers are usually workarounds for Salesforce limitations or batch processing patterns; in most cases the equivalent in Factory is either a native feature or a simpler automation. The migration playbook covers the replacement strategy.

Can we keep Salesforce as a read-only archive after cutover? Yes. Most customers keep Salesforce read-only for 60-90 days, then export everything to S3 and end the Salesforce contract. Factory's integration continues to support read access during this window.

What about Salesforce data residency / Hyperforce? The migration utility respects whichever Salesforce instance you authenticate against, including Hyperforce-resident orgs. Factory's data plane is multi-region (US, EU) and the destination region is configurable per tenant.