If HubSpot Sync Health reports a Salesforce custom field validation rule error, Salesforce rejected a record change because an active validation rule evaluated the record as invalid. The record can look complete in HubSpot and still fail in Salesforce: the rule may check other fields, a record type, or a condition that changed during the create or update.
Start with the exact error and affected record. Find the Salesforce object, the attempted action, and the rule that evaluated to true before changing a workflow, mapping, or validation control. A Salesforce administrator can use the validation debug events to identify the rule name and formula result when the HubSpot message is not specific enough.
Fast route: open the error in HubSpot Sync Health; capture the record, object, message, and time; inspect active Salesforce validation rules for that object; compare the rule’s conditions with the values and context of the attempted API change; make one reviewed correction; then resync one record and confirm the saved result.
Confirm the exact error and affected record
In HubSpot, go to Settings → Integrations → Connected Apps → Salesforce → Data sync → Sync Health. Open the relevant error card and inspect the affected-record details. HubSpot’s Salesforce integration sync-error guide lists “Salesforce custom field validation rule” under Custom code and directs users to work with a Salesforce administrator when the failure originates in Salesforce automation or validation logic.
Record the exact message, object type, HubSpot record, Salesforce record ID if one exists, time of the attempt, and whether HubSpot was creating or updating the record. If the detail panel identifies a field or includes a Salesforce error message, keep that text. Do not export or paste customer values into an unsecured log or support message.
| HubSpot error or symptom | What it points to | First check |
|---|---|---|
| Salesforce custom field validation rule | A Salesforce validation formula rejected a create or update. | Find the active rule and its error message for this object. |
| Invalid Salesforce ID | A reference/lookup mapping received a value that is not a Salesforce record ID. | Inspect the mapping and any related custom validation rule; HubSpot lists this separately under Property mappings. |
| Salesforce Flow | A Salesforce flow or automation path failed. | Use the Salesforce Flow error details; see the Flow troubleshooting guide. |
| Salesforce duplicate rule | A deduplication rule blocked the attempted Salesforce record. | Review matching and duplicate rules; see the duplicate-rule diagnostic. |
| Restricted picklist value | A value is not allowed for a Salesforce picklist field or record type. | Check the value set and mapped option; see the restricted-picklist guide. |
These error names are not interchangeable. HubSpot’s guide places “Invalid Salesforce ID” under Property mappings and recommends checking a Salesforce custom validation rule, while its broader “Salesforce custom field validation rule” message appears under Custom code. Follow the exact Sync Health category and details instead of treating every failed sync as the same problem.
Find the rule that applies to the Salesforce object
With a Salesforce administrator, open Setup → Object Manager → [affected object] → Validation Rules. Check both active custom rules and the custom error text returned to HubSpot. Start with a distinctive phrase from the message, the field named in the error, or the HubSpot property mapped to that field. A validation rule can depend on multiple fields, so the field called out in the message may not be the only condition to review.
Salesforce defines a validation rule as a formula that returns true or false. When its error condition evaluates to true, Salesforce blocks the save and displays its configured message. Salesforce also says that validation rules apply to new and updated records even when the fields referenced by the rule are not in the page layout or the API request. Therefore, a field that HubSpot did not send can still influence the result through its existing value, a related field, or a formula condition.
Check when the rule is expected to apply: record creation or later updates, a particular status, record type, owner, conversion state, or combination of fields. Compare those conditions with the actual record at the time of the failed sync. If the record has changed since then, its current state may not reproduce the original failure.
Do not assume the rule is defective just because HubSpot’s API call failed. The rule may be enforcing a real business requirement, while the integration is sending incomplete or out-of-sequence data. Conversely, a rule may unintentionally block a legitimate update because its formula assumes every save comes from a human using a particular page or workflow.
Compare the attempted change with the rule conditions
For the affected record, compare the source values in HubSpot with the Salesforce fields that the rule evaluates. Pay particular attention to conditions based on fields the integration does not normally map, existing values that were never cleared, and logic that runs only when a record changes from one state to another. If the error happens only on create or only on update, preserve that distinction while the Salesforce admin reviews the formula.
Salesforce advises considering assignment rules, field updates, field-level security, and hidden fields when testing validation rules. Also distinguish permission failures from formula failures: a Salesforce field-permission or insufficient-access error calls for a permissions check, while a validation-rule message calls for formula and record-context review.
If the rule was recently changed, compare its active version, error text, and deployment timing with the first failed sync. If several rules can reject the same object, have the Salesforce admin review them together; changing the first visible rule may simply expose a second failing condition.
Use Salesforce debug logs when the rule is not obvious
When Sync Health does not reveal the rule name or the error message is generic, a Salesforce admin can set a temporary user trace flag for the Salesforce account that performs the integration transaction, if that actor can be identified. Reproduce one controlled failure, then inspect the Validation log category. Salesforce documents events that can include the validation rule name, whether it passed or failed, the error, and the formula and values that were evaluated.
Use a narrow time window and remove the temporary trace flag after the check. Debug logs can include record data and have size and retention limits, so restrict access and retain only what is needed for the diagnosis. A Salesforce admin should confirm the trace flag is attached to the actual API transaction user rather than assuming it is the HubSpot record owner.
Choose a narrow correction and test it before resyncing
| What the evidence shows | Correction to evaluate | What to preserve |
|---|---|---|
| HubSpot value violates an intentional business condition | Correct the source data or required upstream step so the record meets the rule. | Keep the business control; do not mask the failure by changing unrelated fields. |
| The rule blocks a legitimate integration update | Have the Salesforce owner review whether the formula should distinguish this supported update path. | Any exception should be narrow, documented, tested, and owned by Salesforce administration. |
| Several rules or automations change evaluated fields | Reproduce the transaction in a sandbox or controlled test and review rule/flow order and changed values. | Do not deactivate multiple rules together; that hides which condition failed. |
| The message is Invalid Salesforce ID or another mapping error | Correct the reference-field mapping or investigate the exact validation rule mentioned by HubSpot. | Keep mapping failures separate from custom-code validation failures. |
Do not deactivate all validation rules as a quick fix. If Salesforce decides that a rule needs an integration exception, the admin should test a narrowly scoped change with the record owner and security requirements in view. Salesforce recommends testing validation rules before activation because a poorly designed rule can prevent valid records from being saved.
Where a sandbox or controlled test record is available, verify both the legitimate integration update and the business cases the rule is meant to block. Then return to the original HubSpot Sync Health error and resync one affected record. Confirm that the same record pair remains in place, the intended Salesforce values saved, and the exact error cleared before expanding to other records.
Prevent the error from returning
- Include a representative HubSpot API create/update in Salesforce validation-rule testing, not only a manual UI edit.
- Keep a named Salesforce owner for rules that affect HubSpot-mapped objects.
- Document which fields HubSpot supplies, which system owns each value, and when validation is expected to block a record.
- Test changes to formulas, record types, flows, and field mappings against both valid and intentionally invalid examples.
- After a deployment, review Sync Health for new affected records before running a bulk resync.
Common questions
Can a Salesforce validation rule block an API update?
Yes. Salesforce states that validation rules apply to new and updated records, including integrations, even when a referenced field is absent from the API request or page layout. Check the exact rule and transaction context.
Should I turn the validation rule off to restore sync?
Not as a default. First determine whether the HubSpot values are wrong, the update is incomplete, or the rule rejects a legitimate integration path. A Salesforce administrator should approve and test any narrow rule change. Turning a rule off broadly can allow records that the rule was designed to stop.
Is a validation-rule error the same as a Salesforce Flow failure?
No. HubSpot lists Salesforce custom field validation rules and Salesforce Flow as separate custom-code error examples. If Sync Health identifies a Flow, use the separate Salesforce Flow diagnostic; if it names a validation rule, inspect the rule formula and Validation log evidence.
Sources and scope
This workflow is based on HubSpot’s named Salesforce sync-error categories and Salesforce Help on validation rules, debug logs, and save-order behavior. HubSpot may show only a summary error; this guide does not assume that every error includes the rule name or formula. Confirm the actual record and message in Sync Health before changing a production rule.
Related reading: HubSpot Salesforce integration sync errors · Salesforce validation rules · Salesforce debug log levels · Salesforce debug logs · Salesforce validation-rule tips.
How did this article land?
Choose one reaction. You can change it anytime.