HubSpot calculated and rollup properties: what they do, and where they stop

What is a HubSpot calculated property?

A calculated property is a HubSpot property whose value comes from a formula over other properties on the same record, instead of from somebody typing it in. HubSpot stores the result as an ordinary property, so you can report on it, segment on it and drop it into a personalisation token like any other field.

The field type underneath is calculation_equation, and the equation can return a number, a boolean, a string, a date, a date-time or an enumeration value.³ Inside the editor you get thirteen operators and twenty-nine functions, including round_up, round_down, round_nearest, min, max, abs, sqrt, power, concatenate, contains, string_length, exchange_rate, and date helpers such as add_time, subtract_time and time_between.¹ Formulas can nest up to seventy open parentheses.¹

One constraint shapes everything else. A custom equation can only reference properties of the same object as the property you are creating.¹ There is no reaching from a deal across to its line items, or from a contact across to its company, inside the formula editor. That job belongs to the other half of the feature.

What is the difference between a calculated property and a rollup property?

A calculated property combines fields on one record. A rollup property aggregates a field across that record’s associated records and returns one of seven results: min, max, count, sum, average, earliest date or latest date.¹ Most write-ups of this feature list five and miss the two date aggregations, which are the ones that answer questions like when a company’s first deal was created.

A rollup does not have to take every associated record. You can point it at specific association labels, including same-object associations, so a deal property can count only the associated contacts carrying the Decision maker label.¹ You can also attach up to fifty number and enumeration conditions to a single rollup, which is how you get a sum that ignores everything under a threshold.¹

The two get confused because they sit under the same Field type dropdown and both let HubSpot do the maths. They are different tools, and picking the wrong one costs an afternoon. Calculated properties work inside the record in front of you. Rollup properties reach one hop across an association.

Which HubSpot plan do you need, and how many do you get?

Calculated and rollup properties are a Professional and Enterprise feature. HubSpot lists them on Marketing Hub, Sales Hub, Service Hub, Content Hub, Smart CRM and Revenue Hub at Professional and Enterprise, and on Data Hub at Professional only.¹ They are not available on Starter or the free tools.

The count is capped, and the cap is lower than most portals expect. Smart CRM Professional includes forty calculated properties. Smart CRM Enterprise includes two hundred.² That allowance is per account, not per object, and rollups come out of it too: HubSpot’s account limits view shows one Calculated properties line, not one for each type.⁴

You can buy more, up to a point. HubSpot sells the allowance in limit-increase packs of twenty-five, on Enterprise editions only, up to a hard ceiling of five hundred calculated properties per account.² So the practical range for any portal is forty, two hundred, or two hundred plus whatever you are willing to pay for, and never more than five hundred.

Check what you have already spent before you plan a build, not after. Settings, then Properties, then Calculated Properties gives you the count, and the Limits tab in your account usage view shows it against your allowance.⁴ A portal that has quietly used thirty-eight of forty does not fail loudly. It just stops letting anyone add the next one.

How do you build one?

Open property settings for the object, create a new property, and choose Calculation or Rollup as the field type. Everything after that depends on which of the two you picked.

For a rollup, select the associated object and the property on it you want to aggregate, then the aggregation itself. Set the number format, which can be Formatted Number, Unformatted number, Currency, Percentage or Duration. If you are rolling up currency on a deal, the property uses your account’s company currency by default, and switching it to each record’s own currency changes only how the value is displayed. HubSpot does not apply an exchange rate for you; you have to call exchange_rate or dated_exchange_rate in a formula if you need one.¹

For a custom equation, set the output type first. The type you select has to match the type your formula returns, or the property will not save at all.¹ Build the formula with the Properties and Functions dropdowns rather than typing names by hand, then use Test formula to preview the result before you commit. Enumeration values in an equation have to be the option’s internal name in double quotes, not the label a user sees.¹

You can also describe what you want in plain English and have HubSpot generate the formula for you.¹ Treat that as a first draft and read the property references it chose, because a formula pointed at the wrong field still returns a number and still looks correct sitting on the record.

Once it is live, you do not maintain it. The value updates on its own as its source data changes, which is the whole reason for moving a number off a spreadsheet and onto the record. HubSpot does not publish a recalculation interval, so if a value has to be right at a precise moment, check it on a real record rather than assuming it is instant.

Where do calculated and rollup properties stop working?

The tier gate and the count cap are the two limits people find first. The five below are the ones that cost a build a day, because each of them fails quietly: the property saves, the record shows a value, and the value is wrong or missing on a subset of records nobody checks.

