RevOps Playbook: Custom Objects and Advanced Data Structures Across 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 GTM motion matures, standard CRM objects are rarely enough. Partner programs, product usage, subscriptions, and multi-entity buying groups all require data models that go beyond Contacts, Companies/Accounts, and Deals/Opportunities. This playbook explains how to plan, design, and operate custom objects across HubSpot and Salesforce so your integration remains reliable while unlocking richer automation and reporting.

We will cover when to introduce custom objects, how to model relationships, and how to keep identity consistent across systems. The result is a flexible, governed data layer that supports sophisticated funnels without turning your CRM into a fragile Rube Goldberg machine.

Who This Is For

RevOps architects, Salesforce administrators, HubSpot solutions architects, and data leaders who need to represent nuanced business entities (subscriptions, events, usage, partner deals) while preserving reporting clarity and operational ease.

Goals and Success Criteria

Model complex entities without overloading standard objects or stuffing data into notes.
Maintain stable, auditable syncs and avoid identity drift across systems.
Enable automation and attribution that leverage advanced object relationships.

When to Introduce Custom Objects

Resist the urge to create a custom object for every idea. Introduce one when:

The entity has its own lifecycle, ownership, or SLA (e.g., a partner referral or an implementation project).
You need many-to-many relationships (e.g., multiple products across multiple deals) that cannot be modeled cleanly with lookups and standard junctions.
Reporting and automation require fields and statuses that do not belong on standard objects.

Relationship Design Patterns

Custom objects shine when relationships are intentional and documented.

One-to-Many

Example: a Company has many Subscriptions. Store subscription start/end, status, and MRR. Roll up active MRR to Company and Opportunity for pipeline prioritization.

Many-to-Many (Junction)

Example: a Deal involves multiple Products with different terms. Use a junction object to link Deals and Products with quantity, price, and term fields. Sync core roll-ups back to HubSpot for campaign influence and scoring.

Event Streams

Example: a Product Usage Event object that tracks in-app milestones. Summarize recent events to Contact and Company for scoring; store raw events outside the CRM to avoid scale issues.

Identity, Keys, and External IDs

Custom objects must be addressable across systems and warehouses.

Assign a stable External ID from your source system (billing, product, or data platform) and store it on both HubSpot and Salesforce objects.
Use deterministic composite keys when needed (e.g., Account External ID + SKU for subscription line items).
Avoid using human-readable names as keys; change management becomes brittle.

Sync Direction and Ownership

Pick a system-of-record per custom object. If the object originates in a product or billing system, sync to Salesforce first and mirror summaries to HubSpot. If it originates in HubSpot (e.g., partner referrals), write to Salesforce with an external ID and restrict edits to designated fields.

Field Design and Value Governance

Prefer picklists for statuses, phases, and categories; document allowed transitions.
Keep rich content (logs, long notes) out of frequently synced fields; store links to external systems instead.
For numeric roll-ups (MRR, count of events), compute once in the source system or a data platform and mirror to both CRMs.

Implementation Steps

Introduce custom objects with discipline and transparency.

Draft a written object spec: purpose, lifecycle, relationships, key fields, external IDs, and sample records.
Review with RevOps, Sales, CS, and Finance to confirm ownership and reporting.
Implement in sandbox with realistic seed data; test queries, automation, and sync behavior.
Define user permissions and profiles; document who can create, edit, and archive.
Deploy to production with monitoring on sync errors and field changes.

Reporting and Automation Use Cases

Custom objects unlock valuable visibility when mapped to the GTM motion.

Subscription Health

Roll MRR, term, and churn risk up to Account and Opportunity. Use health to prioritize expansions and renewals.

Product-Led Growth Signals

Summarize product usage milestones to Contacts for scoring; trigger nurture or sales outreach when thresholds are met.

Partner Source and Influence

Track partner-originated opportunities and attribute influenced revenue. Sync partner object summaries back to HubSpot for multi-touch measurement and co-marketing programs.

Anti-Patterns to Avoid

Mirroring raw event streams into CRM objects; use summarized fields instead.
Creating custom objects that duplicate standard object semantics (e.g., a “Custom Deal” object).
Omitting external IDs and then relying on fuzzy matching across systems.
Allowing uncontrolled free-text fields where picklists are necessary for reporting.

FAQ

How do we decide which system is the source-of-truth for a custom object?

Choose the system that originates or governs the lifecycle. If product/billing creates the record, make that the source. Mirror summaries to the other system for reporting and automation.

Can HubSpot custom objects participate in attribution?

Yes. While attribution centers on contacts, companies, and deals, custom objects can supply context and roll-ups that improve accuracy (e.g., active subscription MRR influencing opportunity weighting).

How do we avoid performance issues when syncing custom objects?

Keep objects concise. Store heavy detail in your data platform, and sync only fields required for workflows and reporting. Batch updates and avoid flapping fields that change constantly.

What’s the safest way to roll out a new custom object?

Pilot with a single team, seed realistic data, and run a dual-reporting period where you validate numbers in parallel. Document a rollback (archive or hide) plan before launch.

How do we handle merges and deletes?

Use external IDs to track merges. When deleting in the source system, archive in the destination or mark a status to retain history. Schedule cleanup jobs to keep both CRMs in agreement.