Custom Object Automation
AI Ops

HubSpot Custom Objects for Contracts, Subscriptions, and Renewals (with AI Workflows)

Part of: Daeda AI: AI-Powered HubSpot Operations
Tikita Tolley

If you have been on HubSpot for a while, your muscle memory for contracts, subscriptions, and renewals probably involves Custom Objects. Build a Contracts Custom Object. Build a Subscriptions Custom Object. Build the workflows around them. Live with it.

That is no longer the right default for most teams. HubSpot shipped a lot of native Commerce Hub features in Spring 2026, and the decision tree is not what it used to be.

This is where HubSpot actually lands in 2026, where Custom Objects still earn their place, and how AI inside workflows changes the build.

What does HubSpot offer natively for contracts, subscriptions, and renewals in 2026?

Three native pieces now, where there used to be one and a half.

Contracts (new, Spring 2026 public beta)

HubSpot’s Contracts object went public beta in the Spring 2026 Spotlight release. It is a Commerce Hub Professional or Enterprise feature, requires a Commerce Hub seat, and is real enough that I would not model contracts in a Custom Object by default any more.

What it ships with:

  • Statuses: Scheduled, Active, Completed, Terminated, Draft
  • Properties: start date, end date, contract value, recurring revenue, status, billing info
  • Associations: contacts, companies, invoices, tickets
  • Lifecycle tooling: renewal quotes and amendment quotes can modify a contract mid-term, with impact on ARR visible in real time

The Contracts object is what you want when the commercial agreement has a fixed start and end, contract value matters, and renewal is a defined lifecycle event.

Subscriptions (already native, all plans)

HubSpot Subscriptions has been a native object for a while and is available on all plans for portals using HubSpot Payments or Stripe.

What makes it different from Contracts: Subscriptions is a billing object. It tracks recurring charges, payment status, and the customer-facing side of that. Its key properties are the ones you would expect from a billing system:

  • Next billing date, start date, end date, last payment date, churn date
  • Statuses: Active, Unpaid, Cancelled, Expired, Scheduled, Paused
  • Built-in reminders: 14 days before a recurring payment by default (2 days before for SEPA)
  • Native notifications for cancellation, pause, failed payment, billing date change

A key thing worth knowing: there is no explicit “renewal date” property on Subscriptions. The anchors are next billing date and end date. Anything dressed up as a “renewal date” in a report is a derived view over those.

Deal renewal pipeline (structural, not object)

HubSpot’s long-documented renewal pattern does not involve a dedicated object at all - it is a second Deal pipeline with renewal-specific stages (“Renewal Anticipated”, “Quote Acceptance”, “Renewal Confirmed”, “Verbal No”), or a single pipeline with a renewal-type property.

HubSpot’s own pipeline docs suggest: “Create a new pipeline if your stages are different. If your stages are the same, use the same pipeline but create a property to filter.”

This is still the right pattern when renewals are a sales motion with owners, stages, forecasting, and deal scores attached. The Deal object gives you all of that for free.

One more Spring 2026 change that matters if you sell complex products: line items can now link to Custom Objects. That means the Custom Object path stays powerful for anything HubSpot does not model natively, because the billing side can still connect back to HubSpot’s native Commerce flow.

When should I use Custom Objects instead of native Contracts or Subscriptions?

When the native model does not fit.

Specifically:

Multi-party agreements. If a single commercial relationship involves multiple parties with distinct roles (MSP + reseller + end customer, or prime contractor + subcontractor + buyer), HubSpot’s Contracts object does not model that cleanly. You need party roles that carry their own data.

Licence keys or per-user entitlements. If you sell software where each user or seat has its own state (issued, revoked, used, expiring), you are modelling thousands of children under a single contract. Native properties will not hold that shape.

Usage-based products with complex tiers. Threshold crossings, tier changes, usage meter readings - the kind of data that is generated daily and drives renewal conversations. A Custom Object per meter or per usage event makes sense.

