CRM sync: The note arrives, fields stay empty - Diagnosis

AI This article was created with the help of AI.

Key takeaways

• A visible note only proves transport, not field evaluation: check the write attempt and CRM acceptance separately.
• HubSpot names picklist values, required values, and missing permissions of the integration account as typical sources of sync errors.
• The field history shows value, timestamp, and source for every change - so you can separate note time from the actual write attempt.
• For the diagnosis, document record ID, expected value, actual value, affected field, error message, and user permissions.
• Fix the root cause instead of loosening validations across the board, and test the retry on a test record.

What does an arrived meeting note prove?

You know the picture: The meeting note sits neatly in the deal's timeline, the team has read it, but the "Next step" field is empty, the deal stage still reflects where things stood three weeks ago, and the budget field stays blank. The temptation is strong to blame the integration across the board. The better route is the opposite: an arrived note is a partial failure, and you can narrow it down precisely. Behind every note there are three separate processes that you should check one by one:

• Transport: The note actually arrived in the CRM system.
• Linking: The note is attached to the right record, i.e. the matching contact, company, or deal.
• Field update: A specific field was written with a new value and the CRM accepted the write.

HubSpot's activity model shows why the three processes tell you nothing about each other. An activity appears in the timeline of the record it is linked to. By default, HubSpot automatically links activities such as notes, meetings, and calls to, among others, the five most recently associated open deals of a contact or company. When creating a new deal, up to 2,000 recent activities per linked record can also be carried over into the new timeline.^[1]

A visible text in the timeline therefore proves exactly two of the three processes: transport and linking. It says nothing about field evaluation, and nothing about the write permissions of the integration account either. Name the partial success clearly before you suspect causes: Documentation works, field population doesn't. Precisely this separation makes the case discussable for everyone involved, from the CRM admin to support.

How do you locate the missing write step?

Between the spoken word and a populated CRM field lies a chain of six steps. If a field stays empty, exactly one of them failed. Instead of guessing, walk the chain once and demand evidence for every step:

‍

For step 5, modern CRM integrations give you a dedicated view: With the HubSpot-Salesforce integration, it's the sync health view with error cards per error type.^[2] How to access and evaluate it is covered in the section on value changes and error messages. This lets you assign a failure to one step instead of re-debugging the whole chain.

One principle always applies: without logs, never state a cause as certain. If you're missing the evidence for a step, label the assumption as an assumption. A support case that arrives with "step 4 is proven to have happened, step 5 fails" gets handled in minutes. A case that arrives with "the integration simply doesn't work" costs everyone involved a week.

Which CRM rules can block individual fields?

When the write attempt goes through but the CRM rejects it, the causes usually fall into three patterns. One of them, the restricted integration account, is described in the HubSpot documentation on Salesforce sync errors as its own error type: Changes from HubSpot cannot be synced to Salesforce if the connected user does not have access to the required field or object.^[2]

‍

In the first pattern, the internal option value decides, not the label: for a restricted picklist in Salesforce, the value coming from HubSpot must exist exactly as an option in the value list, otherwise the field blocks. In the second pattern, a missing required value prevents the write until the field is filled. In the third pattern, the connected user has no read and write permissions on the field even though the connection itself is up; for this case, the HubSpot documentation recommends explicitly granting the Salesforce integration user read and write permissions on the field.^[2] That is exactly what makes this case tricky: a connected account does not prove complete field permissions.

Important distinction: these three patterns come from the documentation for the HubSpot-Salesforce connector and describe its diagnostics in detail. But the general checking pattern behind them - check the field type, compare the internal option value, verify the integration account's permissions - helps you with any CRM integration. We broke down which fields can be filled in a structured way instead of as a note attachment separately in Writing vs. Attaching.

Where do you see value changes and error messages?

The counter-evidence to the empty-field assumption sits in the field history. HubSpot shows it per record, either for a single property or for all properties at once. For every change you see three pieces of information: the value the field was changed to (Changed to), the date of the change, and the source (Source), i.e.^[3] who or what wrote the value.

• Changed to: The actual value that arrived in the field, not the value you expect.
• Date: The time of the last successful change to this field.
• Source: The source of the change, e.g. manual edit, import, workflow, or integration.

Your workflow: put the expected value right next to the actual value from the history and document the deviation. If the history shows an older value with a different source, you know immediately that your write never arrived. If it shows the correct value, the problem lies elsewhere, for example in the view or in the wrong record.

