Home/Documentation

How to Sync Two Salesforce Orgs

A complete guide to connecting, mapping, and keeping data synchronized between Salesforce orgs — automatically, bidirectionally, without code.

Get Started FreeView Pricing

What is SwiftPort?

SwiftPort is a SaaS platform that connects two or more Salesforce orgs and keeps data synchronized between them in near real-time — automatically, bidirectionally, and without writing a single line of code.

Companies use SwiftPort when they run multiple Salesforce orgs — for example, a parent company and a subsidiary, two acquired companies, or a production org and a sandbox they want to stay in sync. Instead of manual exports, complex middleware, or expensive Salesforce consultants, SwiftPort handles the sync automatically every 2 minutes.

You choose which objects to sync (Accounts, Contacts, Opportunities, custom objects), which fields to map, which records to include or exclude using filters, and who should own the records in the target org. SwiftPort's built-in AI analyzes your field mappings and warns you about type mismatches, picklist value mismatches, missing required fields, and lookup field problems before you go live.

Connecting Your Salesforce Orgs

SwiftPort uses Salesforce OAuth 2.0 with PKCE for secure, one-click authentication. You do not need to create a Connected App in Salesforce — SwiftPort handles that for you.

Steps:

1. Go to Connected Orgs in your dashboard

2. Click Connect New Org

3. Choose Production or Sandbox

4. You'll be redirected to Salesforce's login page — log in with any user who has API access

5. Approve the SwiftPort permissions

6. You're connected

SwiftPort requests only the api OAuth scope — the minimum required to read and write Salesforce records. Your org credentials are encrypted with AES-256-GCM and never stored in plain text.

Tip:Use a dedicated Integration User in each org rather than a personal user account. This ensures syncs don't stop if someone changes their password.

Creating a Sync Configuration

A sync configuration defines the relationship between a source object (where data comes from) and a target object (where data goes). You walk through this in a guided 8-step builder.

Step 1 — Name your sync:Give it a descriptive name like "Production Accounts → Subsidiary Contacts"
Step 2 — Choose your orgs:Select source org and target org from your connected orgs list
Step 3 — Choose objects and direction:Select the object in each org and whether to sync one-way (source → target) or bidirectionally (both ways)
Step 4 — Set triggers:Choose what events trigger a sync: record Created, Updated, or both
Step 5 — Add filters (optional):Only sync records that match specific criteria — for example, only Accounts where Industry = Technology, or only Contacts where Email is not blank
Step 6 — Map fields:Map each source field to a target field. SwiftPort auto-suggests mappings by name. The AI analyzer reviews your mappings and flags incompatible types (e.g., Currency → Text), picklist value mismatches between orgs, missing required fields, read-only fields, and lookup field issues.
Step 7 — Owner assignment:Every Salesforce record needs an OwnerId. Since User IDs differ between orgs, choose a strategy: Fixed Owner (one user owns all synced records), Round Robin (rotates through a list), or Pass Through (copies source owner — only works if the same user exists in both orgs).
Step 8 — Pre-flight test and review:SwiftPort fetches a real sample record from your source org and simulates the sync payload without writing anything. You see exactly what would be sent, including any warnings. Activate when ready.

Bidirectional Sync

Bidirectional sync keeps changes flowing in both directions — source to target and target to source.

How it works:SwiftPort uses Salesforce's `SystemModstamp` field to detect which records have changed since the last sync run. After writing a record to the target org, SwiftPort records the timestamp so it won't re-process the same record on the next cycle. This prevents infinite sync loops.
Separate owner strategies per direction:You can configure different owner assignment strategies for each direction — for example, all records coming from Org A use a Fixed Owner in Org B, while records going the other way use Round Robin.
Recommendation:Start with one-way sync first, confirm it works correctly, then enable the reverse direction. Bidirectional sync is more complex to debug when something goes wrong.

Owner Assignment

Every Salesforce record must have an OwnerId. User IDs are unique per org — the same person has a different ID in each org — so you cannot simply copy OwnerId across orgs.

SwiftPort provides three strategies:

Fixed Owner:All synced records in the target org are assigned to one specific user you select. Simple and predictable. Best for integration users or a dedicated owner.
Round Robin:Synced records are distributed evenly across a list of users you select. The first record goes to User 1, the second to User 2, and so on, cycling through the list. Good for distributing leads or cases across a team.
Pass Through:SwiftPort copies the source OwnerId directly to the target record. This only works if the same user (same Salesforce User ID) exists in both orgs — which is rare. Using Pass Through when the user doesn't exist in the target org causes `INVALID_CROSS_REFERENCE_KEY` errors. Only use Pass Through if you've confirmed the user IDs match.

Filters

Filters let you control which records get synced. Only records that match all your filter conditions are processed.

Example filters:
•Industry equals Technology — only sync tech companies
•Email is not blank — only sync contacts with an email address
•AnnualRevenue greater than 1000000 — only sync enterprise accounts
•RecordTypeId equals [specific ID] — only sync records of a specific type