Regulatory or compliance documents tied to the same commercial relationship. Separate lifecycle, separate owners, separate renewal cadence.

Data HubSpot does not already model. If you find yourself stuffing multiple fields into one Deal property or naming things licence_1_status, licence_2_status, you have outgrown the native shape.

For everything else - standard term contracts with renewal dates and ARR, recurring payments with billing reminders - the native objects now do the job, and they come with workflow hooks, reporting, and in the case of Contracts, renewal quote tooling you do not have to build.

Can HubSpot workflows automate Custom Object renewals?

Yes, on Enterprise.

Custom Object workflows are listed explicitly under Enterprise Only in HubSpot’s workflow object types article. Inside those workflows, the Edit record action updates Custom Object properties, creates tasks, sends notifications, and feeds data into the Use a custom LLM action.

A few things HubSpot does not quite say out loud, worth knowing before you build:

Re-enrollment does not cover associated objects

HubSpot’s re-enrollment docs state: “Properties can only be used for re-enrollment when they’re the same type as the workflow.”

In practice: a Custom Object workflow cannot re-enrol based on a Deal property changing. If you want that behaviour, you bridge with a mirror property updated by a separate workflow. Not elegant, but it is the only supported path.

Re-enrollment has several silent gotchas

All from HubSpot’s own docs, worth memorising:

  • Date and number refinements are ignored on re-enrollment.
  • Activity properties never re-enrol.
  • The “is any of” multi-value operator does not support re-enrollment in contact workflows.
  • Records must still meet the initial enrollment criteria at re-enrollment time, on top of the trigger.

Renewal workflows run into all four of these regularly. If your “60 days before renewal” workflow is not firing, it is usually one of the four above, not a HubSpot bug.

Hard limits to know

  • 250 enrollment triggers per workflow
  • 25 property change events per account
  • 30M events per month across the account

You will hit the 250-trigger limit sooner than you think on a complex Custom Object.

Why property updates and task actions silently fail in renewal workflows

This is one of the most-searched HubSpot workflow issues, and HubSpot documents the leading cause directly.

The common workflow errors article calls out: “The property couldn’t be set because the [record-type] isn’t associated with any target records.”

Example: your Custom Object workflow tries to update a property on the associated Contact. If the Custom Object record has no associated Contact, the Edit record action fires and does nothing visible. No error in the workflow history that stands out, no task created, the property just does not change.

The fix pattern: guard every cross-object Edit record action with a branch that checks whether the association exists. If it does not, route to a “create association” action first. Small change, big reduction in silent fails.

Task-action failures are less well-documented in the common-errors article, but in practice they follow the same pattern: a task action that targets an associated object will fail silently if the association is missing.

For a deeper dive into workflow reliability, why workflow triggers fail and troubleshooting conflicting workflows both cover the upstream issues that lead to these silent failures.

Using AI inside HubSpot workflows

Two places AI lives natively in HubSpot workflows today.

”Use a custom LLM” action (Enterprise only)

HubSpot’s Custom LLM action calls an external provider during a workflow. Providers: OpenAI, Anthropic (Claude), Cohere, xAI (Grok), and Google (Gemini). You write a prompt that can reference record properties, the output comes back as a string, and you feed it into downstream actions.

What it does well: the calling side. You pick the provider, you bring your own API key, you reference properties in the prompt.

What it does not do: structure the output. It hands you a raw string. If you want that string to update a Multi-select Dropdown property, you write custom logic to parse it, validate against the property’s valid options, and coerce it into the right shape. A Number property needs it to be a number. A Date needs ISO format. That glue is your problem.

For renewal automation specifically, this is where the manual work piles up. “Summarise the call transcript”, “classify the renewal risk”, “extract the competitor mentioned in the last email” - the prompt side is five minutes; the output-to-property plumbing is hours.

Breeze Data Agent actions (Professional+, HubSpot Credits)