A common mistake is jumbled timestamps. The note time, the last write attempt, and the time of the last field change in the CRM history can describe three different events. Never treat them as the same; check each timestamp against the event it actually documents. The overview Which CRM fields does Voice-to-CRM update shows which field types can be filled in a structured way by voice, from deal stages to custom fields.

Error messages rarely land where you look for them. On the record in the CRM interface there is usually nothing; the write simply took effect without result. The diagnosis sits in the connector. With the HubSpot-Salesforce integration you will find it in the sync health view; here is how you proceed:^[2]

1. Open Integrations > Connected Apps > Salesforce in the settings and switch to the Data sync tab.
2. On the Sync health tab, in the Sync errors area, you will find exactly the error cards per error type that were introduced above in the check chain as evidence for step 5.
3. Click an error card to see details in the right panel, and click the number in the Affected Records column to create a temporary filtered view of the affected HubSpot records.
4. Export the error list via Export errors (CSV) to share it with your team or feed it into your ticketing system.
5. Fix the cause, then use Resync to trigger a targeted new sync run for the fixed errors instead of blindly restarting.

Two things stand out here. First: errors when syncing activities, such as permission problems of the connected user when writing field values, only become visible in this error list, not in the record itself. If you only read the timeline, you miss them. Second: the resync is the clean way back. A new complete run creates new error images and makes your diagnosis worthless.

If you are evaluating an integration in principle, it is worth looking at the criteria that make such situations less likely in the first place: write depth, object coverage, conflict handling and auditability. We have summarized these in the mandatory criteria before tool selection.

How do you prepare a safe retry?

A retry without preparation often causes more damage than the original error: duplicate tasks, overwritten values, diluted histories. Make the retry predictable, in three steps:

1. Fix the cause precisely: add the missing picklist option, fill in the required value, or give the integration account the field permissions named in the error message.
2. Secure existing values: document the field history and affected records before the next write attempt, so no valid value is accidentally overwritten.
3. Re-check on a test record: first run one record through, verify the result in the field history, and only then release the remaining affected records.

The retry must not create duplicate tasks or activities. So before the next run, check whether the first attempt left partial traces, such as a created task without a field update. Exactly this combination, activity present, field empty, is the pattern of the partial failure from the first section.

One path is off limits: loosening validations or required fields across the board so the write "just goes through". That only moves the problem into data quality. A deal that slides through the pipeline without required values destroys exactly the evaluability you built the field mapping for. Fix the cause, not the control.

What information does the diagnosis need?

If the check chain yields a documented partial failure, meaning the note arrived but the field was not filled, you do not need screenshots from what feels like twenty places for the diagnosis. One set of precise details is enough to make the case reproducible:

• Record ID of the affected contact, company or deal
• Time of the customer conversation or of the write attempt
• Expected value: the value that should have been written to the field
• Actual value: the value that, according to the field history, is actually in there^[3]
• Affected field including field type and internal option value
• Error message from the sync error list, verbatim
• User permissions of the integration account on the affected field

Keep personal data limited to the one necessary example: one record, one field, one point in time. That is data minimization as a working principle, and it makes the case easier for everyone involved, not just for data protection. After the change, verify the success again via the field history with value, time and source, as described in the section on value changes.^[3]

This is exactly where the Bliro Sales Assistant comes in: instead of just attaching a note to the timeline, it recognizes from the conversation which CRM fields can be filled and writes structured values into the right fields, from deal stage to custom field, instead of leaving your reps a text block to fill in themselves. This works across the supported CRM systems, from HubSpot and Salesforce to Microsoft Dynamics 365 and SAP Sales Cloud. Importantly: Bliro works without recording the conversation, processing is GDPR-compliant and takes place in the EU, and you keep the autonomy to decide which fields may be filled automatically at all. On the product page you will find a description of this workflow and the integration steps.

Once you have identified a partial failure in your CRM, have it checked against exactly this checklist: with record ID, expected value, actual value and error message, a diffuse symptom becomes a verifiable case that you can solve, instead of finding it again at the next quarterly review.

Sources

1. https://knowledge.hubspot.com/records/associate-activities-with-records
2. https://knowledge.hubspot.com/salesforce/resolve-salesforce-integration-sync-errors
3. https://knowledge.hubspot.com/records/view-record-property-history