ERR_SYNC_CONFLICT on Make.com: Sync conflict detected. Root cause: Simultaneous updates to same record from multiple sources Step 1: Identify which two scenarios are writing to the same record simultaneously. Open Make.com and go to Activity → Scenario Runs. Filter by the time window when the conflict occurred. Look for two scenario runs that overlapped in time and both targeted the same destination app and record. Make.com logs the record ID or identifier in the module output — click each run and expand the module that writes to the destination to see which record ID it was updating. Confirming the exact record ID that was targeted by both scenarios is the essential first step before any fix. Step 2: Serialise the scenarios using a Make.com data store as a lock. The most reliable way to prevent sync conflicts is to ensure only one scenario can update a given record at a time. Create a Make.com Data Store (go to Data Stores in the left sidebar → Add data store) with a single text field called "locked_record_id". At the start of each scenario, add a Data Store → Search Records step to check whether the record ID is already in the data store. If it is, use a Router to skip processing. If it is not, immediately add the record ID to the data store, process the update, then remove the record ID when done. Step 3: Use the target app's native optimistic locking if available. Many CRMs and databases support optimistic locking via a version number or updated_at timestamp. Salesforce uses a SystemModstamp field; HubSpot uses hs_lastmodifieddate; Airtable uses Last Modified Time. Before writing an update, fetch the current version of the record and include it in your update payload. If the record was modified between your read and your write, the API will return a conflict error (usually HTTP 409). In Make.com, add an error handler on the update module that catches 409 errors and re-fetches the latest version before retrying. Step 4: Stagger scenario schedules to eliminate simultaneous execution windows. If both scenarios run on a schedule (e.g., every 15 minutes), offset their start times so they cannot overlap. Go to each scenario → click the clock icon on the trigger module → change the schedule. If Scenario A runs at :00 and :15 and :30 and :45, set Scenario B to run at :05 and :20 and :35 and :50. This 5-minute offset is usually sufficient to prevent overlap for scenarios that complete in under 3 minutes. Check the average run duration in Activity → Scenario Runs to confirm the offset is large enough. Step 5: Implement a conflict resolution strategy for the data itself. Even with locking, you need a defined rule for what happens when a genuine conflict is detected: last-write-wins (simplest — the most recent update overwrites), first-write-wins (the first update is preserved and subsequent conflicting updates are discarded), or merge (both updates are applied to different fields). Document this decision in the scenario description. For last-write-wins, compare the updated_at timestamp of the incoming data against the current record before writing. For merge, use a Router to direct each field update to a separate module. Step 6: Set up a conflict alert so future conflicts are caught immediately. Add a Slack or email notification to the error handler of your update modules. When a conflict error (HTTP 409 or a duplicate key error) is caught, send a message that includes the record ID, the scenario name, and the conflicting values. This creates an audit trail and ensures conflicts are investigated rather than silently overwritten. Review the conflict log weekly during the first month after implementing the fix to confirm the locking strategy is working as expected.