Who this is for
A sales operations or revenue operations manager whose HubSpot and Salesforce disagree about one field, or whose edits to that field keep changing back.
Someone fixes a value, and a day later it has reverted, or a new picklist choice never arrives in the other system.
The result
For one named field on a synthetic test record, a change made on the agreed side reaches the other side, still holds after the next sync settles, each agreed picklist value syncs, and the sync health view shows no new error for that field.
What is included
- One mapped field pair on one object, such as contact or lead, with its current sync rule and type compatibility read
- Diagnosis of the cause: sync rule direction, first-sync baseline, picklist or type mismatch, field permission or a Salesforce-side automation
- Correct the mapping rule, or add a missing picklist option so its HubSpot internal value matches the Salesforce one, as agreed; name any Salesforce-side change, and any change to an existing property's type, for the right person to make
- Test on one marked synthetic record in each direction and for each agreed picklist value, in a Salesforce sandbox or behind the safeguard your Salesforce administrator confirms, then watch for the agreed window
You receive
- A short diagnosis naming the cause, with the field's sync rule before and after
- Change notes for every mapping rule change and every option added, and the Salesforce-side changes your administrator needs to make
- The synthetic record log: value changed, direction, value seen on the other side and time of observation
- A note on any field mapping that conflicts with this one, and on any property type change that would be needed, with the export HubSpot recommends before it
What is not included
- Connecting the integration, adding new object syncs or mapping other fields
- Changing an existing property's field type, or renaming or removing existing options: HubSpot warns that a type change can invalidate the values already stored and recommends exporting first, so a type change is a separate step you run after an export, or a separate quote
- Changing Salesforce flows, validation rules, duplicate rules or permission sets, which your Salesforce administrator owns
- Clearing a backlog of old sync errors or re-syncing historical records in bulk
- Data clean-up, merging or deleting records
- Real customer records or any message sent to real contacts during testing
What we need from you first
- The HubSpot property and Salesforce field names, the object and the sync rule you believe applies
- What goes wrong, in a sentence: reverts, never arrives, or shows an error, and its redacted error text
- Which side should win, and whether both sides are edited by people
- Do not send record exports, passwords or an account invitation in the first enquiry
Never send passwords, keys, customer records or confidential code in the first enquiry. Secure handover is agreed after scoping.
How we check it is done
- A change to the named field made on the agreed winning side of a synthetic test record appears on the other side and is still present after the agreed observation window.
- A change made on the other side behaves exactly as the agreed sync rule says, either arriving or being deliberately overwritten, and the handover states which.
- Each agreed picklist value syncs from one system to the other without a sync error for that field.
- The notes list every mapping rule change with its previous rule, every option added, and every Salesforce-side change handed to your administrator.
- The marked test record was created only in the sandbox or behind the safeguard your administrator confirmed in writing, no flow, assignment rule or notification acted on it, and it was deleted afterwards.
You inspect the record log and the change notes, then sign off before payment. Your administrator makes any Salesforce-side change and you watch one genuine record.
When we would stop or decline
- The integration is suspended or disconnected, which needs the account holders first
- The cause is a Salesforce flow, validation rule or permission that no administrator will change
- The test record would sync into live Salesforce and no administrator can confirm it will be left alone by flows, assignment rules and notifications
- The only possible test is on live customer records that sales staff are working
- The cause can only be fixed by changing an existing property's type, which this job does not do
Questions
Why does a value I fix keep changing back?
Usually a sync rule such as prefer Salesforce unless blank, or always use Salesforce, overwrites the HubSpot edit. A Salesforce flow can also rewrite it. The diagnosis tells you which.
Will you re-sync all my old records?
No. This job fixes the rule for one field and tests it on a synthetic record. Bulk re-syncing or cleaning up history is a separate scope.
Do you change Salesforce?
We name any change needed there. Your Salesforce administrator makes it, because flows, validation rules and permissions are yours to approve.
Will you change the type of my HubSpot property?
No. HubSpot warns that changing a property's field type can invalidate the values already stored in it, and recommends an export first. If the diagnosis shows a type change is needed, we say so and it is a separate step you run after an export, or a separate quote.
Will a test record appear in my live Salesforce?
Only if you have no sandbox and your Salesforce administrator confirms in writing that flows, assignment rules and notifications will leave one marked record alone. Otherwise we stop, because we will not test where a real person could be contacted.
Price and terms
£295 · untested offer price. £295 after the agreed checks pass and you sign off. No payment before sign-off.
This is a new service with no published client results. The price is a starting point we have not yet tested with buyers. Nothing is ordered or charged by the enquiry. The full specification is on the Synthetic Industry catalogue.