HubSpot Custom Objects Case Study: Serial-Level Equipment Records for a Manufacturer Selling Through Dealers

Summary

Cartwright Equipment manufactures farm machinery. It markets directly to farmers and sells through a dealer network, which means the buyer on every invoice is a dealer and the operator of the machine is a person the manufacturer has never recorded.

That is not a marketing inconvenience. It is a structural information failure with three downstream consequences: attribution cannot be traced past the dealer, service cannot be offered to an owner whose name is unknown, and lifecycle marketing has no audience beyond the channel.

The build described here closes the gap with four things: NetSuite retained as the system of record, HubSpot added as the system of engagement, two custom objects that separate an equipment model from a physical serialised unit, and a warranty registration form keyed on the serial number that either the dealer or the end user can complete.

One platform constraint shaped the entire data model. HubSpot products cannot be associated to custom objects. The link between the native Product record and the custom Equipment record is therefore a stored identifier rather than a native association, which means referential integrity is the implementation's responsibility and not the platform's.

Client details are pseudonymised at the client's request. Figures are as measured.

Background: the customer the manufacturer cannot name

The commercial shape is common across manufacturing and rarely modelled. Cartwright's demand generation targets operators. Its transactions occur with dealers. Those two facts describe different populations, and the manufacturer's systems recorded only the second.

Palanichamy and Amarnathan (2025) examine barriers to transparency in manufacturer–distributor relationships and find the withholding to be structural rather than incidental: the distributor's commercial position depends in part on the manufacturer not holding the end-customer relationship directly. A manufacturer that waits for its channel to volunteer the data will wait.

NetSuite held everything a transaction needs. Orders, invoicing, inventory, serial number management and financial records were complete and correct, and none of that was in question. What NetSuite had no reason to hold was the person operating the machine, because that person is not party to any transaction NetSuite records.

The decision taken at the outset was therefore not to replace anything. NetSuite stays as the source of truth for orders, inventory, serial numbers and finance. HubSpot becomes the engagement layer for marketing, pipeline, service and the end-user relationship. The two connect through the native marketplace connector rather than custom middleware, because a connector that a vendor maintains is a connector the client is not paying to keep working.

Pre-engagement audit

Products in NetSuite available to sync: approximately 9,461. The full catalogue, most of which is parts and consumables.

Serialised products within that catalogue: 126. Machines rather than parts, identified by a serialized flag on the product record. A second flag, shortlist, marked 118 products, and which of the two should define the population remained an open decision at handoff.

End users known to the manufacturer by name: zero. No object existed to hold one.

Objects linking a physical machine to its owner: zero. A serial number existed in NetSuite against an order to a dealer. Nothing connected it forward to whoever eventually bought the machine off that dealer's lot.

Service capability: reactive and unidentified. An inbound call about a machine could not be resolved against a record of that machine.

Reinartz, Krafft and Hoyer (2004) measure customer relationship management across initiation, maintenance and termination, and find maintenance the stage where implementation is weakest. A manufacturer that cannot identify the customer cannot implement maintenance at all, which makes this the limiting case of their finding rather than an exception to it.

The build

Phase one: the object model

Four tiers, and the separation between the middle two is the whole design.

Product is native and synced from NetSuite, approximately 9,461 records, matched on the NetSuite internal identifier. It carries the master catalogue and pricing.

Equipment is a custom object holding the model. It is the serialised subset of products, roughly one to one with them, and it carries the attributes a quote form needs to filter on: equipment type, bale groups and attachment groups.

Inventory is a custom object holding the physical unit. One record per machine that exists in the world, carrying the serial number and the warranty state.

Company and Contact are native. The dealer bought the unit; the end customer registered it.

The cardinalities matter. Equipment to Inventory is one to many, because one model becomes many machines. Inventory to Company and Contact is many to many at the schema level, and constrained by rule to one owner per serialised unit. Attaching several contacts to one Inventory record was a test-data error, and it was corrected rather than tolerated, because a serial number with two owners is a serial number that answers no question.

Phase two: the constraint that shaped the model

HubSpot products cannot be associated to custom objects.

The Product record and the Equipment record therefore cannot be joined the way every other pair in this model is joined. The link is a stored property, matched_product_id, alongside equipment_netsuite_id, and the difference is not cosmetic. A native association is enforced by the platform: delete one side and the association goes with it. A stored identifier is a string that happens to match something, and nothing in the platform notices when it stops matching.

