GoHighLevel Data Structure Guide: Build a CRM Data Model Around Your Business

A GoHighLevel account can contain hundreds of fields, tags, forms, workflows, and integrations and still have no real data architecture behind it. Duplicate fields and unused tags are symptoms. The underlying issue is usually that nobody defined what information the business needs, what each value describes, which record it belongs to, which system owns it, and what reporting has to answer. This guide works through those decisions in the order they should be made, then covers the configuration that follows from them.

What Is a GoHighLevel Data Structure?

A GoHighLevel data structure is the organized model that determines how business information is stored and used across contacts, opportunities, companies, custom fields, tags, source data, integrations, workflows, and reporting. It is the answer to a simple question asked repeatedly: where does this piece of information live, and what depends on it?

A defined structure determines:

• What information is captured in the first place.
• Which record each value belongs to.
• Which values are allowed to change and which should be preserved.
• Which system is the authoritative source for each value.
• How information moves between GoHighLevel and other software.
• How automation and reporting consume that information.

If you are new to the platform vocabulary used throughout this guide, the GoHighLevel glossary defines contacts, opportunities, custom values, and related terms in plain language.

What Is CRM Data Architecture?

CRM data architecture is the set of rules that defines what information the CRM stores, how records relate to one another, which fields describe which entities, how information enters and changes, and how workflows, integrations, users, and reporting interact with that data.

Fields, tags, and custom values are implementations of that architecture. They are not the architecture itself. A business can create a hundred well named fields and still have no coherent model, because naming does not decide ownership, update rules, or reporting definitions. Those decisions come first, which is also why the CRM setup checklist puts requirements gathering ahead of configuration.

Start With the Business, Not the Fields

Before creating anything, work out what the business actually needs to know. That means understanding what the business sells, who interacts with it, and what each function relies on: what sales needs to qualify and progress work, what operations needs to deliver it, what customer service needs to support it, what management needs to make decisions, what reporting has to answer, what external systems require, and what information has to persist over years rather than weeks.

Technology decisions follow business understanding. A field created because someone thought a value might be useful someday tends to sit empty, get populated inconsistently, and then appear in a report where nobody can explain what it means. Every data point should have a defined purpose and a defined consumer. The Business Process Planner is a useful place to write the process down before any of it becomes configuration, and the wider Planning Center holds the rest of the planning tools referenced in this guide.

Step 1: Define the Records and Entities the Business Needs

Business information describes different real world things. Before deciding on fields, decide what things your business tracks. Depending on the business and what the platform supports, that may include a person or contact, a company or organization, an opportunity or deal, an appointment, a transaction, a project, a physical location, or an account.

Not every business needs every record type. A single location service business may operate perfectly well with contacts, opportunities, and appointments. A business selling into organizations usually needs company level information as well. A franchise or multi location operator has an extra dimension entirely, which the Multi Location Planner is designed to work through.

The governing question for every value is straightforward: what real world thing does this information describe? The answer tells you where the value belongs.

Step 2: Decide What Belongs on the Contact, Opportunity, Company, or Another Record

Most confusion in a CRM comes from storing information on the wrong record. When deal specific information is stored on the contact, the second deal overwrites the first and history disappears. When person level information is stored on the deal, it has to be re entered every time.

Contact level data

Contact data describes the person and remains true regardless of how many deals they have: name, email, phone, role or job title, communication preferences, consent status, language, time zone, and the identifiers other systems use for that person.

Opportunity level data

Opportunity data describes a specific potential piece of business: what is being sold, estimated value, expected close or start date, qualification answers for that request, the stage it currently sits in, the owner responsible for it, and the reason it was won or lost. One contact can legitimately have several opportunities over time, which is exactly why this data cannot live on the contact. The pipeline mapping guide covers how to define an opportunity and its stages, and the Pipeline Planner helps map it out.

Company level data

Company data describes the organization rather than the individual: legal name, industry, size, headquarters or service address, account status, and account level identifiers used by accounting or billing systems. Company level data matters most when several people at the same organization interact with you, or when contracts and invoices belong to the organization rather than to a person.

