Connect HubSpot or Salesforce

Bring your CRM contacts into CoverGuard so every new lead gets a property check without anyone re-typing an address. You add your credentials once, CoverGuard checks them against your CRM, and the connection arrives already mapped — there is no field-matching step to work through.

Who this is for

Real estate agents, mortgage professionals, and insurance brokers on a Professional plan or above who run their book in HubSpot or Salesforce. You'll need permission in your CRM to create a private app (HubSpot) or approve a connected app (Salesforce) — if you don't have it, your CRM administrator does.

You'll find it at Sys Admin → Integrations → Connect a new system.

Not seeing HubSpot or Salesforce in the list? They're enabled per account. Ask your CoverGuard contact to switch the connector on.

The app is yours

For both CRMs you create the app in your own account and give CoverGuard its Client ID and Client Secret. Nothing has to be set up on CoverGuard's side, and you keep the controls: the app is listed in your CRM under your name, you decide its scopes, and you can revoke it there at any moment without involving us.

The scopes you'll want either way:

• crm.objects.contacts.read / api — required, so CoverGuard can read your contacts.
• Write access — only if you want CoverGuard to send results back.
• crm.objects.deals.read — only if you want your deals in the CoverGuard pipeline. Without it contacts still sync and deals are skipped.

Connect HubSpot

HubSpot gives you two ways in. Pick whichever your IT policy allows — CoverGuard offers both on the connect screen.

Your own OAuth app (the default):

1. In CoverGuard, open Sys Admin → Integrations, choose HubSpot, and pick what you want it to do. The connect screen shows a callback URL — copy it.
2. In HubSpot, create an app with OAuth enabled — Settings → Integrations → Private Apps → OAuth, or a public app in your developer account — and paste that callback URL into its redirect URLs. HubSpot rejects the sign-in if the app doesn't list it.
3. Add the scopes above. For the write-back you also need crm.schemas.contacts.read and crm.schemas.contacts.write, so CoverGuard can create its own fields on the contact record.
4. Copy the app's Client ID and Client Secret.
5. Back in CoverGuard, paste both values and select Connect, then approve access at HubSpot.

A private app token (no app to register — one value, pasted):

1. In HubSpot, go to Settings → Integrations → Private Apps and choose Create a private app.
2. Name it something you'll recognise later, like "CoverGuard", and add the scopes above.
3. Create the app and copy its access token. It starts with pat-.
4. In CoverGuard, choose Paste your HubSpot private app token on the connect screen and paste it.

Either way CoverGuard checks the credentials against your portal before saving anything. If something's wrong or a scope is missing, you'll get a plain-English message and nothing is stored — correct the value and try again.

Connect Salesforce

Salesforce has no pasteable token, so you create a Connected App in your org and sign in through it.

1. In CoverGuard, open Sys Admin → Integrations and choose Salesforce. The connect screen shows a callback URL — copy it.
2. In Salesforce, go to Setup → App Manager → New Connected App, enable OAuth, paste that callback URL, and add the scopes above (api and refresh_token).
3. Save, then open Manage Consumer Details and copy the Consumer Key and Consumer Secret.
4. Back in CoverGuard, paste both values.
5. Choose your org type:

• Production / Developer for a normal org.
• Sandbox for a sandbox org.

Getting this wrong sends you to a login page your account isn't on, and sign-in will fail.

1. Select Continue to Salesforce, sign in, and approve access.

You'll come back to CoverGuard with the connection created. CoverGuard never sees your password — it receives a grant you can revoke in Salesforce at any time.

What you get

The connection arrives with a field mapping already applied. CoverGuard ships a tested mapping for each CRM, so contact details line up with the fields it needs for a property check:

Deals come across too — HubSpot deals and Salesforce opportunities land in your CoverGuard pipeline:

You can review and change it any time from the connection's page — nothing is hidden.

Only fields CoverGuard can actually use are mapped by default. Company name, for instance, is deliberately left out: there's nowhere for it to land, so mapping it would carry the value across and then quietly drop it.

Your own custom fields are handled separately. If your CRM has fields CoverGuard doesn't ship a mapping for, they're proposed for you to review rather than applied automatically. That split is deliberate: a mapping CoverGuard wrote and tested is applied on your behalf; a suggestion about your schema is yours to approve.

Sending findings back to your CRM

If you picked a goal that writes to your CRM, CoverGuard puts its findings on the contact record so your team sees them without leaving the system they work in:

These come from the most recently saved property on that client. A contact with no property checked yet syncs their details and nothing else — CoverGuard never writes a blank over a value you already have.

A brand-new lead won't have findings on the very first sync: the property check is queued when the lead is promoted and runs in the background, so its results go across on the next sync after it finishes. That's expected, not a failure — you'll see the contact appear first and the CoverGuard fields fill in shortly after.

On HubSpot this works out of the box. No CRM ships with a place to put an insurability verdict, and HubSpot lets CoverGuard create the properties for you. They appear in a CoverGuard property group on the contact record the first time a sync writes to them. Your private app needs crm.schemas.contacts.read and crm.schemas.contacts.write in addition to the contact scopes; if they're missing, CoverGuard tells you exactly which scope to add.

