RevOps Playbook: Managing Custom Objects and Multi‑Object Sync Between HubSpot and Salesforce

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.

As your go‑to‑market motion matures, standard objects alone rarely capture your revenue reality. You may run partner motions, track subscriptions, manage product usage events, or coordinate implementations—each with its own data model. The HubSpot–Salesforce integration can support these motions, but only if you deliberately design custom objects and relationships, and only if you’re crystal‑clear about which platform owns which slice of truth.

This playbook provides a pragmatic path to modeling and syncing custom objects, maintaining relationship integrity, and keeping automation understandable as your object graph grows.

When Custom Objects Are the Right Tool

Custom objects are a powerful solution when you need to represent repeatable, first‑class entities that don’t fit neatly into Contacts, Companies, or Deals. Common B2B examples include:

Subscriptions or entitlements tied to a product plan and term.
Implementations or projects with milestones and health.
Partner relationships and partner deals.
Products/Line Items for detailed quoting and revenue analysis.
Usage events or feature adoption summaries for product‑led motions.

When the concept has its own lifecycle, owners, and reports, it likely deserves a custom object. When it’s just metadata about an existing object, prefer fields or child records to keep complexity down.

Model Design: Keep It Explicit and Sparse

The more objects and relationships you add, the more opportunities for drift. Constrain complexity with three rules:

Each object must have a clear primary key and a stable natural key (e.g., Subscription ID, Partner Code). Avoid composite keys that require constant joins to answer basic questions.
Each relationship must have a purpose you can explain in a sentence (“A Subscription belongs to one Account and can be associated to the primary Contact who signed the order”).
Each field must have a single owner and a consumer list (who uses it and why). If you cannot name a consumer, do not create the field.

Ownership and Directionality at the Object Level

Decide which side creates and maintains each custom object:

Salesforce‑owned objects: Subscriptions, Implementations, Partner Accounts, and any entity tightly coupled to quoting, fulfillment, or revenue recognition. These should be created and updated in Salesforce, with a read‑only mirror in HubSpot for segmentation and automation.
HubSpot‑owned objects: Marketing programs that don’t warrant a Salesforce object (e.g., content subscriptions) or product usage aggregates used primarily for segmentation. These can be HubSpot‑native custom objects and mirrored to Salesforce only if sales needs read access in CRM.

Avoid true bi‑directional writes for custom objects. Pick a side, then mirror.

Relationship Integrity Across Systems

The value of custom objects comes from the relationships they encode—contacts to subscriptions, opportunities to implementations, accounts to partners. To keep those relationships intact across systems:

Use Stable External IDs

Assign an external ID to each record, write it once, and use it for sync and reconciliation. If the integration ever breaks or you need to re‑sync, external IDs let you reattach children without creating duplicates.

Mirror Only the Associations You Use

Resist the urge to mirror every possible relationship. Mirror the associations required for segmentation, routing, and reporting. For example, you may mirror “Subscription → Account” and “Subscription → Primary Contact,” but omit less critical associations from HubSpot to keep the object graph manageable.

Guard Against Orphaned Records

Create monitors that flag custom object records whose parent does not exist or no longer qualifies for sync. Establish a script or automation to reattach or suppress those orphans promptly.

Patterns for Common Custom Objects

The following patterns strike a balance between detail and maintainability.

Subscriptions

Key fields: Subscription ID (external), Account, Product Family, Plan, Term Start/End, MRR/ARR, Status, Auto‑Renew, Primary Contact, and Billing Owner.

Directionality: Salesforce‑owned. HubSpot mirrors for lifecycle automation (renewal reminders, adoption nurtures) and segmentation (e.g., upsell plays).

Lifecycle: Active, Grace, Cancelled. Write transition timestamps (Activation Date, Cancellation Date). In HubSpot, create date‑based workflows triggered by these fields.

Implementations/Projects

Key fields: Project ID, Account, Primary Contact, Associated Opportunity, Stage (Kickoff, Config, Test, Live), Target Go‑Live Date, Project Health, Risks.

