A HubSpot CRM data model that records what matters

We ask what the information describes and how long it remains true. A contact record describes a person, a company record describes an organisation and a deal describes a particular opportunity. The same customer can have several opportunities with different requirements. Putting every commercial detail on the contact risks allowing the newest enquiry to replace the context of earlier work.

A useful test is to imagine the value changing. If a person changes their telephone number, updating their contact record makes sense. If they discuss a different budget for a new project, the earlier project's budget should normally remain intact. That difference helps determine whether the field represents a current personal detail or information specific to an opportunity.

Relationships require equal care. A contact might act for more than one organisation, and several people may participate in the same buying decision. We establish which organisation and participants belong to the opportunity rather than relying on whichever record happens to be primary. Where supported, association labels can make roles easier for users and automation to interpret.

GRO tests the proposed placement against your forms, follow up and reports. Sometimes a summary field on one record is useful, but it should have an explicit source and update rule. The objective is to avoid competing versions of the same fact while preserving the history your team needs. The property dictionary records those choices so new administrators understand why the information lives there.

Custom objects may be appropriate when your business manages a distinct type of entity that needs its own records, relationships and ongoing history. A hypothetical property services company might need to track buildings independently of individual sales opportunities. The decision depends on how that information is used, not simply on whether the business has a special name for it.

We first test whether the available standard objects and properties can represent the requirement clearly. Creating another object introduces administration, relationship rules and reporting decisions. It can also affect subscriptions and integrations. A simpler structure may be sufficient when the information only describes one deal and has no independent lifecycle outside that opportunity.

If an additional object is justified, we define its identity and relationships before configuration. Users need to know when to create a record, how to recognise an existing one and which team maintains it. We check whether forms, integrations, workflows and reports can use the proposed structure in the ways required. Platform availability and account entitlements are verified during scoping.

GRO explains the trade off in business terms: what becomes easier, what new maintenance is introduced and which features depend on licensing. We do not recommend complexity to make an implementation appear more sophisticated. The strongest model is the least complicated structure that preserves the information and relationships your business needs, with enough flexibility for requirements you can describe rather than hypothetical possibilities.

The right format depends on what you want to do with the answer. A controlled set of options is useful when a value drives routing, segmentation or comparison. Free text is useful when people need to capture context that cannot be predicted sensibly. Many processes need both a structured category and a note explaining the particular situation.

For a hypothetical maintenance provider, an enquiry category could direct work to the correct team, while a description captures the reported problem. Asking users to type the category freely would create spelling variations and overlapping terms. Trying to represent every possible fault in a dropdown would create an unwieldy list and encourage users to choose an approximate answer.

We also consider what happens when the answer is unknown or does not fit existing options. Blank, not applicable and a confirmed negative are different states. Treating them as equivalent can distort reports or trigger inappropriate follow up. The model defines those meanings and provides a route for reviewing recurring exceptions rather than quietly expanding the option list without agreement.

HubSpot property types have specific behaviours and limitations, which we check before configuration or conversion. Changing a heavily used field's format can affect existing values and connected tools. GRO selects formats around the intended action, tests representative data and documents the choice. Users should understand how to answer the question, while managers should understand what comparisons the resulting values can support.

Old fields should be reviewed before they are removed. A property can appear unused on the main record layout while still supplying a workflow, form, report or external connection. Deleting or replacing it without understanding those dependencies can interrupt a working process or remove information that a colleague relies on during an occasional but important task.

We inventory the properties and examine where they are used. Similar names do not prove that two fields mean the same thing. A quoted value and an agreed contract value may differ intentionally, while two differently named fields may both represent the same customer preference. The review establishes meaning and ownership before deciding what should be consolidated.

When replacement is appropriate, the transition covers existing values as well as future updates. We map old options into the agreed definition, identify values that need human review and update the relevant dependencies in the scoped work. A field can be removed from everyday views before final retirement where that reduces confusion while preserving information needed during the transition.

Your nominated owner receives a record of the decisions and any unresolved dependencies. Some connections may be managed by an external supplier, so their involvement must be planned rather than assumed. GRO's approach is to reduce unnecessary complexity with evidence. The aim is fewer, better understood properties and a clear explanation of what happened to the information previously stored in retired fields.

The model needs an owner and a simple process for requesting changes. Without that, each new campaign or operational problem can produce another property with a slightly different definition. A useful request explains the question the field answers, who will maintain it and which existing property or relationship has already been considered as an alternative.

The property dictionary becomes the reference for those decisions. It should describe meanings in business language, with examples where interpretation could vary. Naming conventions and field descriptions help, but they cannot replace agreement about what the value represents. Your administrator should be able to explain why a field exists and what would stop working if it disappeared.

Regular checks can focus on the parts of the model used for important actions. If routing depends on service category, review unexpected values and missing categories there. If reporting depends on deal relationships, inspect unattached opportunities and ambiguous company links. Targeted checks are more useful than demanding that every record be completely filled regardless of its stage or purpose.

