Bidirectional Sync

Bidirectional sync keeps data synchronized in both directions between two systems. When a record is updated in either system, the changes flow to the other.

How Bidirectional Sync Works

In a bidirectional mapping:

1. Source → Target: Changes in the source system are pushed to the target
2. Target → Source: Changes in the target system are pushed back to the source
3. Conflict Detection: When both systems change the same record, FluxCascade detects the conflict
4. Resolution: Conflicts are resolved using your configured strategy

When to Use Bidirectional Sync

Configuring Bidirectional Sync

Step 1: Create or Edit a Mapping

1. Go to Mappings
2. Click New Mapping or edit an existing one
3. In the Direction setting, select Bidirectional

Step 2: Configure Field Pairs

For each field pair, you can set the direction:

Example: You might want email to sync both ways, but a "lead source" field to only flow from CRM to field service (not back).

Step 3: Set Conflict Resolution Strategy

Choose how to handle conflicts when both systems update the same record. See Conflict Resolution for details.

Change Detection

FluxCascade tracks changes in both systems using:

Timestamp-Based Detection

Most systems provide updated_at or modified_at timestamps:

• FluxCascade records the last sync timestamp
• On next sync, only records modified since that timestamp are processed
• This is efficient and accurate for most use cases

Webhook-Based Detection

For real-time sync:

• Systems send webhooks when records change
• FluxCascade immediately processes the changed record
• No polling delay – changes sync in seconds

Record Matching

For bidirectional sync to work, FluxCascade must match records between systems:

Email-Based Matching (Recommended for Contacts)

HubSpot Contact (john@example.com) ↔ Jobber Client (john@example.com)

External ID Storage

FluxCascade can store foreign IDs:

HubSpot Contact:
  id: hs_12345
  jobber_id: job_67890  ← FluxCascade stores this

Jobber Client:
  id: job_67890
  hubspot_id: hs_12345  ← FluxCascade stores this

This ensures accurate matching even if email changes.

Bidirectional Sync Flow

Scenario: Contact Updated in HubSpot

1. User updates phone number in HubSpot
2. HubSpot sends webhook OR next scheduled sync runs
3. FluxCascade detects the change
4. Phone number is updated in Jobber
5. Sync is logged with details

Scenario: Client Updated in Jobber

1. Field tech updates address in Jobber mobile app
2. Jobber sends webhook OR next scheduled sync runs
3. FluxCascade detects the change
4. Address is updated in HubSpot
5. Sync is logged with details

Scenario: Both Systems Updated (Conflict)

1. Sales updates phone in HubSpot at 2:00 PM
2. Field tech updates phone in Jobber at 2:05 PM
3. Sync runs at 2:15 PM
4. FluxCascade detects conflict (both modified since last sync)
5. Conflict resolution strategy applied
6. Winner is synced to the other system

Best Practices

1. Choose a Primary System

Even with bidirectional sync, designate one system as "primary" for conflict resolution:

• Marketing/Sales → CRM is primary
• Field Operations → Field service app is primary

2. Limit Bidirectional Fields

Not every field needs bidirectional sync:

Bidirectional (both teams update):

• Phone numbers
• Email addresses
• Notes

One-way from CRM:

• Lead source
• Marketing campaign
• Deal value

One-way from Field Service:

• Job status
• Completion date
• On-site notes

3. Use Webhooks for Critical Data

For data that must be in sync immediately:

• Enable webhooks on both systems
• Configure real-time sync triggers

4. Monitor for Conflicts

Regularly review sync logs for:

• Frequent conflicts on specific fields
• Records that conflict repeatedly
• Patterns suggesting process issues

Troubleshooting

Records Not Syncing Back

Possible causes:

• Webhook not configured on target system
• Scheduled sync not running frequently enough
• Field marked as one-way only

Solutions:

• Verify webhook registration in target system
• Increase sync frequency
• Check field direction settings

Duplicate Records Created

Possible causes:

• Matching strategy not finding existing records
• Email/phone changed before match could occur

Solutions:

• Use external ID storage for reliable matching
• Ensure matching fields are synced first

Data Oscillating Between Values

Cause: Both systems have different values, and each sync overwrites the other.

Solution: Set a clear conflict resolution strategy and stick to it.

Next Steps

• Conflict Resolution – Handle conflicting updates
• Field Transformations – Transform data as it syncs
• Sync Scheduling – Configure when syncs run