Every field in Conversion has a sync mode that controls how data flows between Conversion and Salesforce. Understanding these modes helps you maintain data integrity and ensure the right system is the source of truth for each piece of information.Documentation Index
Fetch the complete documentation index at: https://docs.conversion.ai/llms.txt
Use this file to discover all available pages before exploring further.
What Are Sync Modes?
A sync mode determines two things for each field:- Direction – Does data flow from Salesforce to Conversion, from Conversion to Salesforce, or both?
- Conflict resolution – When both systems have different values, which one wins?
The Five Sync Modes
Conversion offers five sync modes to handle different scenarios:Prefer Salesforce Unless Empty
Salesforce is the source of truth, but Conversion can fill in gaps.
Always Prefer Salesforce
Salesforce always wins. One-way sync into Conversion.
Always Prefer Conversion
Conversion always wins. One-way sync to Salesforce.
Two-Way Sync
Most recent update wins, regardless of which system made the change.
Do Not Sync
Field is not synced. Changes stay local to each system.
Prefer Salesforce Unless Empty
Default for most fields. This is the most common sync mode and works well for the majority of use cases, including newly detected custom fields.
- Salesforce values always sync to Conversion
- Conversion values only sync to Salesforce when the Salesforce field is blank
- Once Salesforce has a value, Conversion won’t overwrite it
Example: Job Title field
Example: Job Title field
Scenario: A lead fills out a form on your website with job title “Marketing Manager”. Later, a sales rep updates their title in Salesforce to “Director of Marketing”.
The Salesforce value is protected once it exists. The form submission can’t overwrite the sales rep’s update.
| Event | Salesforce Value | Conversion Value | Result |
|---|---|---|---|
| Form submission | (empty) | Marketing Manager | SF updated → “Marketing Manager” |
| Sales rep updates SF | Director of Marketing | Marketing Manager | Conversion updated → “Director of Marketing” |
| Contact fills out another form with “VP Marketing” | Director of Marketing | VP Marketing | No change to SF – SF value is protected |
Always Prefer Salesforce
How it works:- Salesforce values always sync to Conversion
- Conversion never sends values back to Salesforce for this field
- This is a true one-way sync into Conversion
Example: Account Tier
Example: Account Tier
Scenario: Your sales team classifies accounts into tiers (Strategic, Enterprise, Mid-Market, SMB) based on relationship factors and revenue potential that only they can assess.
Sales maintains complete control over account classification. Even if a contact self-selects a company size on a form, it won’t affect the tier that sales has assigned.
| Event | Salesforce Value | Conversion Value | Result |
|---|---|---|---|
| Initial sync | Enterprise | (empty) | Conversion updated → “Enterprise” |
| Sales rep upgrades tier | Strategic | Enterprise | Conversion updated → “Strategic” |
| Form submission includes “SMB” | Strategic | Strategic | No change to SF – Conversion cannot overwrite |
Always Prefer Conversion
How it works:- Conversion values always sync to Salesforce
- Salesforce values never sync to Conversion for this field
- This is a true one-way sync to Salesforce
Example: First Traffic Source
Example: First Traffic Source
Scenario: Conversion tracks where each contact originally came from (organic search, paid ad, referral, etc.).
Conversion is the source of truth for this field. Even if someone changes it in Salesforce, Conversion will restore its value if the field is updated later.
| Event | Conversion Value | Salesforce Value | Result |
|---|---|---|---|
| Contact created from Google ad | Paid Search | (empty) | SF updated → “Paid Search” |
| Someone edits SF field to “Direct” | Paid Search | Direct | SF overwritten → “Paid Search” |
Two-Way Sync
How it works:- Both systems can update each other
- When there’s a conflict, the most recently updated value wins
- Conversion compares timestamps to determine which value is newer
Example: Phone Number
Example: Phone Number
Scenario: A contact’s phone number might be updated by a sales rep in Salesforce or by the contact themselves via a form in Conversion.
The most recent change always wins, keeping both systems up to date with the latest information.
| Event | Timestamp | Salesforce Value | Conversion Value | Result |
|---|---|---|---|---|
| Initial sync | 9:00 AM | 555-0100 | 555-0100 | In sync |
| Contact updates via form | 2:00 PM | 555-0100 | 555-0199 | SF updated → 555-0199 |
| Sales rep updates SF | 3:30 PM | 555-0200 | 555-0199 | Conversion updated → 555-0200 |
| Contact updates via form again | 4:00 PM | 555-0200 | 555-0201 | SF updated → 555-0201 |
Timestamp comparison: Conversion compares Salesforce’s
LastModifiedDate against the individual field’s last update time in Conversion. In the rare case of identical timestamps, Salesforce wins.One important difference: Salesforce only provides a record-level timestamp, not field-level. So when any field changes in Salesforce, all fields are treated as updated at that time. Conversion tracks field-level timestamps, so only fields updated more recently than the Salesforce record are pushed back.Do Not Sync
How it works:- The field exists in both systems but is never synchronized
- Changes in Salesforce stay in Salesforce
- Changes in Conversion stay in Conversion
Example: Internal Notes
Example: Internal Notes
Scenario: Both systems have a “Description” field, but they’re used for different purposes – marketing notes in Conversion and sales notes in Salesforce.
Each team maintains their own notes without interference.
| Event | Salesforce Value | Conversion Value | Result |
|---|---|---|---|
| Initial state | ”Enterprise prospect, 6-month timeline" | "Downloaded pricing guide, attended webinar” | No sync – values remain independent |
| Sales rep updates SF | ”Meeting scheduled for Friday" | "Downloaded pricing guide, attended webinar” | No sync |
| Marketing updates Conversion | ”Meeting scheduled for Friday" | "Requested demo via chatbot” | No sync |
Do Not Sync is only available for some default fields whose mappings to Salesforce fields cannot be deleted. For custom fields, deleting the field mapping has the same effect as Do Not Sync.
Sync Mode Comparison
Use this table to quickly compare all five sync modes:| Mode | Salesforce → Conversion | Conversion → Salesforce | Who Wins Conflicts |
|---|---|---|---|
| Prefer SF Unless Empty | Always | Only if SF is blank | Salesforce (unless blank) |
| Always Prefer SF | Always | Never | Salesforce always |
| Always Prefer Conversion | Never | Always | Conversion always |
| Two-Way Sync | Yes | Yes | Most recent update |
| Do Not Sync | Never | Never | N/A (no sync) |
Sync Mode Restrictions
Some fields have restrictions on which sync modes are available. This ensures data integrity for critical fields.Fields with Limited Sync Mode Options
| Field Type | Available Modes | Why |
|---|---|---|
| Two-Way Sync only | Email is the unique identifier and must stay synchronized | |
| Last Name | Prefer SF Unless Empty, Two-Way Sync | Required field in Salesforce – must be able to sync |
| Company Name | Prefer SF Unless Empty, Two-Way Sync | Required field in Salesforce – must be able to sync |
| Owner | Prefer SF Unless Empty, Two-Way Sync | Critical for assignment rules and routing |
| System Source | Always Prefer Conversion, Do Not Sync | Conversion-managed field tracking record origin |
| Traffic/UTM Fields | Always Prefer Conversion, Do Not Sync | First-touch attribution data owned by Conversion |
Standard Fields
Most standard fields support four sync modes:- Prefer Salesforce Unless Empty
- Always Prefer Salesforce
- Two-Way Sync
- Do Not Sync
“Always Prefer Conversion” is not available for most standard fields to prevent accidentally overwriting important Salesforce data. It’s primarily available for Conversion-managed fields like traffic source and UTM parameters.
Custom Fields
When Conversion detects new custom fields in Salesforce:- Editable fields default to Prefer Salesforce Unless Empty and can be changed to any available mode
- Read-only fields default to Always Prefer Salesforce and cannot be changed while the field remains read-only in Salesforce
Changing Sync Modes
You can change sync modes at any time for fields that allow it:Frequently Asked Questions
What happens if I change a sync mode?
What happens if I change a sync mode?
The new mode takes effect immediately for future syncs. Existing values aren’t automatically synchronized – they’ll update the next time either Salesforce or Conversion modifies that field.
Can I have different sync modes for the same field on Leads vs. Contacts?
Can I have different sync modes for the same field on Leads vs. Contacts?
No. Sync modes are set per Conversion field and apply to all Salesforce objects that field is mapped to. If
job_title is mapped to both Lead.Title and Contact.Title, both use the same sync mode.Why can't I select 'Always Prefer Conversion' for some fields?
Why can't I select 'Always Prefer Conversion' for some fields?
Some fields, particularly standard Salesforce fields, restrict this mode to prevent accidentally overwriting critical data. This protection ensures sales data isn’t inadvertently replaced by marketing updates.
What if timestamps are identical in Two-Way Sync?
What if timestamps are identical in Two-Way Sync?
In the rare case where both systems have exactly the same timestamp, Salesforce wins. This is an edge case that rarely occurs in practice.
Do sync modes affect the initial sync?
Do sync modes affect the initial sync?
Yes. During the initial sync, Conversion uses your configured sync modes to determine how to handle each field. This is why it’s helpful to review your sync modes before connecting Salesforce.
Can I set a default sync mode for new custom fields?
Can I set a default sync mode for new custom fields?
Currently, new custom fields detected from Salesforce default to Prefer Salesforce Unless Empty (or Always Prefer Salesforce if read-only). You can change editable fields individually after they’re detected.
What's the difference between 'Prefer SF Unless Empty' and 'Always Prefer SF'?
What's the difference between 'Prefer SF Unless Empty' and 'Always Prefer SF'?
With “Prefer SF Unless Empty,” Conversion can fill in blank Salesforce fields. With “Always Prefer SF,” Conversion never writes to Salesforce for that field—even if Salesforce’s value is blank.
Related Documentation
Field Mappings
Learn how fields are mapped between Salesforce and Conversion
Default Fields Reference
See all default fields and their sync mode options