Filters are evaluated against the source record's field values before the record is sent to the target org. Records that don't match are counted as "filtered out" in your sync logs.

Field Mapping

Field mapping defines how data flows from source fields to target fields. SwiftPort loads all available fields from both objects using the Salesforce Metadata API.

AI-powered analysis:When you click "Analyze with AI" in the field mapping step, SwiftPort's AI reviews your mappings and flags:
•Type mismatches (e.g., mapping a Currency field to a Text field)
•Missing required fields — fields the target object requires but aren't in your mapping
•Read-only fields (e.g., Name on Contact, formula fields, auto-number fields)
•Lookup fields that may reference records that don't exist in the target org
•**Picklist value mismatches** — if you map a picklist field in the source org to a picklist in the target org, SwiftPort compares the actual allowed values from both orgs. If the source has values like "Hot" or "Cold" that don't exist in the target's picklist, Salesforce will reject those records. SwiftPort flags missing values as a warning (partial overlap) or error (zero overlap) before you go live — so you know exactly which values to add to the target org's picklist definition first.
Important:The `Name` field on the Contact object is read-only — Salesforce builds it from `FirstName` and `LastName`. Map those separately and do not include `Name` in your mapping.
How SwiftPort tracks records:When you activate a sync, SwiftPort automatically creates a custom field `SwiftPort_Source_Id__c` on the target object in your target org (requires "Customize Application" permission on the connected profile). This field stores the source record's Salesforce ID and uses Salesforce's native External ID upsert mechanism. On every sync run:
•If a record with that source ID already exists in the target org → it gets **updated**
•If no matching record exists → a **new record is created**
•If someone manually deletes a target record → SwiftPort **recreates it cleanly** on the next run

Zero record data is ever stored in SwiftPort's database — all data lives entirely within your own Salesforce orgs.

Sync Logs & Error Handling

Every sync run is logged in the Sync Logs section. You can see: - How many records were processed, succeeded, and failed - The exact Salesforce error code and message for each failure - When the sync ran and how long it took - AI-generated explanations of errors with suggested fixes

Inline retry:You don't need to re-open your sync config to fix a failed record. From the Sync Logs page, expand any failed run and click Retry on individual records or Retry All to re-attempt all failures at once.
Retry settings:Each sync config has configurable retry settings — maximum automatic retry attempts (0 to 10), whether to auto-retry on partial failures, and notifications on failure. Configure these in Step 7 (Retry Settings) of the sync builder.
Success rate:Your dashboard shows an overall success rate across all syncs. When retried records succeed, the original sync log is updated — succeeded count increases, failed count decreases, and your success rate reflects the true outcome.

Security

SwiftPort is designed to be enterprise-safe and is built for Salesforce AppExchange compatibility.

What we store:
•Your Salesforce OAuth access tokens and refresh tokens — encrypted with AES-256-GCM. The encryption key is never in the database.
•Sync configuration metadata (which orgs, objects, field mappings, settings)
•Sync execution logs (record IDs, timestamps, error codes — never field values)
What we never store:
•Salesforce record field values (name, email, phone, revenue, etc.)
•Passwords
•PII from your Salesforce data
Log retention by plan:

Sync logs (run history, record counts, error codes) are automatically deleted on a nightly schedule based on your plan: Starter keeps 30 days, Professional keeps 90 days, Enterprise keeps 1 year. Individual record-level error details are cleaned up first; summary log rows follow the same schedule.

Data isolation:Each customer's data is isolated using Supabase Row Level Security. It is architecturally impossible for one customer's sync configuration to access another customer's org.
OAuth scope:SwiftPort requests only the `api` OAuth scope — the minimum needed to read and write records via REST API.
Transit:All data between SwiftPort and Salesforce is transmitted over TLS 1.2+. Your data never touches disk — syncs are processed entirely in memory.

Common Errors

**INVALID_CROSS_REFERENCE_KEY — Owner ID doesn't exist in target org** The OwnerId you're using doesn't exist in the target org. Switch to Fixed Owner or Round Robin and select a real user from the target org.

**REQUIRED_FIELD_MISSING — Missing a required field in target object** The target object requires a field you haven't mapped. Add it to your field mapping. If you can't map it from the source, set a default value for it in the target org's Salesforce field definition.

**INVALID_FIELD_FOR_INSERT_UPDATE: Name — Don't map Name on Contact** The Name field on Contact is read-only. Remove Name → Name from your mapping and map FirstName and LastName individually.

**MALFORMED_QUERY — No fields in your mapping** Your sync config has no field mappings. Edit the config and add at least one field mapping.

**FIELD_CUSTOM_VALIDATION_EXCEPTION — Validation rule in target org** A validation rule in your target org is rejecting the record. Review the validation rules on the target object and either fix the source data or add a filter to exclude non-compliant records.

Ready to sync your Salesforce orgs?

Connect two Salesforce orgs in minutes. No code, no Connected App setup, no data stored on our servers.

Start for freeView plans