HubSpot Custom Objects for B2B SaaS: When Deals and Companies Aren't Enough

What is a HubSpot custom object, and when does a B2B SaaS company actually need one?

A HubSpot custom object is a separate data table — alongside the standard Contacts, Companies, Deals, and Tickets — for tracking something specific to a business model, available only on HubSpot Enterprise. For B2B SaaS, the most common candidate is a Subscription or License object, tracking renewal date, tier, and usage separately from the Deal that created it.

Most B2B SaaS companies don't hit this ceiling because of data volume. They hit it because Deal and Company properties get asked to represent something they were never built for. A Deal closes, a custom property called renewal_date gets added to the Company record, then a second product line ships and someone adds renewal_date_product_b next to it. A third product follows the same pattern.

None of this breaks anything at first. It just accumulates.

The actual failure mode shows up once a single Company runs three concurrent subscriptions at different renewal dates, tiers, and seat counts. A Company record can hold one value per property. It cannot hold "three of these, each on its own timeline" — and every workaround from that point on (numbered property suffixes, a shared notes field, a spreadsheet next to HubSpot) is a symptom of the same underlying problem: the data has a one-to-many shape, and the object model doesn't.

This is not unique to any one company's discipline. It's what happens by default once a SaaS product line splits into two, then three, and the CRM setup was built when there was only ever one subscription to track per customer. Nobody decided to build it this way. It grew there, one property at a time, the same way most CRM data-model debt grows.

How do you decide between a custom object and a custom property?

The decision test has two questions: does this data have a one-to-many relationship to an existing record, and does it need its own pipeline or stage lifecycle independent of the Deal? Two yes answers mean the data needs a custom object. One or zero usually means a property, a picklist, or a lifecycle stage is cheaper to build and maintain.

Most teams get this backwards. A new data point shows up, it feels "custom," and someone reaches for the more powerful tool by default — without checking whether the underlying relationship actually requires it. That instinct is understandable. It's also how HubSpot instances end up with custom objects nobody remembers building.

A one-line rule survives the table: if you can point to two or more of these existing at once on the same Company, it's an object. If there's only ever one, it's a property.

Run this test against a real, mid-sized case. A 40-person SaaS company sells three product tiers, each billed and renewed separately, to the same enterprise accounts that buy more than one tier at once. Cardinality: yes, several concurrent subscriptions per Company. Lifecycle: yes, each tier renews on its own schedule, independent of when the original Deal closed. Two yes answers — this is an object, not a property, and no amount of clever property naming changes that conclusion. The same company, selling a single tier with simple annual renewals, would fail both questions and shouldn't build one at all.

What does HubSpot actually require to build a custom object?

Custom objects require an Enterprise subscription across every HubSpot Hub — Marketing, Sales, Service, Content, Data, and Smart CRM — not only Sales Hub, confirmed directly against HubSpot's own documentation. Account permissions gate who can create and manage them, and both object counts and per-object property limits vary by subscription tier rather than being fixed and public.

That Enterprise requirement is worth confirming before a project gets scoped around a custom-object build, not after. It's a real cost gate, and it applies Hub-wide — a team on Sales Hub Enterprise but Marketing Hub Professional still can't build one.

HubSpot's own documentation is specific about at least one limit that matters once a Subscription object needs to connect to Companies, Deals, and a renewal pipeline at the same time: association limits between records are configurable up to 10,000 per association type, available starting on the Professional tier across Marketing Hub, Sales Hub, Service Hub, Data Hub, Content Hub, and Revenue Hub. That ceiling rarely matters on a first build — most SaaS instances need only a handful of associations per Subscription record: a Company, an originating Deal, maybe a renewal Deal. It starts to matter later, once a support ticket, a usage event, and a renewal opportunity all need to reference the same Subscription record without HubSpot silently capping how many can attach. Confirm the number early, not once a data model is already built on an assumption instead of a documented limit.

Object and property count limits themselves aren't published as a fixed number in HubSpot's own object-settings documentation — they're tier-dependent and listed in HubSpot's product and services catalog. Treat any number you see quoted elsewhere as unverified until you check it against your own portal's actual tier.

Permissions are worth deciding before the build starts, not after. HubSpot gates custom-object creation and management behind account-level permissions, separate from the standard object permissions reps already have. In practice that means one named owner — usually whoever runs RevOps or CRM administration — decides who can create a new custom object at all, before the second or third one gets added by whoever hit a wall that week.

This is also the point where teams decide whether to build the object internally or bring in a HubSpot implementation partner. Internal builds work well when the data model is genuinely simple — one subscription type, one renewal pattern. Once Blueprint-style automation, multiple pipelines, and cross-Hub permissions all need to line up at once, the cost of getting the object model wrong on the first attempt usually exceeds the cost of getting help before building it.

How do you model a Subscription object for a SaaS company, step by step?