Step 3: Decide Which System Owns Each Important Data Point

Once other software is involved, every important value needs an owner. Source of truth means the one system whose version of a value is considered authoritative, with every other copy treated as a reflection of it. Without that decision, two systems edit the same value and the last write wins, which is not a rule anyone can report on.

Payment status is a common example. If invoicing lives in an accounting platform, the accounting platform owns payment status and GoHighLevel receives it. Appointment status is usually owned by the calendar system. Marketing consent is typically owned by whichever system records the consent event. Write these ownership decisions down before building anything, then make the integrations respect them. The Integration Planner exists for that mapping, and our CRM setup and architecture work starts from the same question.

Step 4: Design Fields and Field Types

A field should exist because a defined process, automation, integration, or report needs it. Once you know that, the field type matters more than the name. Dates stored as free text cannot be used for date based automation. Numbers stored as text cannot be summed or compared. Open text where a controlled list belongs produces twelve spellings of the same answer.

• Text for genuinely open answers such as a description of the request.
• Dropdown or single select for values that must be consistent for filtering and reporting.
• Multi select only when a record can truthfully hold several values at once.
• Number for anything that will be totalled, averaged, or compared.
• Date for anything that drives timing, aging, or renewal logic.

Use controlled values where consistency matters

Any value that will appear in a report, a filter, or a workflow condition should come from a controlled list. Industry, service type, lead source, and status are the usual candidates. Controlled lists need maintenance rules of their own: who can add an option, what happens to records holding a retired option, and how the list stays aligned with the options used in connected systems. Naming discipline belongs here too, and the naming conventions guide covers the conventions we apply across fields, tags, workflows, and folders.

Step 5: Distinguish Current State From Historical Events

Two kinds of information behave very differently, and mixing them is one of the most common structural mistakes.

Storing an event as a current state field destroys history, because the second occurrence overwrites the first. Storing a current state as a series of tags creates records carrying three contradictory statuses at once. Decide which category each value belongs to before choosing how to store it.

Decide which data can change and which should be preserved

Some values should be preserved once set. Original lead source is the clearest example: if every new form submission overwrites it, you lose the ability to report on where a customer originally came from. Other values are meant to move, such as current stage or last activity. A useful pattern is to keep both where the business needs both, for example an original source that is written once and a most recent source that updates freely.

Step 6: Use Tags Only Where Tags Are the Right Representation

Tags are best suited to simple membership and event markers: this record attended the webinar, this record requested an audit, this record is part of a specific campaign. They are quick to apply and easy to segment on, which is exactly why they proliferate.

Tags are a poor fit for structured, reportable attributes. Industry, deal value, renewal date, and service type belong in fields with defined types. Tags are also a poor fit for mutually exclusive statuses unless something reliably removes the previous tag, because nothing in a tag list enforces that only one can be true.

Compliance sensitive flags deserve particular care. A marker such as do not contact should not be treated as a casual tag that any workflow can add or remove. Whatever mechanism you use, it needs a defined owner, a defined way to set it, a defined way to reverse it, and automation that genuinely respects it. Verifying that it is respected everywhere is a standard part of a GoHighLevel account audit.

Keep the tag taxonomy small and prefixed

A workable taxonomy uses a short list of categories and a consistent prefix so tags group alphabetically. A common pattern uses prefixes for source, behavior, lifecycle, and internal flags. The rule that keeps it maintainable is not the prefix itself but the requirement that a new tag has to fit an existing category and have a stated purpose before it is created.

Step 7: Use Custom Values for Reusable Configuration

It helps to separate two very different things. Record data describes a specific contact, opportunity, or company. Configuration data describes the account or business and is reused across many messages and assets: business name, office address, support email, booking link, standard disclaimer text, or a frequently referenced URL.

Custom values are for configuration data. Storing these centrally means a change to a booking link or a disclaimer is made once instead of across dozens of templates. They should never be used as a substitute for record level fields, because they are not tied to a record and cannot be reported on.

Treat credentials with more caution than convenience suggests. API keys and similar secrets should be handled through the intended integration mechanisms rather than stored casually in places many users can view, and access to configuration should be limited to the people who need it. Permission design is covered in the Team Permissions Planner.

