How to Sync MySQL and Pipedrive Using n8n

TL;DR

Use n8n to fetch contacts from MySQL and Pipedrive, normalize their fields, and match records by email with the Compare Datasets node. Create contacts that exist in only one system, then resolve changed records by comparing updated timestamps and sending the most recently updated name or phone value to the other system.

Transcript

foreign workflow to create a two-way data sync from pipedrive to mySQL and vice versa so I already prepared the workflow and set up my mySQL database and my pipedrive account and this is the workflow that we will be going through in a minute and for today's tutorial we are focusing on synchronizing contact person data from pipedrive I have already ... Read More

Key Insights

• Email is the matching key used to treat a MySQL contact and a Pipedrive person as the same entity. This lets the Compare Datasets node identify records that exist in only one source, records that match, and records containing different field values.
• Pipedrive data is normalized before comparison because its returned person structure is more complex than the MySQL table. A Set node maps incoming expressions into a simplified collection of ID, name, email, phone, and updated timestamp values that aligns with the database fields.
• Records found only in Pipedrive are inserted into MySQL through an Insert operation on the contacts table. The incoming name, email, and phone values are mapped directly to their corresponding MySQL columns, creating the database records that were previously missing.
• Records found only in MySQL are created in Pipedrive with the Person resource and Create operation. Expressions map the incoming database values into Pipedrive's name, email, and phone fields, allowing contacts missing from the CRM to be restored automatically.
• The different output identifies which fields disagree between matched records. IDs and updated timestamps can naturally differ between the two services, so an IF node specifically checks whether a name or phone property exists among the different fields before starting an update.
• Timestamp normalization is required before the workflow can compare modification times. A Date and Time node reformats the MySQL timestamp to match the Pipedrive timestamp format, enabling a later IF node to determine whether the MySQL or Pipedrive version changed more recently.
• The most recently updated source determines the direction of synchronization. If the MySQL timestamp occurred after the Pipedrive timestamp, the workflow updates Pipedrive; otherwise, it updates MySQL using the newer values obtained from the Pipedrive record.
• Destination-specific IDs are required when updating existing records. A MySQL update uses the ID from the MySQL input, while a Pipedrive update uses the ID from the Pipedrive input, even though the name or phone values come from whichever source changed most recently.

Questions & Answers

Q: How do you create a two-way sync between MySQL and Pipedrive?

Create an n8n workflow that retrieves contacts from both systems, converts the Pipedrive output into a schema comparable with the MySQL table, and sends both datasets to a Compare Datasets node. Match contacts by email. Create records found in only one source, and route differing records through timestamp comparison so the older version is updated with newer values.

Q: How does n8n match MySQL contacts with Pipedrive persons?

The workflow uses email as the comparison field in the Compare Datasets node. When a MySQL contact and a Pipedrive person share the same email address, they are treated as one entity. The node can then separate the results into records found only in input one, only in input two, identical records, and records whose other fields differ.

Q: How are missing Pipedrive contacts added to MySQL?

Contacts that appear only in the normalized Pipedrive input leave the Compare Datasets node through the input two only output. They enter a MySQL node configured with the Insert operation for the contacts table. Expressions map the incoming name, email, and phone values to the corresponding columns, creating each contact that was absent from MySQL.

Q: How are missing MySQL contacts created in Pipedrive?

Contacts found only in the MySQL input leave the Compare Datasets node through the input one only output. A Pipedrive node then uses the Person resource with the Create operation. Expressions supply the incoming MySQL name, email, and phone values, producing new Pipedrive persons for records that previously existed only in the database.

Q: How does the workflow detect meaningful contact changes?

The Compare Datasets node returns a different object containing fields whose values do not match between MySQL and Pipedrive. Since IDs and updated timestamps can differ normally, an IF node checks specifically for a different name or phone property. Only records containing one of those meaningful differences continue through the update branch, while unchanged records require no action.

Q: Why are timestamps reformatted before comparing updates?

The MySQL and Pipedrive timestamps arrive in different formats, so they cannot be used directly for a consistent date comparison. A Date and Time node maps the MySQL updated timestamp and applies a custom format that matches the Pipedrive value. The following IF node can then determine which record was modified later and select the correct update direction.

Q: How does the workflow decide which system to update?

An IF node compares the updated timestamps from input one, MySQL, and input two, Pipedrive. If the MySQL change occurred after the Pipedrive change, the workflow follows the branch that updates the Pipedrive person. Otherwise, it follows the branch that updates the MySQL contact, because the Pipedrive version has the later timestamp and supplies the newer data.

Q: How are the correct values and IDs selected for an update?

Set nodes prepare the update payload with conditional expressions. If name or phone appears in the different object, the workflow takes that field from the more recently updated source; otherwise, it keeps the shared value. The destination ID always comes from the system being updated: input one for MySQL and input two for Pipedrive. This targets the existing destination record correctly.

Summary & Key Takeaways

• The workflow retrieves ID, name, email, and phone data from a MySQL contacts table while also retrieving every Pipedrive person. Because Pipedrive returns a more complex structure, a Set node converts its records into a simpler schema containing ID, name, email, phone, and an updated timestamp for comparison.

• The Compare Datasets node matches MySQL and Pipedrive contacts by email. Records found only in MySQL are created as Pipedrive persons, while records found only in Pipedrive are inserted into the MySQL contacts table. Records that are identical require no action, while differing records enter the update process.

• For differing records, an IF node checks whether a meaningful field, such as name or phone, changed. The workflow formats timestamps consistently, determines which source was updated later, prepares the correct values and destination ID with Set nodes, and updates the older record. A scheduled trigger can run this process every five minutes.