RevOps Playbook: Multi‑Org, Multicurrency, and Custom Objects in the HubSpot–Salesforce Connector

Q: What’s the safest way to manage identity across orgs?

Centralize person and account keys (email, domain, externalid). Gate creation with suppression windows, and mirror merge decisions back to HubSpot and the identity store.

Context

As go‑to‑market complexity rises—new regions, acquisitions, product lines—your HubSpot–Salesforce integration must support multiple Salesforce orgs, multiple currencies, and custom objects while preserving data quality and reporting consistency. This playbook describes scalable patterns for identity, routing, currency management, and object design, along with guardrails for the native connector and where to augment with middleware.

Challenges at a Glance

Identity drift across orgs and brands
Territory and routing divergence
Currency conversion and reporting roll‑ups
Custom object relationships that the connector does not natively model
Operational overhead without observability

North Star Architecture

HubSpot as engagement OS; each Salesforce org as pipeline and bookings truth for its region/brand.
A shared identity service: common person (email + user_id), account (domain + external_id), and opportunity (global external_id) keys.
A thin orchestration layer (middleware) to decide: which org should receive a record; how currencies map; when to promote enrichment into canonical fields.
Observability with per‑org logs and a unified health dashboard.

Multi‑Org Routing

Org selection rules: route by country/region, brand code, or go‑to‑market segment. Keep rules declarative and version‑controlled.
Credentials isolation: each org has dedicated integration users and secrets; no shared superusers.
Backpressure handling: if one org throttles, buffer and continue others; never block the entire flow.
Cross‑org visibility: if sellers need context from sister orgs, replicate read‑only summary fields rather than raw activity streams.

Identity and Deduplication Across Orgs

Person identity: normalize emails; maintain a global suppression list for role‑based addresses; allow secondary emails for mergers and rebrands.
Account identity: domain is primary; add a global customer_id. For conglomerates, designate a commercial hierarchy and roll up ARR.
Opportunity identity: stamp a global external_id on creation from HubSpot or middleware; persist in Salesforce.
Merge strategy: centralize merges in each org but synchronize the result (survivor IDs) back to the identity store and HubSpot.

Multicurrency Strategy

Currency codes: standardize on ISO 4217 across orgs (USD, EUR, GBP, JPY, etc.).
Opportunity reporting: Salesforce remains the authority for amount and currency; push converted amounts (to a corporate reporting currency) to HubSpot for marketing‑level dashboards.
Conversion rates: manage centrally (finance‑approved); apply at the time of cohort stamping (opportunity_created_cohort_ym) so historical views stay stable.
Display logic: in HubSpot, show corporate currency for roll‑ups and local currency for program views.

Custom Objects

When native objects are insufficient:

Naming: use clear names (Subscription__c, Implementation__c) and avoid overloading Deals/Opportunities.
Relationships: model master‑detail appropriately (Subscription__c → Account; Subscription__c ↔ Opportunity via lookup). Mirror only the fields HubSpot needs for segmentation or nurture.
Connector limits: the native connector cannot sync arbitrary custom object graphs. Use middleware to project minimal, denormalized fields to HubSpot (e.g., active_subscriptions_count, plan_tier, renewal_date) and keep the rest in Salesforce.

Field Ownership in Complex Environments

Truth matrix per org: list which system writes each field; ensure parity across orgs unless a justified exception exists.
Shadow fields: for enrichment and inference; promote to canonical only when safe.
Guard bidirectional fields: identical picklists in all orgs and in HubSpot; cooldown logic to prevent thrash.

Observability at Scale

Per‑org pipelines: separate queues and metrics; alert on backlog depth and error burst by org.
Global dashboards: duplicates, identity conflicts, SLA breaches, error taxonomy breakdown, and currency conversion success rate.
Audit trails: store mapping versions, routing rule versions, and conversion rate versions with timestamps.

Rollout Pattern for a New Org

Blueprint: clone the core dictionary, lifecycle, and routing templates; adapt only where law or commercial rules differ.
Dry run: simulate routing with historical data; validate against territory design.
Pilot cohort: enable for one segment/region first; measure SLOs and user adoption.
Full enablement: expand scope; train users; publish a hypercare channel.

Common Anti‑Patterns

Letting each org reinvent fields and picklists—creates reconciliation nightmares.
Syncing full custom objects to HubSpot—UI becomes noisy and fragile.
Ignoring currency versioning—historic reports drift when FX rates change.
Shared integration superuser—hard to audit and easy to over‑scope.

Practical Tips

Keep a short allowlist of properties mirrored to HubSpot for segmentation; archive anything not used in workflows for 90 days.
Derive “reporting‑ready” booleans (has_active_subscription, is_enterprise_customer) in middleware from custom objects.
Provide a “which org wrote this value?” field for debugging.
Stamp a global “integration_profile” (brand, region, org_id) on records for traceability.

FAQ

How do we decide which Salesforce org should own a record?

Use a declarative routing table keyed by country/region, brand, or segment, and version it. Route deterministically and record the decision on the record for traceability.

Can the native connector handle custom objects?

Not generically. Use middleware to project a small set of derived properties into HubSpot. Keep custom object complexity inside Salesforce.

How do we keep currency reporting stable over time?

Apply finance‑approved FX rates at the time you stamp cohort fields and retain the rate version. Do not retrospectively recompute historic values unless finance directs it.

What’s the safest way to manage identity across orgs?

Centralize person and account keys (email, domain, external_id). Gate creation with suppression windows, and mirror merge decisions back to HubSpot and the identity store.

How do we add a new org without breaking the others?

Isolate credentials and queues, dry‑run routing, pilot with one segment, and maintain per‑org alerts. A failure in one org should never block others.