Directionality: Salesforce‑owned if your implementation team works in CRM or in a PSA; mirror to HubSpot to trigger onboarding and adoption content.

Lifecycle: Timestamps for each stage entry; a boolean for “At Risk” with a reason code that marketing can use to prioritize success plays.

Partner Relationships

Key fields: Partner Account, Partner Tier, Partner Manager, Sourced Deals Count, Influenced ARR, MDF Balance.

Directionality: Salesforce‑owned. Mirror to HubSpot if you run partner‑targeted campaigns or need to segment contacts by partner programs.

Product Usage Aggregates

Key fields: Account, Active Users (30 days), Key Feature Adoption Flags, Usage Health Score, Last Active Date.

Directionality: Often sourced from a data warehouse into HubSpot for segmentation. Mirror to Salesforce only if sales needs visibility for expansion plays.

Implementing Multi‑Object Sync Safely

Multi‑object sync multiplies risk if you turn everything on at once. Use a staged approach that validates relationships and data quality.

Stage 1: Mirror Parents First

Sync Accounts and Contacts thoroughly before introducing children. Validate external IDs, ownership, and lifecycle fields. Confirm routing and dedupe policies are preventing duplicate parents.

Stage 2: Introduce One Child Object

Add one custom object (e.g., Subscriptions) and validate: record counts, association completeness (e.g., percent of subscriptions with a primary contact), and field completeness. Build a minimal dashboard to track the object’s health.

Stage 3: Add Additional Children

Expand to Implementations or Partner entities only after the first child is stable. Each addition should follow the same validation steps.

Automation Patterns in HubSpot for Custom Objects

HubSpot can trigger workflows from custom objects. A handful of patterns cover most needs:

Renewal and Expansion Motions

Trigger 90/60/30‑day renewal nurture sequences based on Subscription End Date. Branch on usage health (e.g., low adoption triggers customer education content) and route to account managers for proactive outreach.

Onboarding Journeys

From Implementation stage changes, send onboarding guides and training content to the primary contact and their team. Notify CSMs when “At Risk” toggles true with a reason code so they can act.

Partner Enablement

When partner tier upgrades, enroll partner contacts in enablement tracks and notify channel managers.

Reporting and Analysis with Custom Objects

Custom objects enable reporting beyond the classic funnel. Examples:

ARR by Product Family and Renewal Cohort.
Time‑to‑Live for implementations by segment and region.
Expansion pipeline by usage health tier.
Partner‑sourced vs. partner‑influenced revenue.

Make these reports consistent across systems by using mirrored fields and timestamps.

Data Warehouse Interop and Event Pipelines

Many teams enrich HubSpot and Salesforce from a warehouse that aggregates product, billing, and support data. To keep the loop tight without creating circular writes:

Land raw events in the warehouse, compute aggregates (e.g., 30‑day active users, feature flags), and publish a slimmed “RevOps facts” table keyed by Account/Contact external IDs.
Write those aggregates into HubSpot for segmentation and into Salesforce for CRM context, but treat the warehouse as the single writer for these fields. This avoids dueling calculations.
Keep calculation windows explicit (e.g., last 30 days) and add a “Computed At” timestamp so operators can tell when values are stale.

Migration Plan: From Fields to First Custom Object

Adopt a stepwise migration so you don’t shock downstream automations:

Catalog the fields on Contacts/Companies/Deals that actually encode another entity (e.g., “Subscription Plan,” “Renewal Date” sprinkled across objects).
Prototype a custom object (Subscriptions) in a sandbox and backfill a small cohort from the warehouse or billing system.
Mirror to HubSpot and replace automations that referenced scattered fields with object‑aware workflows.
Deprecate and archive the obsolete fields with a 60‑day grace period to catch stragglers.

Joining Strategies for Insight Without Spaghetti

