A green integration status is a tempting place to close an outage ticket. Marketing can see its contacts again; sales can get back to work. But if a conversion belongs in a Salesforce campaign, finding the contact is only part of the check. Recovery should be judged against the handoff you intended, before anyone starts replaying workflows to make the numbers look complete.
The September 24 HubSpot-Salesforce incident makes that distinction worth taking seriously. HubSpot's incident report describes unexpected disconnection and temporary marketplace unavailability for some customers, followed by restored service. A missing connector was therefore not, by itself, a reason to assume somebody had removed it. Check the vendor status alongside your audit trail before treating a service incident as a configuration problem.
Give ordinary sync a chance
The strongest argument against a custom recovery job is that you might not need one. HubSpot expected data to refresh when the integration returned. Its sync documentation describes checks for new or updated information approximately every 15 minutes, subject to configuration and field mappings. It also offers manual record resync and, on eligible plans, segment resync.
Start there when the problem is an out-of-date record and the existing sync rules are correct. A controlled mapped-property change can trigger sync too, although changing live data simply to force movement deserves more care than clicking a dedicated resync control. A recovery script should solve a demonstrated gap, not compete with an integration that is already catching up.
That restraint matters in a two-system setup. Keeping marketing in HubSpot and sales in Salesforce can be a sensible division of work. An outage does not automatically make that arrangement redundant. It does make the boundary between the systems the place to inspect.
A contact and a campaign action are different checks
Take an affected conversion. Is the correct contact present in Salesforce? Are the mapped values right? Is the contact associated with the intended campaign, with the intended status? Did the relevant workflow action complete? Each question checks something different.
HubSpot's campaign-association guidance describes configured form associations and workflow alternatives. Our conclusion is narrower than claiming that restoration failed: a successful record sync is not evidence that every intended campaign action completed. We cannot establish which campaign actions, if any, remain missing in a particular account without its record and workflow history.
So check an affected sample before deciding to reenroll the entire outage cohort. If the records and campaign actions are already right, stop. If the records are right but membership is missing, repair that specific gap. Replaying a whole workflow because one action needs attention risks repeating the parts that already ran.
Repair the difference you can explain
For a confirmed backlog, define the outage window and the relevant created, updated, or converted contacts. Then compare what should exist with what actually exists, using stable cross-system IDs. Keep records already correct separate from records needing a write, and distinguish failures from cases that need a human decision. This is a proposed recovery discipline, not a promise that one backfill method fits every account.
Field ownership deserves the same precision. HubSpot's mapping rules determine which system wins a conflict; two-way rules can also propagate deletions. A newer-looking timestamp is a poor substitute for knowing which value should survive. Preserve those rules in any script rather than treating every difference as permission to overwrite.
An AI coding agent is an alternative to writing the reconciliation script yourself. Its useful job is to help identify differences and prepare a bounded change set. Giving it broad production access does not settle which records need repair, which fields it may change, or which campaign memberships already exist. Demand the same explicit scope and outcome checks from an agent that you would demand from a temporary workflow.
Run a small batch, inspect the resulting records and memberships, and check for unintended downstream actions before widening it. Keep a record of what was added, already present, failed, or held for review.
The ticket can close when the affected handoff checks out. Until then, the decision is whether to wait for native catch-up or repair a verified difference. A frantic second round of writes is not evidence of recovery either.