HubSpot Build: Lifecycle, Associations, Workflows

The HubSpot portals we inherit typically carry between 300 and 600 contact properties, of which fewer than sixty are read by any workflow, report or human in a given quarter. The first week of this engagement is finding out which sixty, because everything downstream depends on it and no amount of workflow design rescues a portal where nobody knows what a field means. First pass: Property usage is pulled from HubSpot's own analytics, cross-referenced against workflow and report dependencies, and the rest archived rather than deleted. Archiving is reversible; deletion after thirty days is not. Migrated portals are the worst offenders: a field-for-field copy from a legacy CRM imports somebody else's decisions along with their history of compromises. We do not do field-for-field migrations, including when asked. Lifecycle: HubSpot advances lifecycle stage forward automatically and never moves it backward without an explicit instruction, which is why almost every portal we open has an MQL count nobody trusts. Every stage transition goes into one workflow with one named owner, and the backward-movement rules get written down: what happens when a customer's contact leaves and appears as a lead at a new company, what happens when an opportunity is lost. Turning off the backward-movement restriction without a rule for when it should apply is how the number breaks. Associations: Association labels model the relationships your business actually has: outside counsel to matter, clinic to franchise group, introducer to fund, guardian to animal to policy. We reach for labelled associations before custom objects, because a custom object buys a shape at the cost of reporting simplicity and every association-based report you already have. Custom objects when a label genuinely cannot carry it, such as a matter with its own lifecycle and its own numbers, and not before. Workflows: Re-enrollment off by default, switched on deliberately and documented when it is. No workflow enrolling on any property change, which is how a portal sends four emails in an afternoon. A naming convention carrying the owner, the object and the trigger, so whoever is debugging at 6pm knows who to ask. Every branch terminates somewhere explicit rather than trailing off. Deal stage automation only where the stage follows from data rather than from a judgement a human should be making. Operations Hub is used for what workflows genuinely cannot do: coded actions for phone normalisation, a conflict-check call at legal intake, a KYC status read from a core banking API before a deal can advance. Written to respect the API's rate limits and to fail loudly rather than silently. Off the table: We will not build sequences for a team with no written ICP; you would get consistent delivery of a message nobody agreed on. We will not install lead scoring in the first phase, because a score built before the lifecycle definitions settle encodes the confusion rather than resolving it. We do not write email copy or design templates. Not the right buyer: Teams who want Salesforce rebuilt inside HubSpot. It can be approximated, and the result is expensive, slow and disliked by everyone who touches it. If your process genuinely needs that object model, stay where you are and we will say so before you sign. Also wrong if nobody on your side can approve a picklist change without three meetings. This work is a sequence of small irreversible decisions and it stalls without a decision-maker.