Mautic CRM integration with Salesforce and HubSpot

Decide the direction of every field before you touch a plugin setting. Each piece of data in this integration has a natural owner: contact identity and consent usually start in Mautic when someone fills in a form or opts in, while opportunity stage and account owner belong to the sales team inside Salesforce or HubSpot. Lifecycle or lead status sits in between, because both systems can change it, and engagement data such as points and email activity is generated in Mautic but is often useful to sales. Write these decisions down first, because the plugin will happily sync whatever you map.

There are three basic patterns. A one-way push sends data from Mautic to the CRM, which suits engagement scores, campaign membership and consent status that sales should read but not edit. A one-way pull brings CRM values into Mautic, which suits account owner or opportunity stage if marketing needs them for segmentation. A two-way pattern updates both systems and is the one that needs the most care. Two-way sync on the same field creates overwrite loops: Mautic writes a value, the CRM sees a change and writes it back, Mautic then sees another change, and each side can keep reverting the other. Even a field that changes rarely can flip-flop when two automations or two users edit it close together.

The practical rule is simple: one field, one owner, one direction. If a field must be edited in both systems, pick a single system of record for it and treat the other side as read-only, or split the field into two fields, one per system, so each can be written without conflicting. Pay particular attention to consent and email opt-out flags. If a CRM user can clear a suppression flag that Mautic set, the integration may re-subscribe people you are legally required to keep suppressed. Assign consent to Mautic as owner unless your compliance team has decided otherwise.

Before configuration, build a field ownership table with one row per field and columns for source system, target system, direction, owner, update trigger and whether the field can be blank. Include the Mautic contact field, the CRM object and field names, and the rule for conflicts. Then confirm, for each CRM, which objects and fields the plugin or API can read and write in your edition and configuration. Permissions, managed packages, custom fields and HubSpot property types all affect what the plugin can actually do, so treat the vendor documentation and a test sandbox as the source of truth rather than assumptions.

Expect the table to change during testing. Run a small illustrative set of test contacts through each direction, check which side wins after edits in both systems, and record the result against the table. Any field that loops or drifts goes back to the decision step. Keeping the table current after launch matters as much as building it, because new campaigns and new CRM fields tend to add mappings that nobody has assigned an owner.

Duplicates appear when two systems each create a record for the same person and the integration cannot tell that the records match. A typical path starts with a form submission, which creates a Mautic contact keyed on an email address. A sales rep then creates the same person in Salesforce or HubSpot, perhaps with a different capitalization of the email, a missing email, or an address the prospect changed later. When the plugin pushes the Mautic contact, it finds no match and creates a second CRM record. Illustrative example: one prospect with three records, each holding part of the activity history, and a campaign that emails the wrong one. Map each entry point before the first sync so you know every way a person can enter either system.

Start by choosing a stable unique identifier. Email is the default in most setups, but it changes and it is not always present. Consider storing the CRM record ID on the Mautic contact as a dedicated field once the first match is made, so later updates travel by ID rather than by address. Then decide which system is allowed to create contacts. A common model lets the CRM create people and Mautic only update them, or lets Mautic create contacts from forms while the CRM receives them only through the integration. Whichever you choose, document it. The HubSpot plugin pushes contacts based on contact actions or point triggers, so the trigger rules also decide when a record is born in the CRM.

Next, confirm the matching behavior of the specific plugin version you will run. Read the vendor documentation for the Mautic HubSpot plugin and the Mautic Salesforce plugin, and check which field the integration uses to search, whether that search is case-sensitive, what happens when the email is empty, and whether it creates a record or stops when no match is found. Also check the native duplicate rules in Salesforce or HubSpot, because they may merge or block records independently of Mautic. Ask your implementation partner or the vendor to state these behaviors in writing for your version, and do not rely on general assumptions about how such plugins usually work.

Before the first sync, plan the cleanup of existing data. Export both systems, count likely duplicates by email, normalized email and name, and decide the survivor record for each group. Agree which system wins for each field, and make sure consent records and suppression status carry over to the surviving contact. Pause the integration and the cron jobs that trigger pushes while the merge runs, and keep a backup of both sides so you can reverse a bad merge. Assign one owner to approve merge decisions, because inconsistent judgment across hundreds of records creates new duplicates later.

Test the design with deliberate duplicate inputs before go-live. Build a short matrix covering an uppercase email, an email with stray spaces, a missing email, a changed address for a known person, a name spelled two ways, and the same person entering through a form and through a rep. Run each case through the full path and record which record Mautic and the CRM hold afterward. Repeat the matrix after every plugin upgrade, CRM configuration change or Mautic version change, since matching behavior can change between releases.

The point of this section is simple: before the integration carries live leads, you should be able to show, with written expected results, that each rule works and that a failure leaves Mautic usable and visible to someone. Build a test plan around the rules you already decided on: the data direction for each field, the ownership table for conflicting updates, the point threshold that triggers a push, and the opt-out behavior. Each of these becomes at least one test case with a named input, a named expected result in both systems, and a pass or fail mark. Treat the test plan as a deliverable of the project, not a scratch list kept by one engineer. Start with the core cases. Create a new contact in Mautic and confirm it appears exactly once in the CRM, not zero times and not twice. Edit a field that the ownership table assigns to Mautic, then a field assigned to the CRM, and confirm each change follows its owner in the direction you specified. Push a contact across the point threshold and confirm exactly one push occurs, then add more points and confirm no second push fires. Mark a contact as opted out and confirm the sync does not write marketing data for that person in a way that contradicts your consent records. Submit the same form input twice and confirm the duplicate matching rule produces one CRM record. Keep the contacts in these tests in a dedicated test set, labeled so they are never mistaken for real leads and removed from the CRM afterward. Failure testing matters as much as success testing. Force an API error by pointing the connector at an invalid endpoint or a rate-limited sandbox, and force an expired credential by revoking or rotating the token in a test instance. For each case, confirm three things: Mautic still loads and accepts new contacts, the failed record is held, retried or dropped according to the behavior you chose, and an alert reaches a named owner through a channel someone actually watches. Behavior on retry, queueing or dropping depends on the specific plugin or API client you select, so confirm it in that product's documentation and in a test run rather than assuming it. The HubSpot and Salesforce plugin documentation in the resource list is the place to start, and any custom client needs its own written answers. Run the same test set after every Mautic upgrade and after any change to CRM field definitions, picklists, required fields or API permissions, because either can break a mapping without any visible error on the Mautic side. Store the expected results in version control or a controlled document, record the actual results with the Mautic version and plugin version tested, and keep the last passing run as the reference for the next cycle. Ask your implementation partner, or confirm with your own team, how long a full run takes and who signs off on a failed case before production traffic resumes. A test that nobody repeats will not catch the regression that matters most.