Modeling a Subscription object means defining its properties, connecting it to the records it depends on, giving it its own pipeline, and attaching at least one automation before it goes live. Skip the last step, and the object exists in the data model without doing any work.

1. Define the object and its core properties. Tier, monthly recurring revenue, renewal date, and seat or usage count are the four that show up in almost every SaaS build.
2. Set associations. Connect the Subscription record to its Company, the Deal that originated it, and — separately — a renewal pipeline it will move through later.
3. Build a dedicated renewal pipeline, not a reuse of the original sales pipeline. Renewals have different stages (upcoming, at risk, renewed, churned) than a first-time sale does, and mixing the two makes both reports harder to trust.
4. Set a permission and view plan for reps before launch — who sees the object, what default view they land on, which properties are editable versus read-only.
5. Attach at least one automation. A renewal-reminder workflow triggered 60 days before the renewal date is the minimum viable version; usage-threshold alerts and churn-risk scoring can follow once the base object is stable.

Steps one and two are usually quick — a few hours of configuration for a team that already knows its own subscription structure. Step three, the dedicated renewal pipeline, is where teams are tempted to cut the corner and reuse the sales pipeline instead. Resist it. HubSpot's own pipeline documentation treats custom object pipelines as configured separately from the sales pipeline, with their own stages and automation rules — the platform itself is built around the assumption that a renewal lifecycle and a new-business lifecycle are different things, not one pipeline wearing two hats. A pipeline built for closing new business and one built for tracking renewal risk need different stages, different reports, and often different owners — collapsing them into one just means both get worse at their actual job.

Where do custom object builds actually fail?

Three patterns account for most failed custom-object builds: nobody maintains the object after launch, reps never adopt it because no one planned permissions or default views, or the object sits with no automation attached. Each failure looks different but has the same root cause — the object was built as a data-modeling exercise, not as a system someone owns.

• Object sprawl. A second, then a third custom object gets added for edge cases that could have stayed properties on the first one. Six months later nobody can explain why there are four SaaS-related objects instead of one.
• No permission or view plan. The object exists, but reps never see it in their default workspace, so they keep working from Deal properties out of habit. Adoption, not the schema, is what actually failed.
• A data graveyard. Records get created and never touched again — no renewal reminder, no churn-risk workflow, nothing that reads the object's data and does something with it. An unused custom object is an expensive database table, not a system.

All three share a fix that's cheaper than it sounds: name one owner for the object before it launches, and give that person the authority to say no to a second object when a property would still do the job. Most sprawl doesn't come from bad intentions. It comes from nobody being clearly responsible for saying "not yet."

How do you roll out a new custom object without breaking existing reporting?

Sequence a custom-object rollout as build, then backfill, then automate, and retire the old properties last — never first. Retiring old Deal or Company properties before new reports are validated against them is the single most common way a rollout breaks a dashboard leadership already relies on.

1. Build the object, its properties, and its associations in a sandbox or test portal if one is available, not directly in the production instance.
2. Backfill existing subscription data from the Deal/Company properties it's replacing — a one-time migration, checked against a sample of records before running it at scale.
3. Automate the renewal workflow and any reporting that depends on the new object, and run it in parallel with the old properties for at least one full reporting cycle.
4. Retire the old properties last, only once every report and workflow that used to read them has been rebuilt against the new object and validated side by side.

Skipping straight to retirement is the most common way this rollout goes wrong. A team builds the new Subscription object, feels done, and archives the old renewal-date properties the same week — only to find a leadership dashboard still pointed at the property that no longer updates. The parallel period in step three isn't bureaucratic caution. It's the only point in the rollout where a broken report shows up before leadership notices it in a live meeting instead of a validation check.

Where does a custom object fit into the bigger HubSpot setup?

A custom object is one piece of a company's overall HubSpot implementation, not a standalone feature to enable in isolation. It matters most for companies already running a product-led motion in HubSpot, where usage data needs to feed sales and renewal decisions directly.

The same pattern shows up for multi-entity companies running one CRM across several teams or countries, where an undocumented object model turns into a governance problem fast. Teams that reach the object-versus-property ceiling are usually running several concurrent product lines, a multi-entity structure, or both — rarely a single-product, single-entity setup. Below that complexity threshold, a well-organized set of properties and a clean lifecycle stage still does the job, and a custom object would just be maintenance overhead with no matching benefit. This is also where a broader revenue-system view earns its cost — the object model is one lever inside it, not the whole system.

Under a fixed scope, fixed price model, the object-versus-property call gets made once, upfront, during a CRM-architecture review — not retrofitted six months later after the Deal-property ceiling has already been hit and half the sales team has started keeping its own spreadsheet next to HubSpot.

Book Launchpad — free, 60 minutes, no pitch, a clear fit/no-fit answer on whether your HubSpot data model actually needs a custom object yet.