Step 8: Design Attribution and Source Tracking Deliberately

Attribution is a data design problem before it is a marketing problem. Decide what a source means to your business, where it is stored, whether it can change, and who is allowed to change it. Then decide how campaign and channel detail is captured, how offline sources such as referrals and phone calls are recorded, and how paid traffic parameters are carried from the landing page into the record.

Most businesses need at least an original source that is preserved and a most recent source that updates. Keeping only one produces either misleading first touch reporting or misleading current campaign reporting. Once the values exist and are populated consistently, reporting becomes a question of definitions rather than guesswork. The Reporting Planner and the metrics guide cover what to do with the results.

Step 9: Define How Data Enters and Changes

Data reaches a CRM through several routes: manual entry by staff, forms and surveys, calendar bookings, imports, integrations, and automation. Each route needs rules. Which fields are required, which are optional, what a valid value looks like, and what happens when a value is missing.

Decide what happens when new data conflicts with existing data

When an existing contact submits another form, several questions have real consequences and should be answered deliberately rather than inherited from a default setting:

• Should a blank submission value overwrite an existing populated value?
• Should a newly supplied phone number replace the existing one, or be stored alongside it?
• Should the original source remain untouched while a most recent source updates?
• Should this submission create a new opportunity or update an existing one?
• Should new qualification answers overwrite the answers on a prior opportunity?
• Which conflicts should be flagged for a human to review instead of resolved automatically?

There are no universal answers here. There is only the difference between a business that decided and a business that did not.

Step 10: Define Duplicate and Record Matching Rules

Matching rules decide when two pieces of incoming information describe the same thing. Email is the usual primary match key for people, with phone as a secondary. Companies are better matched on a domain or an external identifier than on a name, because names are entered inconsistently. Records created by integrations and imports need particular attention, since they often arrive without the identifiers a human would use.

Work through each question explicitly:

• What defines the same person, when families and colleagues share phone numbers and addresses?
• What defines the same company across variations in legal and trading names?
• What defines the same opportunity, as opposed to a legitimate second request?
• What should happen when an integration sends an existing person again?
• What should happen when a past customer returns for new work?

Duplicate prevention should not accidentally prevent legitimate repeat business. A returning customer needs a new opportunity, not a blocked record. Cleaning up existing duplicates is covered in the account cleanup guide.

Protect external system identifiers

Fields holding identifiers from other systems, such as a customer ID, account ID, invoice ID, order ID, project ID, policy ID, or an ID from a previous CRM, are frequently load bearing. An integration may use them to find the matching record on the other side. Before renaming, merging, deleting, or repurposing any of them, verify every dependency. Losing an identifier field usually means rebuilding the link between two systems by hand.

Step 11: Map Forms, Surveys, Calendars, and Workflows to the Data Model

For every input source, answer the same set of questions:

• What data does it collect, and which record receives each value?
• What happens if the record already exists?
• Which fields update, and which must never be overwritten?
• Is a new opportunity created, and under what conditions?
• Does attribution change as a result?
• Which workflow starts, and what happens if required data is missing?

Workflows need the same scrutiny, from the data side rather than the marketing side:

• What data does the workflow read to make its decisions?
• What data does it write?
• Can another workflow write the same field?
• Does an integration also update that field?
• Could competing automations leave the record in an inconsistent state?

Automation should follow the data model rather than becoming the data model. When a field only makes sense to the person who built one workflow, the model has been replaced by an implementation detail. The Workflow Planner and the workflows guide cover this from the automation side, and funnel and automation work is where we usually reconcile the two.

Step 12: Map How Data Moves Between GoHighLevel and Other Systems

Connections take several forms: native integrations, direct API calls, webhooks, automation platforms such as Zapier, middleware, and custom built integrations. The mechanism matters less than the mapping. Connected systems commonly include accounting, payments, quoting and estimating, inventory, project management, scheduling, advertising platforms, reporting tools, phone systems, and internal databases.

For each connection, document the direction and the rules:

