The integration is connected. Yesterday’s customer update is still missing. Sales has made the correction twice, operations has a screenshot, and somebody is about to suggest disconnecting everything and starting again.
Before you do that, make the failure somebody’s job. A useful sync process tells your team which records need attention, what stopped them, and who should act next. Connecting the apps is the beginning. Dealing with the awkward records is the work that follows.
Start with the sync information you already have
For supported HubSpot data sync apps, open Settings, then Integrations, Connected Apps, your app, and CRM syncs. Object view shows records in sync, failing, or excluded. Open a failing record’s Sync Activity details to inspect the reported reason.
Check Excluded as well. A record can be outside the sync because of filters or a missing matching identifier. That calls for a different decision than repairing an attempted update. Review the reason before treating every absent record as an error.
These controls are documented in HubSpot’s data sync guide, checked on October 15, 2026. The guide also describes queue states and selecting individual records to rerun from Record view.
Other marketplace apps and custom integrations may expose different logs and recovery tools. Confirm which integration you are looking at before following instructions meant for native data sync. Start with its existing diagnostics rather than building a second dashboard that says the same thing.
Write down the failure, not just the complaint
“The sync is broken” does not give the next person much to work with. Use one place to track issues that need intervention, whether that is your existing task system or an integration support queue.
Keep the entry short enough that someone will actually maintain it. Include the information needed to investigate without copying unnecessary customer data into another system.
- Affected record: Link to the record in HubSpot and, when accessible, its counterpart in the other app.
- Expected result: State which change should have arrived and in which direction.
- Observed failure: Record the relevant error, when it was observed, and whether one record or a wider group is affected.
- Business impact: Explain what is waiting, such as a sales handoff, service update, or internal report.
- Owner and next action: Name the person investigating and what they will check next.
Track related failures together when they share a cause. Fifty records blocked by one missing dropdown option probably need one investigation with a list of affected records, not fifty separate emergency meetings.
Assign the next action to the right person
The person who notices the problem does not always have permission to fix it. Separate coordination from the actual correction.
A CRM administrator might resolve a mapping issue. The owner of the source data might confirm an invalid value. An application administrator might need to restore access. A developer may need to investigate a failing custom service. Name a backup for each responsibility.
Set response expectations around the business process. An update needed for a customer-facing handoff deserves different attention from a nonessential field used in a monthly report. Choose a review cadence that fits the consequences of waiting.
Give the coordinator a clear escalation path when the assigned person cannot act. “Someone in IT” is a department, not an owner.
Fix the cause before repeating the request
A retry is useful after a temporary interruption or a correction. It is not a substitute for understanding why a record failed. Sending the same invalid value again mostly demonstrates persistence.
For example, suppose a source system sends a service category that the destination does not recognize. Confirm the intended category with the business owner before changing the data or adding an option. Do not invent a replacement just to clear the error.
If the systems disagree about which value should win, return to your field ownership rules before making corrections. Repair the agreed source and check the destination afterward.
For custom integrations, document what happens if the same request is processed twice. Ask the developer how retries avoid creating duplicate records or repeating side effects. Keep an intentional deletion separate from a failed update so a recovery step does not quietly recreate something the team removed.
Limit the first recovery attempt to the affected records where the integration supports it. Avoid broad configuration changes while you are still establishing the cause.
Verify the result that the business needs
After the retry, check the destination record rather than stopping at a successful action message. Confirm that the intended value arrived on the correct record and that any required relationship is still present.
Then check the next step. If a status update was meant to stop a follow-up sequence or inform an owner, verify that behavior in a controlled way. A successful transfer and a successful business handoff are separate checks.
Close the issue with a brief note covering the cause, correction, and verification. If a manual workaround was used, record what still needs to be reconciled. The next person should not have to reconstruct the incident from a screenshot called final-final-2.
Put custom sync status where people work
Our Hunter Business School case study shows one reason a custom interface can be worthwhile. Admissions moved to HubSpot while administrators and instructors continued using Microsoft Access. The integration includes a contact-record UI extension displaying live sync status and a write-back action.
That is a specific implementation, not a standard feature promised by every connector. The lesson is to make the relevant status visible to the people who depend on it. It does not mean every integration needs a custom card.
If native diagnostics and a named owner are enough, use them. If staff repeatedly need help answering whether a record reached the other system, define that missing visibility as a concrete requirement before commissioning custom work.
Keep the recurring problems on the agenda
Review unresolved issues and repeated causes on a schedule your team can sustain. Look at the oldest blocked work, the errors that keep returning, and the manual corrections people make outside the documented process.
Fixing one record gets today’s work moving. Updating a validation rule, mapping, or support procedure may prevent the same problem tomorrow. Choose the correction based on the evidence, then test it on a small set before expanding.
Start with one integration: identify its failure view, name its support owner, and write the recovery steps someone else could follow. Schedule a call with No Bounds Digital to review the gaps between your sync tools and the process your team needs.