The consequence was designed for rather than discovered later. Equipment records are maintained by a serverless upsert against the product set rather than by hand, so the identifier is re-derived from the source instead of being trusted to stay correct.

Redman (1998) treats poor data quality as a cost borne continuously and recognised rarely, and an unenforced link is precisely that kind of liability. It is correct on the day it is written and degrades silently afterwards, and the degradation surfaces as a quote form that will not filter or a card that renders a machine with no model. Re-deriving the identifier on a schedule does not make the link referentially sound. It bounds how long an incorrect one can persist, which is the most a stored identifier allows.

Two further constraints cost time and are documented nowhere obvious. Ticket pipeline creation was blocked by the scopes available to the application token, so the service pipeline was built through the interface rather than the interface being scripted. Contact links rendered inside a custom card must carry the fully qualified record path including the portal identifier, or HubSpot returns the viewer to a sign-in page rather than the record.

Phase three: the warranty registration join

Warranty registration is the mechanism that closes the attribution gap, and the serial number is the join key.

The flow is deliberately short. A quick-response code on the machine or at the dealer's desk opens a gated form. The form captures the registrant's details and the serial number. The backend creates or matches the contact, matches or creates the Inventory record by serial, associates the contact as owner and the dealer as the selling company, and sets the warranty state.

Warranty state is a three-value enum rather than a boolean: submitted, needs NetSuite update, completed. The middle value exists because registration in HubSpot and the warranty record in NetSuite are different facts, and collapsing them would make the system claim a NetSuite update that had not happened.

The design decision that matters most is that either party can register. A workflow depending solely on dealer participation has a single point of failure in a party with no obligation to participate, and Palanichamy and Amarnathan's finding predicts exactly that failure. The code on the machine is the fallback and, on the evidence of how such programmes usually run, likely the primary path.

Phase four: surfacing it where the work happens

A serial-level record is useless if reading it requires a report.

A HubSpot user interface extension was built and installed as a tab on the company record, rendering a table grouped by model with serial, owner and status for every unit associated to that dealer. It reads live from a serverless endpoint rather than from a cached property, so the card cannot show a state the CRM has moved past.

Zaefarian and Najafi-Tavani (2016) associate supplier sales growth with the supplier's perception of fairness in the relationship, and a dealer-facing record is where that perception is either earned or lost. A manufacturer that holds serial-level ownership data and does not surface it to the dealer who sold the machine has taken information out of the channel without putting any back. The card is the mechanism that makes the exchange two-directional, and it was built in the first phase rather than deferred for that reason.

Wang and Strong (1996) define data quality as fitness for the consumer's use, and the card is that principle applied: a dealer manager opening a company record has a different question than a marketer building a list, and the same underlying records have to answer both without either person constructing a query.

Outcomes

Objects representing a physical machine: from 0 to 1. The Inventory object did not previously exist in any system as a customer-facing record.

Objects separating a model from a unit: from 0 to 2. Equipment and Inventory, with a one-to-many relationship between them.

Serialised products identified within the catalogue: 126 of approximately 9,461, or roughly 1.3%. Establishing that boundary is what made a manageable Equipment population possible.

Association types wired: 5. Inventory to Company, Inventory to Contact, Inventory to Equipment, and two labelled contact-to-company relationships distinguishing a customer from an employee, alongside a pre-existing dealer label.

Warranty states modelled: from 0 to 3. Submitted, needs NetSuite update, completed.

Registration paths: 2. Dealer-completed and end-user-completed, by design rather than by accident.

Equipment records populated at handoff: 22 of 126. Reported as it stands. The schema, the associations, the card and the endpoint are live; the population is not complete, and the first item on the remaining task list is completing it.

Remaining task list at handoff: 33 items, sequenced with a stated critical path.

Lessons learned

A platform constraint is a design input, not an obstacle to route around quietly. The inability to associate products to custom objects could have been handled by pretending the stored identifier was an association and moving on. It was instead handled by naming what the platform no longer guarantees and adding the mechanism that replaces the guarantee. Every integration has one of these. The difference between implementations is whether it is written down.

The model has to separate the thing from the kind of thing. A single custom object holding both the machine model and the physical unit is the shortcut, and it breaks the moment two farmers own the same model, which is immediately. Equipment and Inventory look like duplication until the one-to-many relationship is populated.

