SMS Consent, Telephony, and Compliance in the HubSpot–Salesforce Integration

Published by Bles Software, a custom software and AI company based in Yehud-Monoson, Israel, building web apps, AI agents and API integrations for clients in Israel, the US, the UK and the EU.

Email consent is only half of modern outreach. Many teams run phone and SMS programs through Salesforce‑connected telephony (e.g., Twilio, RingCentral, Five9) while marketing subscriptions and email opt‑out live in HubSpot. The result is a multi‑channel consent problem: how do you maintain a single source of truth for reachability, prevent conflicting automations, and respect regional laws like TCPA, GDPR, and country‑specific do‑not‑call rules? This playbook provides a clear, channel‑aware approach to modeling phone and SMS consent in a HubSpot–Salesforce integration so you engage confidently without legal risk or operational chaos.

Channel‑aware consent model

Separate consent by channel. Create explicit properties for Email Opt‑out, SMS Opt‑in, Voice Do Not Call, and a small “Consent Legal Basis” set per channel where applicable. Consolidate these into a human‑readable “Reachability” property (e.g., Emailable + SMS Allowed; Emailable only; No Marketing Reach) that drives segmentation. HubSpot should remain authoritative for email subscription types; Salesforce commonly becomes authoritative for phone and SMS when telephony systems integrate there.

Record consent source and timestamp per channel. For SMS, store the keyword (“START,” “STOP”), shortcode or number, and the system that captured it. For voice, store the origin (do‑not‑call list import, rep selection, customer request) and any region constraints.

Forms, keywords, and capture flows

Do not infer SMS consent from an email checkbox. If you invite SMS participation on a form, present clear, localized disclosures (message frequency, data rates, how to opt out) and enforce double confirmation by sending a confirmation keyword flow. For inbound keyword programs, treat the telephony system as the capture source and mirror results to Salesforce and HubSpot.

Routing and automation guardrails

SMS and voice outreach must respect consent at the moment of send. Build a single guardrail function in your telephony platform or middleware that evaluates the up‑to‑date consent state before placing a call or sending a message. For HubSpot workflows that trigger SMS via an integration, call the same guardrail; do not embed duplicated logic in multiple places. When consent flips (a “STOP” arrives), suppress all channel automation immediately and write a timeline event to both systems for audit.

Data model in Salesforce

In Salesforce, add a small, explicit schema:

Mirror HubSpot Email Opt‑out and subscription types read‑only for visibility. For accounts with multiple contacts, compute a simple “Account Reachability” roll‑up to guide campaign planning without exposing raw PII more broadly than necessary.

Telephony integration specifics

Whether you use Twilio or another provider, treat it as a peer system with its own audit trail. Create a nightly reconciliation that compares opt‑out and opt‑in counts by day and flags mismatches. Where possible, subscribe to webhook events for keyword changes and write them through a single handler that updates Salesforce and HubSpot consistently.

Regional compliance

Laws vary. Bake region into your rules. For the US and Canada, enforce TCPA and carrier policies; for the EU, align with GDPR and ePrivacy, often requiring explicit consent for marketing SMS. In APAC, apply country‑specific do‑not‑call registries. Store the “legal region” per record and evaluate it at send time. If you’re unsure, default to suppression and require a human decision before resuming outreach.

Observability and incident response

Publish a weekly consent report per channel: net changes, top sources (forms, keywords, imports), and error rates for attempted sends with missing or invalid consent. In incidents (for example, a mistaken bulk SMS), stop sends, mark affected records with a temporary suppression reason, notify recipients if required, and publish a short retrospective that covers root cause and prevention. Small, fast responses protect trust.

Operating model and reviews

Meet monthly with marketing ops, sales ops, and legal to review consent movements and policy changes. Use a simple RACI for updates to consent capture (forms, scripts), telephony configuration, and integration logic. When regions update rules, capture the change in a versioned playbook and add tests to the guardrail function.

FAQ

Where should SMS consent live—HubSpot or Salesforce?

If telephony is integrated with Salesforce, store SMS consent there and mirror to HubSpot for segmentation. If HubSpot drives SMS via a provider app, you can store it in HubSpot; still mirror to Salesforce so reps have visibility. The key is a single authority with reliable mirrors.

How do we migrate historic consent?

Import with a clear source and date. For stale records with no clear history, default to Unknown and require a fresh opt‑in. Avoid mass “assume consent” migrations; they create risk and erode deliverability.

Can we use intent data to justify SMS outreach?

No. Intent is useful for prioritization, not legal basis. Use it to guide calling order once consent exists, not to replace consent.

How do we handle shared phone numbers?

Tie consent to the person and the specific number. If multiple contacts share a number, a STOP from one should suppress that contact; depending on jurisdiction and your risk posture, you may need to suppress the number across contacts. Document your policy and encode it in the guardrail.

What about WhatsApp and other channels?

Treat each channel with its own consent state and legal posture. Do not generalize SMS consent to chat apps unless the policy clearly allows it and the user has opted in for that channel. Keep your model extensible so you can add channels cleanly.

More RevOps Playbooks from Bles Software