This is the checklist we run on our own builds, published in full. Work through it yourself, hand it to your admin, or use it to interrogate whoever is quoting you. Nothing here is gated and nothing is withheld — a reader who ships a clean integration from this page is the point.
Trusted by 500+ organizations — including B2B SaaS and technology companies running marketing in HubSpot and revenue in Salesforce with Twopir Consulting.
Readiness & Go-Live Assurance
This is the pre-launch checklist for a Salesforce HubSpot integration, organised into four gates: prerequisites you need before configuring anything, architecture decisions that must be made rather than defaulted, pre-launch validation that proves the build behaves under failure as well as success, and post-launch governance that keeps it accurate afterwards.
Two rules make a checklist like this actually work. Every item needs a named owner — not a team, a person. And every item needs a recorded result — a written yes with evidence, not a verbal "that should be fine" in a stand-up. Checklists fail as social documents where everyone assumes someone else confirmed the item.
The three checks skipped most often, in our experience, are the same three every time: testing what happens when a write is rejected rather than only testing the happy path; budgeting the API call allocation against the planned launch-day volume; and assigning a named human to receive sync error alerts. All three are cheap before go-live and expensive after it.
Twopir Consulting publishes it as a working reference. We are a Salesforce Partner and a HubSpot Partner helping growing and mid-market companies solve complex CRM, integration and business system challenges, alongside enterprise organisations on the same stack. Gate 01 in particular should be checked against HubSpot's current installation documentation at the time you install — supported editions and required permissions do change, and no third-party summary should be trusted over the vendor's own.
Use this however is useful — run it yourself, hand it to your administrator, or use it to interrogate a quote. If an implementation partner cannot show you their answers to Gate 02, that is worth knowing before you sign. For the reasoning behind the architecture items, see Salesforce HubSpot architecture; for the sync-layer items, Salesforce HubSpot data sync; and if something on the list has already gone wrong, the common failures page covers the fixes. All of it sits under our integration services.
Work the gates in order. An item that cannot be confirmed is a no-go for that gate, not a note to revisit later — that distinction is the whole value of a gate.
Gates only work if the pass criteria are explicit. These are the ones we hold ourselves to, including the items that most often get waved through.
| Gate | Pass means | Most commonly waved through |
|---|---|---|
| 01 — Prerequisites | Edition, permissions, dedicated integration user and a refreshed sandbox all confirmed in writing, with the integration user's profile documented. | The dedicated integration user — teams use an admin's personal login, then lose the sync when that person changes role or leaves. |
| 02 — Architecture | The source-of-truth matrix exists, lifecycle definitions are signed by both marketing and sales, and the inclusion list criteria are agreed. | Lifecycle definitions. Everyone nods in the meeting; nobody writes them down; the disagreement resurfaces as a reporting dispute two quarters later. |
| 03 — Pre-launch | Sandbox-proven on representative data including the three failure cases, dedupe strategy tested with merge order, API allocation set with confirmed headroom. | Failure testing. The happy path is tested thoroughly and rejection behaviour is not tested at all — which is the behaviour that actually determines whether drift is visible. |
| 04 — Post-launch | A named person receives alerts, allocation headroom is monitored, both systems reconcile to one number, and a quarterly review is scheduled with an owner. | The named owner. "RevOps will keep an eye on it" is not an owner, and it is the single best predictor of an integration that degrades within a year. |
These are not hypothetical. Each one below is a check from the list above, and the failure it reliably produces when it is waved through under deadline pressure.
The sync runs under someone's personal login. When that person changes role, leaves, or is caught in a permissions cleanup, the integration stops — and nobody connects the two events for days.
Every field effectively has two owners and the last automation to run wins. Two years later nobody can change anything safely because nobody knows what depends on what.
Every HubSpot contact reaches the CRM. Reps lose confidence in the record queue within weeks, and rebuilding that trust takes far longer than the list would have taken to build.
Rejected writes accumulate silently in the error queue. The first person to notice is whoever runs the quarterly report, by which point months of divergence exist.
Launch-day volume or the first bulk import exhausts the allocation. Records queue, the integration can be suspended, and it happens during the week everyone is watching.
Alerts route to a shared inbox that nobody owns, which is operationally identical to having no alerting at all — with the added disadvantage that everyone believes it is covered.
The checklist is the artefact; the cadence is what makes it hold. This is the rhythm we use, and it transfers to an internal team without us.
Every item gets a named owner before any configuration begins. Unassigned items are the ones that get waved through, and assignment takes an hour.
Each gate is a review with a pass or no-go outcome recorded against every item. A status call reports progress; a gate review makes a decision.
A pass means a screenshot, a test result or a document — not a verbal confirmation. This is the difference between a checklist and a formality.
Gates that never fail are not being enforced. A no-go at Gate 03 costs days; the same problem discovered in production costs weeks and reputation.
Alerting, reconciliation and the quarterly review are handed to a named owner before the engagement closes, because integration drift starts the week after go-live.
You do not need us to use this list. These are the engagements where teams find outside help genuinely changes the outcome.
We run the checklist against your planned or in-flight build and tell you where you are, before you commit to a go-live date.
An independent review at Gate 03 — the last point at which problems are cheap. Frequently bought as a single engagement.
We take the items your team cannot cover and run them alongside your admin, rather than taking the whole project.
The post-launch layer teams most often lack capacity for. Alerting, monitoring and the quarterly review, owned by us until you want it back.
A North America B2B SaaS engagement delivered through this gate model — diagnostic to governance handover, with Gate 04 assigned before the project closed.
The diagnostic surfaced three problems we did not even know we had. By the time we saw the field mapping spec, it was obvious why the previous sync had been silently corrupting data for months. What impressed us most was that every decision was documented — we were not handed a black box. We owned the system at handover.
Five phases, each validated before the next began, closing with a field ownership matrix, a sync health dashboard and a quarterly audit checklist.
A checklist behind an email form is a lead capture mechanism pretending to be a resource. This one is complete on the page.
Not a marketing abridgement. These are the gates our own builds pass through, including the items that make projects slower.
Gates that never fail are not gates. A delayed go-live is a cheaper outcome than a launched integration that quietly corrupts data.
Failure-case testing is the most-skipped check on the list and the one that most reliably determines whether drift stays visible.
Named alert ownership, monitoring and a scheduled review, handed over. Integration drift starts the week after go-live, not a year later.
If you are evaluating partners, ask each of them for their answers to Gate 02. The list is public precisely so it can be used that way.
A Salesforce edition with API access — Professional, Enterprise, Unlimited or Government Cloud, but not Group Edition; a Salesforce system administrator to install the managed package; account access permissions on the HubSpot side; a dedicated integration user with edit rights on every object you intend to sync; and a refreshed sandbox. Requirements do change, so confirm against HubSpot's current installation documentation at the time you install rather than relying on any third-party summary, including this one.
Because a sync running under a person's login is one role change away from breaking. A dedicated integration user isolates sync activity from individual accounts, which makes permission management and troubleshooting tractable and gives you a clean audit trail of what the integration did versus what a human did. It also survives staff turnover, which a personal login does not. Budget for the licence — it is a real cost and a small one relative to the failure it prevents.
Failure-case testing. Teams test thoroughly that records sync correctly and almost never test what happens when a write is rejected by a validation rule, an unmatched picklist value or an exhausted API allocation. That matters because rejection behaviour is what determines whether divergence stays visible or accumulates silently — and silent accumulation is how most of the integrations we are asked to repair got that way.
Yes. Sync behaviour, validation-rule interactions and picklist parity all need to be proven against representative data before touching production, and failure behaviour especially needs somewhere safe to be observed. Configuring directly in production means your first observation of any failure mode happens against live records that reps are working. The sandbox is the cheapest insurance in the whole project.
Set it deliberately in HubSpot against your actual Salesforce API limit rather than leaving it at a default, then model launch-day volume and your first planned bulk operation against the headroom that leaves. Imports, list re-scores, mass property updates and large sends are the operations that consume allocation fastest. Monitoring headroom continuously — with an alert before it is consumed rather than after — is what prevents the suspension that otherwise arrives during the week everyone is watching.
Yes, and that is the intent. It is complete as published, with no gated section and nothing withheld. Assign each item a named owner, require evidence rather than assertion at each gate, and treat a no-go as a normal outcome. Teams with a capable administrator and enough time run this successfully on their own; where we tend to add value is failure testing, architecture decisions and the post-launch governance layer that teams rarely have capacity for.
It is a good use for it. Ask any partner quoting you for their answers to Gate 02 — the object model decision, the source-of-truth matrix, the lifecycle definitions and the inclusion list criteria. A partner who has thought about your build will have positions on all four, or will say clearly that they are discovery items. A partner who treats them as details to sort out during configuration is telling you something useful.
The checklist is complete above and free to use. If you would rather have the gates run independently — particularly Gate 03, where problems are still cheap — that is a single scoped engagement.
Salesforce Partner · HubSpot Partner · Serving US, Canada, UK, UAE, Australia & New Zealand