The work was nearly lost, and the reason is instructive. The initial build ran in a session scratchpad directory that the operating system subsequently cleared. The project was recovered by downloading the deployed build and reconstructing around it, and it now lives in the client workspace under version control. The cost was real and the lesson is unglamorous: a deployed artefact is a backup only if it can be downloaded, and the working copy belongs somewhere durable from the first commit.

Scoping deferred two things that are genuinely worth building later. A data warehouse was recommended against for now, on the argument that the connector is trivial to enable once there is clean data to load and that building it first means modelling incomplete data. A web store was declined on transaction volume and on the client's own judgement that telephone parts sales are an upselling channel rather than a bottleneck. Holland and Light (1999) identify phasing and scope discipline among the critical success factors in enterprise system implementation, and both deferrals are that finding applied.

Limits

No business outcome is reported and none is claimed. The attribution gap is closed structurally: an object now exists that can hold an end user, and a mechanism exists that can populate it. Whether registrations actually arrive is a question for the registration rate, and at the point described the form was not yet live.

The Equipment population is incomplete. Twenty-two records of a target of 126. Nothing in this document should be read as describing a finished data set.

One scoping decision is unresolved. Whether Equipment should be filtered on the serialised flag, giving 126 records, or on the shortlist flag, giving 118, was an open question for the client at handoff. The two populations are not the same and the difference will matter to the quote form that depends on them.

The product-to-equipment link is not enforced by the platform. The upsert re-derives it, which is a mitigation rather than a guarantee. A product deleted in NetSuite leaves an Equipment record pointing at nothing until the next run.

This is one manufacturer's channel. A firm with a small number of large, contractually close distributors has a different version of this problem than one selling through a fragmented dealer base, and the willingness of the channel to participate in registration will differ accordingly.

Conclusion

The question this build answers is narrow and was previously unanswerable: which machine is where, and who owns it.

Before, the manufacturer knew which dealer had bought a serial number and nothing after that. The chain ended at the invoice. Everything downstream, including every marketing decision about operators and every service interaction with an owner, ran on inference.

Makkonen and Vuori (2016) treat buyer attractiveness as a catalyst for relationship development, and the observation transfers to a channel: a manufacturer that can tell a dealer which units are on that dealer's lot, who owns them and what their warranty state is has become more useful to the dealer than one that cannot. The registration workflow is usually framed as the manufacturer extracting data from the channel. It reads better, and is likelier to be adopted, as the manufacturer giving the channel a record it also lacks.

References

Holland, C. P., & Light, B. (1999). A critical success factors model for ERP implementation. IEEE Software, 16(3), 30–36. https://doi.org/10.1109/52.765784

Makkonen, H., & Vuori, M. (2016). Buyer attractiveness as a catalyst for buyer–supplier relationship development. Industrial Marketing Management, 55, 156–168. https://doi.org/10.1016/j.indmarman.2015.09.004

Palanichamy, N., & Amarnathan, M. (2025). Barriers to transparency and information sharing in manufacturer–distributor relationships. International Journal of Retail & Distribution Management. https://doi.org/10.1108/ijrdm-08-2024-0436

Redman, T. C. (1998). The impact of poor data quality on the typical enterprise. Communications of the ACM, 41(2), 79–82. https://doi.org/10.1145/269012.269025

Reinartz, W., Krafft, M., & Hoyer, W. D. (2004). The customer relationship management process: Its measurement and impact on performance. Journal of Marketing Research, 41(3), 293–305. https://doi.org/10.1509/jmkr.41.3.293.35991

Wang, R. Y., & Strong, D. M. (1996). Beyond accuracy: What data quality means to data consumers. Journal of Management Information Systems, 12(4), 5–33. https://doi.org/10.1080/07421222.1996.11518099

Zaefarian, G., & Najafi-Tavani, Z. (2016). Do supplier perceptions of buyer fairness lead to supplier sales growth? Industrial Marketing Management, 53, 160–171. https://doi.org/10.1016/j.indmarman.2015.07.003

Conflict of Interest Statement

RevOps HQ is a HubSpot Solutions Partner and was paid to perform the work described here on a time-and-materials basis at a stated hourly rate. The object counts, identifiers and record populations come from the portal and from the engagement handoff document. No business outcome is claimed, and the incomplete parts of the build are reported as incomplete.

Acknowledgments

The client's technical lead defined the quote-form attributes carried on the Equipment object and added the quotable flag on the product record. The NetSuite connector is a HubSpot marketplace application; no custom middleware was written for the synchronisation.