Associations are what make a CRM a graph rather than a list, and they are routinely missing. A deal references a project by number but is not linked to it. A contact arrives without a company, so account views are incomplete and company-level automation never fires.
The information needed to make the connection is usually already on the record. It just lives in a property rather than in an association.
Match on a property value
When a reference number, customer identifier or domain appears on both records, that value is the association waiting to be made. Searching the target object for records whose property equals it finds the counterpart without anyone searching by hand.
Some relationships are one to one and some are one to many, which is a genuine choice rather than a detail: linking a deal to every matching project is right in some models and wrong in others.
Custom objects are first class
Teams that model their business properly end up with custom objects, and then find that most tooling quietly assumes contacts, companies, deals and tickets.
Associating to a custom object should be the same operation as any other, specified by object type rather than special cased.
Use labels to carry meaning
A plain association says two records are related. It does not say that a company is a partner rather than a customer, or which contact is the billing contact.
Applying association labels keeps that distinction in HubSpot where reporting can see it, instead of in a spare property or in somebody head.
Build it
Each of these is a working pattern with the exact steps, using the actions this article describes.
Associations made automatically at the point of creation are the ones that are actually there when somebody needs them.