One empty input empties the whole property

If any number property in a custom equation has no value, the calculation does not run and the property comes back empty. That holds even when the equation also contains a constant number.¹ HubSpot’s own fix is to wrap the input in the if and is_known functions and supply a zero.¹ This is the most common reason a calculated property looks correct on the records you spot-check and blank on the ones you do not.

Time since and Time until cannot feed another calculation

Time since and Time until properties are not supported as inputs in calculation and rollup properties. They are also unsupported in custom report builder filters and in custom data sync field mappings.¹ Time between is supported as an input, but Time between itself only works across properties of the same object.¹ If your plan was to build a stage-ageing metric by stacking one time property on top of another, that is the wall.

There is a second trap in the same area. Once a time property is created you cannot change whether it is a Time between, a Time since or a Time until, although you can still swap which date properties it points at.¹

Durations are stored in milliseconds and displayed in something else

Raw duration values are stored in milliseconds, and so are Time between and Average values.¹ Feed one into another formula without converting and the answer comes back thousands of times too large, which reads as a data problem rather than a formula problem.

What the record shows is not the stored number either. Values display in seconds, minutes, hours, days, months or years depending on size, switching to minutes at 2.5 minutes, hours at 2.5 hours, days at one day, months at three months and years at 2.5 years.¹ A date property with no timestamp calculates from midnight UTC, which is worth remembering in an Australian portal, where midnight UTC is mid-morning the same day.¹ Date-time properties are stored as UTC epoch milliseconds and shown in the viewer’s own time zone, so two people in two offices can read the same record and see different values.¹

A property built through the API can no longer be edited in the UI

HubSpot’s developer documentation is plain about this: calculation properties created via the API cannot be edited within HubSpot, only via the properties API.³ It is a one-way door, and the person it closes on is usually the admin who did not write the script. If a non-technical owner has to be able to change the field later, build it in the property editor.

One caveat here is ours rather than HubSpot’s, and we cannot point you at a document for it, so weigh it accordingly: we have seen property creates that carry a cross-object aggregation come back as a clean 201 with the aggregation silently dropped, leaving a plain, non-calculated property behind. The status code does not tell you. If you are scripting anywhere near these, read the property back after the create and check what you got.

They calculate forward, not backward

A calculated property produces values from the point you create it. It does not reconstruct what the number would have been on records that already existed. If you need a point-in-time view of last quarter, this is the wrong tool: a calculated property is a live value, not a history.

The same logic applies to the properties themselves. Every field a formula references becomes load-bearing, and renaming it, deleting it or changing its type breaks the calculation downstream, without that being visible from the property you are editing. A portal with five calculated properties is easy to hold in your head. A portal near the forty-property Professional cap, built by three people over two years, is not.

When should you use a workflow instead?

Use a calculated or rollup property when the maths is arithmetic, the inputs sit on one record or one association hop away, and the answer has to live on the record so lists, reports and personalisation tokens can read it. Deal weighted values, line item totals and counts of associated records are exactly the job it was built for.

Reach for a workflow, a custom coded action or your reporting layer instead when the logic is conditional rather than arithmetic, when it has to cross more than one association hop, when you need point-in-time history, or when somebody who does not write code has to be able to change it in six months.

There is a cheaper test than either, and it is the one most portals skip. Count how many of your forty or two hundred you have already spent. If a number is only ever read inside one report, build it in the report and keep the property allowance for values other tools have to see. If you are not sure what in your portal is load-bearing, that is what a systems audit finds before anything gets changed.

Common questions

Sources

1. Tier availability, the seven rollup types, the fifty conditions per rollup, the seventy-parenthesis nesting cap, the empty-input behaviour and the Time since and Time until restrictions are all set out in HubSpot's own article on the feature. HubSpot Knowledge Base, Create calculation and rollup properties, 2026 Article last updated 1 September 2026. Checked 13 September 2026.
2. The per-tier count of calculated properties, and the ceiling a paid limit increase can raise it to, come from HubSpot's own product catalogue. HubSpot Product and Services Catalog, 2026 Smart CRM table, Calculated properties row, and the Calculated Properties Limit Increase add-on. Checked 13 September 2026.
3. That a calculation property created through the API can no longer be edited inside HubSpot is stated in the Properties API reference. HubSpot Developer Docs, Properties API, 2026 Checked 13 September 2026.
4. Calculated properties appear as a single line in the account limits view, alongside records, associations, custom properties and pipelines. HubSpot Knowledge Base, Track your CRM data usage, 2026 Checked 13 September 2026.