• Which fields are sent, which are received, and which move in both directions.
• Which system is authoritative when the two disagree.
• Which identifier links the records on each side.
• How often data moves, and whether timing gaps can cause conflicts.
• What happens when a sync fails, and who finds out.
• What happens when a record is deleted or merged on one side.

Bidirectional sync deserves extra caution, because two systems writing the same value in a loop can produce data that looks correct in each system and is wrong in aggregate. Plan the mapping in the Integration Planner before building, and see the full services overview for how integration work fits alongside architecture and support.

Step 13: Define Reporting Questions Before Finalizing the Data Model

Reporting is the most reliable test of a data model, because a report can only answer a question if the underlying data was captured in a reportable form. Write the questions management actually asks, then trace each one back to the fields, records, and dates that would answer it.

Typical questions include where qualified leads come from, how long each stage takes, which services produce the most revenue, which sources produce customers rather than enquiries, how many opportunities are lost and why, and how much work is currently in progress by owner. If a question cannot be answered from the current model, the gap is a data design decision, not a reporting configuration problem. Work through this in the Reporting Planner before the structure is locked in.

Step 14: Create a Data Dictionary

A data dictionary is a maintained document describing every meaningful field, tag, and custom value in the account. For each entry, record the name, the record it belongs to, the type, the allowed values, what it means in business terms, who or what populates it, whether it can be overwritten, which system owns it, which workflows and integrations depend on it, and which reports use it.

This is the difference between a system that can be maintained by whoever is available and a system that only its original builder understands. It also shortens every future change, because the dependency question is already answered. The CRM Planner produces a structured starting point, and the SOP guide covers keeping documentation current.

Step 15: Safely Clean Up and Migrate Existing Data

Most accounts are not built from scratch. Cleanup on a live account should be sequenced rather than enthusiastic. Start by inventorying what exists, then identify what is genuinely in use by checking which fields hold data and which are referenced by forms, workflows, integrations, and reports. Only then decide what to keep, consolidate, or retire.

Retire in stages. Stop writing to a field, confirm nothing depends on it, export the data, and remove it once the account has run without it for a reasonable period. Deleting a field usually deletes the data it holds, and that is rarely reversible.

Migrating existing data into a new structure

When data moves into a new model, map old values to new ones explicitly, decide how ambiguous or missing values are handled, test the mapping on a small sample first, and reconcile record counts and key totals afterwards. Exports are a reference point, not a full backup, and an export will not restore the relationships between records or the configuration around them. Plan the sequence in the CRM Migration Planner, and see optimization and cleanup services if the account is live and the risk of breaking active automation is real.

Step 16: Test the Data Model End to End

Testing a data model means running real scenarios and inspecting the record afterwards, not checking that a form submits. Submit as a new contact and verify every field lands on the correct record with the correct type. Submit again as the same person and confirm the update rules behaved as designed. Book an appointment, move an opportunity through its stages, trigger an integration, and check what each one wrote.

• New contact through every capture point.
• Existing contact resubmitting, including with blank fields.
• Returning customer starting a second opportunity.
• Integration creating a record that also exists in GoHighLevel.
• Two workflows that could write the same field on the same record.
• A report built from the new fields, checked against the underlying records.

Step 17: Train the Team on How Data Should Be Used

A data model holds up only if the people using it understand it. Training should cover which fields matter and what they mean, which values are chosen from a list rather than typed, what is entered manually versus set by automation, when a new opportunity should be created rather than an existing one edited, and what to do when something looks wrong.

The most valuable rule to establish is that new fields and tags are requested rather than created ad hoc. That single habit prevents most of the drift that leads to a cleanup project two years later. Ongoing support and training is where this usually gets reinforced.

Step 18: Establish Data Governance

Governance is the ordinary maintenance that keeps a model accurate as the business changes. Decide who approves new fields and tags, how changes are documented, how often the structure is reviewed, and how new integrations are assessed before they are connected. Review the account periodically for fields that stopped being populated, tags nobody applies, values that no longer match reality, and reports that quietly stopped reconciling.