Avoid n‑way joins in operational reports. Use a few opinionated, denormalized tables for dashboards (e.g., Account ← Subscription summary, Account ← Usage summary). In Salesforce, materialize summary fields on the Account for the top metrics (Live Subscriptions, ARR, Health Tier). In HubSpot, use calculated and rollup properties on Companies to avoid per‑request joins.

Case Studies: Patterns That Work

PLG SaaS Adding Sales‑Assisted Expansion

They created a Usage Aggregate object (warehouse‑owned) mirrored into both systems, with Health Tier and Key Feature Flags. CSMs used it in Salesforce to prioritize outreach; marketing used it in HubSpot to trigger expansion campaigns. Net expansion increased because timing and targeting improved, and the object remained lightweight—no bi‑directional writes.

Services Company Productizing Onboarding

They introduced an Implementation object tied to Opportunities and Accounts. Stage timestamps triggered nurture in HubSpot and milestone notifications in Salesforce. Time‑to‑Live dashboards revealed bottlenecks by region. Because the object was Salesforce‑owned, handoffs remained tight, and marketing never overwrote project data.

Performance Considerations and Limits

Large custom objects can slow list building and automation. Keep performance healthy by:

Mirroring only necessary fields; archive or hide verbose columns not used operationally.
Indexing external IDs and relationship keys where the platform allows.
Capping cardinality for relationships that can explode (many‑to‑many) by introducing summary objects or periodic snapshots instead of every raw event.

Operational Recipes

Subscription Upsell Play

Trigger: Usage Aggregate indicates high adoption of a premium feature on a core plan. Action: Enroll the account’s contacts into an educational sequence from HubSpot and create a task for the AE in Salesforce with talking points pulled from the aggregate. Success: Opportunity created within 14 days with the premium SKU attached. Measurement: Conversion rate and velocity from trigger to opportunity by segment.

Implementation Risk Response

Trigger: Implementation Health flips to “At Risk” with reason “Data Migration.” Action: HubSpot sends a troubleshooting guide to the project team while Salesforce notifies the CSM and creates a case tagged to the implementation record. Success: Health returns to “On Track” within 10 days. Measurement: Mean time to restore and churn risk for at‑risk implementations vs. control.

Partner Co‑Marketing Enablement

Trigger: Partner Tier upgrade. Action: HubSpot enrolls partner contacts in a co‑marketing track; Salesforce creates a partner portal task list for the channel manager. Success: First joint campaign launched in 30 days; influenced pipeline recorded with partner attribution. Measurement: Pipeline and win rate for partner‑sourced deals by tier.

Reporting Recipes

Renewal Health Dashboard

Blend Subscription status and Usage Aggregate Health on the Account. Show renewals due in the next 90 days with health tiers, last active date, and open risks. In Salesforce, materialize as a report; in HubSpot, create a company list and a board view for CSM workflows. This enables proactive, data‑driven renewal management without exporting spreadsheets.

Expansion Readiness Score

Compute a simple score from usage breadth (number of features adopted), seat saturation, and engagement recency. Store it on the Account and mirror it. Use the score to prioritize AE outreach and to target expansion campaigns in HubSpot. Track opportunity creation rates by score decile to validate predictive power.

Access Control and Compliance

Custom objects often store sensitive operational data. Restrict visibility by role in Salesforce and limit who can enroll object records into HubSpot workflows. Log edits to authority fields and include them in after‑action reviews when incidents occur.

Change Advisory Examples

Document a few archetypal changes with the exact review questions to ask:

Adding a new Subscription Status value: Which workflows depend on it? Does the integration have a default mapping? What are the reporting impacts?
Introducing a child association (Subscription → Seat): Do we need every seat in CRM, or would a daily seat count on the subscription suffice?
Mirroring a warehouse aggregate to Salesforce: Who consumes it? What is the refresh cadence and acceptable staleness?

Governance and Change Management for Custom Objects

Because custom objects become central to cross‑functional workflows, govern them deliberately.

Object Stewardship

Assign a steward for each object responsible for schema changes, field ownership, and documentation. Stewardship avoids “field sprawl” and protects downstream automations.