GRO can include ongoing governance support within an agreed scope, or hand the process to your internal administrator. Either way, future integrations and imports should be reviewed against the model before they create fields automatically. A maintained design gives your business room to change while preserving common definitions, so the information remains useful to sales, marketing and reporting as new requirements arrive.

Make customer information answer a useful question

A crowded customer record can still leave your team without the information they need. Fields named budget, project budget and estimated spend may describe different things, or the same thing entered by different teams. Meanwhile, a person handling a new enquiry cannot tell whether the value relates to the company, the latest project or a conversation from last year.

GRO designs the structure before adding more fields. We establish what each piece of information means, which record owns it and when it should be collected. A person's preferred contact method belongs with that person; the budget for a particular project belongs with that opportunity. Clear ownership prevents a later enquiry from overwriting context that an earlier deal still needs.

The benefit reaches beyond tidier records. Segmentation, routing and reporting rely on consistent definitions. If the sales team records service interest as free text but marketing expects a fixed category, both teams inherit manual work. We connect those requirements and choose a structure that is understandable to the people entering information as well as those using it.

Define fields, relationships and the rules behind them

The service includes a property inventory, a proposed record model and a dictionary explaining the agreed fields. We review existing properties before creating new ones, identify duplicates in meaning and select appropriate formats for dates, numbers, options and notes. Each field has a defined purpose, source and responsibility for maintaining it.

Relationship design explains how contacts, companies and deals connect. Where your account supports appropriate association labels, these can distinguish roles such as a decision maker and a billing contact. More complex business entities may justify additional objects, but we check current platform availability, licensing and reporting implications before proposing a structure the team must maintain.

Configuration can include property groups, descriptions, option values and relevant record layouts. We document which old fields are retained, replaced or considered for retirement, with a dependency review before changes. Migration of existing values and integration mapping are scoped according to their complexity. The output is an operational model with enough guidance to keep future additions consistent.

Work backwards from actions and reports

We start with the questions the business needs to answer. Who should receive this enquiry? What requirement was discussed? Which organisation is buying? What information must appear in a proposal? Those questions reveal the fields and relationships that deserve priority. Requests for information that nobody uses are challenged before they create another task for the sales team.

Next we examine representative records and connected systems. A property may be populated by a form, a user, an import or an integration, and those sources can disagree. We define who owns each fact and how updates should behave. We also distinguish unknown information from a confirmed negative answer so incomplete records do not accidentally trigger the wrong decision.

The proposed model is tested against new enquiries, repeat customers and opportunities with multiple participants. We check whether the structure supports the intended views and reports before moving larger amounts of data. Handover covers both the configuration and the decision rules, giving your administrator a practical basis for evaluating future field requests without rebuilding the model from memory.

A hypothetical supplier keeps project requirements separate

Consider a hypothetical commercial lighting supplier whose customers order for several properties. Its contact record has one field for installation address and one for project budget. When the same facilities manager enquires about another building, the latest details replace the previous ones. Sales can still see the contact, but the history no longer explains which specification belonged to which project.

A revised model could keep the facilities manager's contact details on the person, the purchasing organisation on the company and each requirement on its own deal. The project address, expected scope and budget discussion would then stay with that opportunity. Other participants, such as a contractor or procurement contact, could be associated with the appropriate project.

If maintaining buildings as separate persistent records would provide additional value, that would be assessed against the available objects and ongoing administration. It would not be assumed necessary merely because buildings exist in the business. This hypothetical example shows how a structural decision can preserve context and improve handovers without making a claim about a real client's results.

Check whether the model produces dependable information

We assess completeness by purpose. An early enquiry may legitimately lack a budget, while an opportunity ready for a proposal may need a defined scope. Measuring every record against every field creates a misleading picture of quality. GRO defines where information becomes necessary and then checks whether the records at that point contain usable values.

Consistency checks look for unexpected options, contradictory fields and relationships that do not match the model. We also inspect whether users can find the relevant information and whether reports count the intended business entity. A company with several contacts should not become several customers simply because a report follows the wrong relationship.

The model's effectiveness becomes visible in reduced correction work and fewer questions about what a field means. We track unresolved exceptions and identify their cause, such as an old import or an integration using a different definition. Clean structure cannot guarantee accurate input, but it makes errors easier to detect and establishes responsibility for preventing them from recurring.

Design for the complexity your business actually has

This service suits accounts with duplicated property names, unreliable segmentation, confusing company relationships or recurring problems when connecting another system. It is also useful before a major migration. Agreeing the model first helps avoid transferring an old system's ambiguity into a new platform and then having to repair it while the team is already working.

We need examples of the information your users collect, the decisions it supports and the systems that create or update it. Access to an account administrator and representative users helps resolve conflicting definitions. Where personal or sensitive information is involved, we work within your agreed data handling requirements and avoid collecting details simply because a field can be created.

The proposal reflects the number of records types, properties, relationships and dependencies involved. Advanced controls or additional object capabilities are checked against your subscription. GRO hands over a client owned structure and a readable dictionary, so the work remains useful beyond the initial configuration and future changes can be assessed against an agreed design.