A quarterly review against the account audit checklist is usually enough for a small account. Larger or multi location accounts need a named owner. The Account Audit tool gives you a structured place to start, and the weekly review guide covers the lighter recurring checks.

Fields vs Tags vs Custom Values

Contact Data vs Opportunity Data vs Company Data

What If Someone Else Built the Existing Data Structure?

Inheriting an account someone else configured is normal. The usual position is a mix of fields that are working, fields nobody can explain, tags applied inconsistently, and integrations whose behavior is only visible in the data they leave behind. The answer is not to start over by default. Most accounts contain useful history and working automation worth preserving.

The sensible order is to document what exists, identify what is actually in use, establish which values are load bearing for integrations and reporting, then change things in stages with testing between them. That is the same work described in the cleanup guide, and it is what a GoHighLevel account audit is for when you would rather have someone else map the dependencies first.

GoHighLevel Data Structure Checklist

GoHighLevel Data Structure: Common Questions

What is a GoHighLevel data structure?

It is the organized model determining how business information is stored and used across contacts, opportunities, companies, fields, tags, source data, integrations, workflows, and reporting.

What is CRM data architecture?

It is the set of rules defining what the CRM stores, how records relate, how information enters and changes, and how automation, integrations, and reporting use that data. Fields and tags implement it.

What is the difference between a field, a tag, and a custom value?

A field stores a structured value on a record. A tag marks membership or an event. A custom value stores account level configuration reused across messages and assets.

What data should be stored on a contact?

Information describing the person and remaining true across multiple deals: contact details, role, preferences, consent status, and person level identifiers.

What data should be stored on an opportunity?

Information describing one specific potential piece of business: service requested, value, expected dates, stage, owner, qualification answers, and outcome.

When should data belong to a company record?

When it describes the organization rather than an individual, and when several people at that organization interact with your business.

Can one contact have multiple opportunities?

Yes, and most businesses need that. It is the main reason deal specific information should not be stored on the contact record.

When should I use a field instead of a tag?

When the value is a structured attribute you will filter, report, or run conditional logic on, or when only one value can be true at a time.

Should lead source be a field or a tag?

For most businesses a controlled field, because source is a structured attribute used in reporting. Many accounts keep both an original source that is preserved and a most recent source that updates.

What is the difference between an event and a current state?

An event happened at a point in time and stays true. A current state describes how things are now and is replaced when it changes.

What does source of truth mean in CRM data?

It is the one system whose version of a value is authoritative. Every other copy of that value is treated as a reflection of it rather than an independent record.

How should GoHighLevel data synchronize with other software?

Through a documented field level mapping that states direction, ownership, matching identifier, frequency, and failure handling for each connected system.

How do I prevent workflows from overwriting important data?

Identify which values must be preserved, restrict which automations and forms can write them, and test resubmission scenarios including submissions with blank fields.

How should duplicate contacts be handled?

With defined matching rules based on reliable identifiers, plus a merge process that specifies which record survives and what happens to history, opportunities, and integration identifiers.

How should duplicate opportunities be handled?

By defining when a new opportunity is legitimate. A returning customer with new work needs a new opportunity; a second form submission about the same job usually does not.

How do I safely merge or remove old fields?

Check every dependency first, export the data, stop writing to the field, confirm nothing breaks over a reasonable period, and only then remove it.

What is a CRM data dictionary?

A maintained document describing each field, tag, and custom value: meaning, type, allowed values, owner, update rules, and the workflows, integrations, and reports that depend on it.

Can GoHighLevel360 clean up a data structure someone else built?

Yes. That is a common starting point. The work begins by documenting the existing structure and its dependencies through an account audit before anything is changed.

Is GoHighLevel360 affiliated with HighLevel?

No. GoHighLevel360 is an independent company providing professional services for businesses using the HighLevel platform. GoHighLevel360 is not affiliated with or endorsed by HighLevel, Inc. HighLevel provides the software; GoHighLevel360 provides the planning, architecture, configuration, integration, audit, repair, optimization, documentation, training, support, and continued development around it. The GoHighLevel vs GoHighLevel360 comparison explains the distinction in detail.