On Salesforce an administrator creates them once. Salesforce doesn't allow an app to add custom fields, so these arrive switched off. To turn them on:

1. In Salesforce Setup, go to Object Manager → Contact → Fields & Relationships.
2. Create each field you want, using the API names above with a CoverGuard_ prefix — for example CoverGuard_Insurability_Status__c (Text) and CoverGuard_Flood_Risk__c (Number).
3. In CoverGuard, open the connection's page and enable those fields in the mapping.

If you enable one before the field exists, the sync stops and names the exact field and type to create rather than pushing records Salesforce would reject one at a time.

What it means

• The app belongs to you, not to CoverGuard. Because you supply the client ID and secret, the connection runs through an app in your own CRM account. Revoking it there cuts access immediately, without asking us — and CoverGuard never has an app of its own sitting in your org.
• Your client secret is stored encrypted and never shown again. CoverGuard needs to keep it because renewing a connection's access is only possible using the app the access was granted to. No screen or API ever returns it.
• "Verified" is a real check, with a date. CoverGuard reads a few records from your CRM to confirm the connection works, and re-checks it daily. If your credential is revoked or expires, the connection stops reading as working rather than quietly failing later.
• You're told when a connection breaks. If that daily check finds your access has been revoked or has expired, CoverGuard notifies you — in the app and by email — so you learn your records stopped syncing from us, not from noticing a gap in your pipeline weeks later. You hear once per breakage, not once a day about the same problem, and reconnecting resets that. You can turn the email off under Account → Notifications → Connection problems; the in-app notification always shows.
• Contacts land in a staging area first. Synced records don't go straight into your client list — you review and promote them. Nothing appears in your book without you saying so.
• You can turn that review step off once you trust it. On the connection's page, tick Bring new records in automatically and every sync promotes what it pulled, so new leads reach your clients without you doing anything. It only ever adds new records — nothing already in CoverGuard is changed or overwritten. It's off until you turn it on, deliberately: staging is where a mapping mistake is still easy to undo.
• A contact with an address brings the property with it. When you promote a contact that has an address, CoverGuard creates the property and saves it against that client — so the lead arrives ready for a risk check instead of as a bare name and email. A contact with no address, or one that can't be matched to a real location, still promotes as a client.
• The property check runs on its own. Promoting a property starts its risk assessment automatically — you don't have to open each new lead to kick it off. The assessment pulls from FEMA, USGS, NOAA and the rest, so it finishes in the background a short while after the lead arrives rather than instantly. That means findings reach your CRM on the next sync after the check completes, not the same one that brought the lead in.
• Two leads at the same address share one property. A couple buying together, or the same lead imported twice, land on a single property record rather than two — so you see one home with one risk assessment, not a split view.
• Deals arrive attached to the right client. When a deal's contact has been promoted, the deal lands against that client. One that CoverGuard can't attribute — the CRM never linked it, or the contact hasn't been promoted — still appears in your pipeline with its stage and amount, unlinked, for you to attach.
• Stage names are matched, not assumed. Every CRM lets you rename pipeline stages, so CoverGuard reads the wording ("Closed Won", "Contract Sent") rather than a fixed list. A stage it doesn't recognise arrives as Prospect — deliberately the conservative end, so a renamed stage never inflates your close rate. Change it on the deal if it lands wrong.
• An expected close date isn't a close date. Open deals carry a projected close date in most CRMs; CoverGuard only records one once the deal is actually won or lost.
• Companies aren't synced. HubSpot companies and Salesforce accounts have nowhere to land in CoverGuard, so mapping them would carry the data across and then drop it. They're deliberately left out.
• Sending data back is opt-in. Writing into your CRM only happens if you choose a goal that includes it, and the connection page tells you whether write access was actually granted. CoverGuard only ever writes its own findings — it never overwrites the name, phone, or address you maintain in your CRM.
• What CoverGuard writes back is modeled. The insurability verdict and premium are CoverGuard's estimates, not an offer of insurance or a quote. Each field says so in its own description inside your CRM, so nobody reading it there mistakes it for a bound figure.

Tips

• Start with "pull contacts in". Get the inbound direction working and see real records before you turn on anything that writes to your CRM.
• Name your HubSpot private app clearly. It's how you'll find it later to check scopes or revoke access.
• A large book takes more than one run. The first sync works through your contacts in batches; later runs pick up where the last one stopped and only fetch what changed.
• HubSpot can push changes as they happen. If your CoverGuard contact has enabled it, HubSpot notifies CoverGuard the moment a contact changes and a sync runs within about a minute, instead of waiting for the next scheduled one. Nothing changes on your side — your connection, mapping, and schedule all stay as they are. Salesforce doesn't offer an equivalent that works without an administrator building it in your org, so Salesforce connections sync on their schedule.
• Revoke from your CRM, not just CoverGuard. Deleting the private app in HubSpot, or the connected app grant in Salesforce, cuts access at the source.

Troubleshooting

Do this next

• Reading a CoverGuard Record — what CoverGuard produces for each address it checks.
• Integrations (Sys Admin) — the rest of the Integration Hub: syncing, promoting records, and connection health.
• Connecting with your agent — link a real client account rather than importing a contact record.