Versioned Schemas

Document the schema in a versioned catalog. Changes get a version tag, an impact analysis, and a rollback plan. This is especially important for picklist changes that can break sync.

Monitoring

Add monitors for orphan rates, sync errors by object, and field completeness (e.g., percent of subscriptions missing term dates). Alert when thresholds are exceeded for consecutive days.

Avoiding Common Traps

Even with a clear plan, teams stumble into the same traps when they scale custom object usage.

Over‑Modeling the World

If a concept does not have a lifecycle, ownership, or a reporting need, it probably does not need its own object. Every new object increases the surface area for sync failures. Prefer fields or child records when possible.

Bi‑Directional Writes for Complex Objects

Bi‑directional writes across complex objects invite conflicts that are hard to debug. Pick an owner, mirror everywhere else. If users in both systems must edit, expose a controlled subset of fields and reconcile centrally (e.g., via a workflow that merges edits into the source of truth).

Keyless Associations

Do not rely solely on names or fuzzy matches to attach children to parents. Use external IDs consistently. Names change; IDs don’t.

Implementation Checklist

Object purpose documented in one sentence; owner and consumers listed.
External ID chosen, written at creation, and enforced.
Minimal field set with single writer per field.
Parent objects synced and deduped before children.
Validation dashboards per object: counts, completeness, orphan rate, error rate.
Governance: steward named, schema versioned, monitors set.

Stewardship Cadence

Hold a monthly 30‑minute steward review per custom object. Scan field usage, picklist drift, error trends, and consumer requests. Close by approving or deferring schema changes and updating the versioned catalog. A tiny, consistent cadence prevents slow‑burn schema entropy. Capture decisions and owners so follow‑through is guaranteed.

FAQ

Can we store raw product events as a custom object?

You can, but it rarely pays off operationally. Raw events belong in the warehouse. Mirror only aggregates and milestones necessary for segmentation and human decisions. If you need raw events in CRM for a specific investigation, load a short‑lived sample rather than the firehose.

How do we backfill a custom object safely?

Run the backfill in a sandbox first with a representative slice. Validate counts, associations, and downstream automations. In production, backfill in small batches with logging and idempotent upserts keyed by external ID. Pause any workflows that should not retrigger on historical data.

What happens when two systems disagree on a field value?

Declare a single writer for the field and resolve disagreements at the source. If disagreement persists, create a shadow field to capture the alternative and investigate. Do not let the integration overwrite authoritative data without human review.

How many custom objects are too many?

There’s no hard limit, but a smell test applies: if you cannot draw the object graph on a single page that a new operator understands in five minutes, you likely over‑modeled. Consolidate or collapse relationships until the diagram becomes legible again.

When should we create a custom object vs. a property on an existing object?

Create a custom object when the concept has its own lifecycle, ownership, and reporting needs—subscriptions, implementations, or partner programs are typical examples. Use an existing object’s fields when the data is simply attributes of a contact, company, or deal. Favor simplicity unless an object’s value is clear.

Can HubSpot custom objects be mirrored to Salesforce?

Yes, but choose carefully. Mirror only if sales or customer success needs to see the data in Salesforce to do their jobs. Otherwise, keep it in HubSpot and expose outcomes through reports or notifications to avoid unnecessary sync complexity.

How do we prevent orphaned custom object records after merges?

Use external IDs and reparenting automations. When a parent is merged in Salesforce, run a job that reattaches children to the surviving parent based on the external ID. Monitor orphan rates and fix quickly to avoid data decay.

What’s the safest way to allow editing on mirrored objects?

Expose edits only on non‑authoritative fields and capture changes as suggestions or notes that a workflow can reconcile into the source system. Alternatively, route edits to the steward who owns the authoritative system.

How do we keep performance acceptable as object counts grow?

Mirror only the fields you use, archive stale records, and avoid n‑way relationships that require expensive joins to answer basic questions. Index external IDs and relationship keys so lookups are fast in your workflows and reporting.