Breeze Data Agent workflow actions are a different shape: Custom prompt, Research, Fill Smart Property, Summarise record, Infer company value proposition/ICP. These run on HubSpot Credits rather than your own API key, they integrate with HubSpot’s native AI surfaces, and they target specific outcomes rather than arbitrary prompts.

Breeze is the right choice when the action fits one of those named shapes. When it does not, you are back to Custom LLM plus custom parsing.

Where Daeda AI fits between them

The gap between “raw LLM output” and “clean value in a HubSpot property” is the piece Daeda AI’s AI Workflow Action was built to close.

Point the action at the target property and it already knows the shape the output has to be in. A Dropdown gets a valid option. A Multi-select gets a clean array. A Number gets a number. A Date gets an ISO timestamp. No branch-heavy regex, no “clean up the LLM response” custom coded action, no Operations Hub custom code fallback.

It runs on your own OpenRouter key, so you pick the model per job - fast and cheap for classification, stronger reasoning for summarisation - and swap the moment something better ships. That matters on renewal workflows where the cost per record adds up fast.

The practical effect on a renewal workflow: you describe “classify renewal risk into High / Medium / Low / Churn Risk based on the activity on this Custom Object”, point the action at the renewal_risk property, and the action runs without you building the format conversion layer underneath.

Decision framework: Contracts vs Subscriptions vs Deal pipeline vs Custom Object

Here is how I think about the tree in 2026:

SituationUse this
Recurring charges through HubSpot Payments or Stripe; you need billing reminders, churn handling, payment-status automationCommerce Hub Subscriptions - built-in notifications, native statuses
Term contracts with fixed end dates, ARR visibility matters, renewal quotes and amendment quotingContracts object (Commerce Hub Pro+, public beta as of Spring 2026)
Renewals are a sales motion with owners, stages, forecasting, and deal scoringDeal renewal pipeline - separate pipeline for distinct stages, or shared pipeline with a renewal-type property
Multi-party MSAs, licence keys, usage-based tiers, regulatory docs, or data HubSpot does not modelCustom Object (Enterprise) - full workflow support, Edit record, AI workflow actions

If you are starting fresh in 2026, you check that tree top to bottom. The Custom Object path is still there, but it is the end of the branch, not the default.

If you inherited a portal that uses a Custom Object for Contracts, migrating to the native Contracts object is worth considering - you lose the custom shape, but you gain the renewal quote tooling, the ARR dashboards, and the workflows that ship with it.

How Daeda AI makes Custom Object renewal automation faster

The Custom Object path stays slow because of the configuration overhead, not the concept. Properties, pipelines, workflows, lists, reports - every piece is clickable, every piece is individually slow to build.

Three Daeda AI capabilities collapse different parts of that:

  • Design workflows through conversation - the AI already has your portal context (properties, pipelines, existing workflows) and refines the trigger, branching, and action structure with you before anything touches HubSpot. If the solution is three connected workflows rather than one, it builds all three.
  • AI Workflow Action - property-aware AI output inside the workflow itself, with your own OpenRouter key. Stops the parse-and-coerce layer being a custom code problem.
  • Renewal tracking system - the whole system (properties, pipeline, workflows, segmentation) designed and shipped in one conversation. Previous walkthrough here.

If you are on Enterprise and the native Contracts/Subscriptions model does not fit your business, those three capabilities are the difference between a renewals project that ships this week and one that sits on a RevOps backlog for a quarter.

Plan pricing and install details on the Daeda AI product page.

FAQ

Full capability catalogue: What you can do with Daeda AI. Topic hub: Daeda AI hub.

Frequently asked questions

Yes, as of Spring 2026. Contracts is a Commerce Hub Professional or Enterprise public beta object with built-in statuses (Scheduled, Active, Completed, Terminated, Draft), contract value, start and end date, recurring revenue, and associations to contacts, companies, invoices, and tickets. Renewal and amendment quotes tie to contracts directly.