GoHighLevel custom objects let you model business entities that do not fit neatly into standard contacts, companies, or opportunities. Examples might include properties, subscriptions, policies, memberships, or service assets. The value is not simply storing more fields. It is giving an important business entity its own records, relationships, ownership, and workflow behavior.
In a GoHighLevel workflow, the Create or Update Custom Object Record action can locate an existing record, create one when no match exists, update fields, and maintain relationships with other records. The reliable approach is to decide what constitutes the same record before configuring the workflow. Otherwise, a workflow can create duplicates or update the wrong entity.
This guide explains the action in operational terms: how to identify the record, when to search, how to handle a missing match, and how to map values safely. The exact fields available depend on the custom object definition and account configuration.
What GoHighLevel custom objects are used for
A custom object represents a type of business entity that deserves its own record structure. A contact represents a person. A company represents an organization. An opportunity represents a sales or revenue process. A custom object can represent something else that the business needs to track independently.
For example, a property management business might need a Property object, while a subscription business might need a Subscription object. Each object can have its own fields and can be related to contacts, companies, or other records. This is different from adding many unrelated fields to a contact because the custom object can have its own lifecycle, ownership, and automation logic.
A custom object should represent a meaningful business entity, not merely a convenient place to store extra fields.
Before building a workflow, define the business meaning of the object. Ask what the record represents, who owns it, which fields identify it, which records it relates to, and what should happen when its information changes. Those decisions determine whether the workflow will produce dependable data or repeated, ambiguous records.
How the Create or Update Custom Object Record action works
The workflow action can be understood as three decisions:
- Identify the record: choose the custom object and determine which record the workflow should act on.
- Find the record: decide whether GoHighLevel should search for an existing record and what should happen if there is no match.
- Update or create the record: define the values, relationships, and ownership to apply.
These decisions should be treated as a sequence rather than as unrelated configuration fields. The first decision establishes the object context. The second controls record identity. The third writes data after the workflow has determined which record is relevant.
The most important part of a create-or-update workflow is not the field mapping. It is the rule that determines whether an incoming event belongs to an existing record.
Step 1: Identify the custom object and record
In the Identify the Record section, select the custom object definition that the workflow will use. The available object types and fields depend on the custom objects configured in the account.
The Record setting determines how the action receives its target. Common options include:
- Selected from Custom Objects: use a specific existing record selected during configuration. This is suitable for a fixed record, but it is not dynamic.
- Received from trigger: use the custom object record passed into the workflow by a compatible trigger or event.
- Found from contacts in the workflow: find a custom object record through the contact or contacts currently associated with the workflow.
Use the trigger-based option when the workflow already knows which custom object caused the event. Use the contact-based option when the workflow begins with a contact and the relationship to the custom object is the reliable path to the record.
Choosing the contact relationship
When the action finds a record from contacts in the workflow, the Find Contacts setting controls which workflow contacts are used in the search. This makes the relationship between the contact and custom object important. If several contacts could be related to the same object, define which contact is authoritative before relying on this option.
A useful diagnostic question is: Could two records satisfy this relationship at the same time? If the answer is yes, the workflow needs a more precise identification rule or a clearly defined ownership relationship.
Step 2: Decide whether to search for an existing record
The Find the Record section controls whether the workflow searches for an existing custom object record before writing data. Select Yes when the incoming data may relate to a record that already exists. Select No only when the workflow should create a new record every time it runs or when the record has already been identified by the workflow context.
When the workflow searches
With the search option enabled, the action can use Find Based On criteria to identify a matching record. The matching value should represent a stable business identifier where possible. A name alone may be ambiguous. A reference number, external identifier, or carefully defined combination of fields may be more reliable, depending on the process.
The action also provides a No Record Found decision. You can either:
- Stop: end this action when no matching record exists.
- Create a record: create a new custom object record when the search returns no match.
Choose Stop when creating a new record would be risky or require human review. Choose Create a record when the workflow is responsible for establishing the entity and the matching rule is sufficiently precise.
Automatic creation is safe only when the workflow has a clear answer to the question, “What makes this a new record rather than an update to an existing one?”
When the workflow does not search
If you select No, the action skips the lookup and proceeds to create or populate a record using the remaining configuration. This can be appropriate for a deliberately new record, but it can also create duplicates if the workflow runs more than once for the same business event.
Do not use the no-search option simply because the lookup is difficult to configure. If duplicate records would damage reporting, ownership, or downstream automation, resolve the identity rule first.
Step 3: Map values to the custom object record
The Update or Create the Record section defines what data is written after the action has established its target.
Use manual values when the workflow transforms data
With Manually Enter, you map values into the custom object fields. Values may come from workflow data, contact information, trigger data, or fixed inputs available in the action.
Manual mapping is useful when the workflow needs to transform the incoming data or set a business state. For example, an intake workflow might create a Subscription record, map the subscription reference and start date, associate the record with a contact, and assign ownership to the responsible user.
Map only the fields that the workflow owns. If several workflows can update the same field, define which one has authority. Otherwise, the final value may depend on timing rather than on an intentional business rule.
Use the current record when passing existing data through
The From Current Record option uses values from the custom object record currently being processed. This can reduce repeated field mapping when the workflow is acting on an existing record and should preserve or pass through its current values.
It is not a substitute for understanding which record is current. Confirm that the workflow context is the object you intend to update, especially when contacts, companies, and custom objects are all present in the same process.
Relationships and ownership are part of the data model
Custom object fields describe the record, but relationships explain how the record fits into the business. Use Add Relationship to associate the custom object with relevant contacts, companies, or other supported entities.
Relationships should answer a business question. For example, a subscription may belong to a customer, a property may be managed by an owner, or a policy may be associated with a policyholder. Avoid adding relationships simply because the option is available. An unnecessary relationship can make searches and reporting harder to interpret.
Object Ownership determines who is responsible for the record and may affect visibility or assignment behavior. Ownership should be connected to an actual operating responsibility. If ownership is not clear, the workflow may successfully create data without creating accountability.
What the record means
Define the entity, its fields, its identifier, and its relationships before configuring automation.
What should happen next
Define when to find, create, update, stop, assign, or request review of the record.
A practical sequence for reliable custom object workflows
Define the business entity
Write one sentence describing what the custom object represents and what it does not represent.
Choose the record identifier
Select the field or condition that distinguishes one real-world entity from another.
Choose the missing-record behavior
Stop for review when creation is uncertain, or create automatically when the rule is dependable.
Map owned fields and relationships
Write only the values this workflow is responsible for and maintain the relevant relationships.
Test repeat behavior
Run the workflow more than once with the same input and confirm that it updates rather than duplicates.
Example: creating or updating a subscription record
Consider a hypothetical subscription process. A contact submits information containing a subscription reference. The workflow identifies the Subscription custom object, searches for a record using that reference, and creates a record only if no match exists. It then maps the plan, start date, and status, relates the subscription to the contact, and assigns ownership to the responsible team member.
If the same submission is received again, the search should return the existing subscription and update the relevant fields. If the reference is missing, the safer outcome may be to stop the action or route the record for review rather than create an unidentified subscription.
This example illustrates a broader rule: a workflow should be designed around the repeat behavior of the process, not just the successful first run.
- The custom object represents a distinct business entity.
- The workflow has a defined record identification rule.
- The no-match behavior is intentional.
- Relationships connect the record to the right contact or company.
- Ownership reflects real responsibility.
- Repeated inputs do not create unintended duplicates.
- Reports can distinguish active, inactive, missing, and review-needed records where relevant.
Operational observations to keep in mind
A custom object field stores information, but a relationship explains business context.
A create-or-update action is only as reliable as its record identity rule.
Ownership should represent responsibility for the next decision, not merely the person who triggered the workflow.
Testing should include repeated events and missing identifiers, not only a clean first submission.
When custom objects become part of a wider CRM operating model, review the workflow alongside pipeline design, reporting, ownership, and integration behavior. GoHighLevel configuration can solve a specific automation need, but the surrounding process still determines whether the data remains useful. For broader architecture and implementation support, see ConsultEvo CRM consulting. You can also review examples of connected operational systems in the ConsultEvo portfolio.
Frequently asked questions
What are custom objects in GoHighLevel?
Custom objects are user-defined record types for business entities that do not fit naturally into standard contacts, companies, or opportunities. They can have their own fields, relationships, ownership, and workflow behavior.
What does Create or Update Custom Object Record do in GoHighLevel?
The workflow action identifies a custom object record, optionally searches for an existing match, and then updates the record or creates one when the configured no-match behavior allows it.
When should a GoHighLevel workflow create a new custom object record?
A workflow should create a record when the incoming data represents a new business entity and the matching rule is precise enough to prevent duplicates. If identity is uncertain, stopping for review is safer.
What is the difference between finding a record from a trigger and finding one from contacts?
A trigger-based option uses the custom object record passed into the workflow event. A contact-based option searches for a custom object related to the contact or contacts currently in the workflow.
How can duplicate custom object records be reduced?
Define a stable record identifier, search before creating, choose the no-match behavior deliberately, test repeated events, and avoid using an ambiguous field such as a general name as the only matching condition.
Need a clearer CRM workflow design?
ConsultEvo can help map your business entities, ownership rules, relationships, and automation logic before implementation so your GoHighLevel workflows support reliable data and visible responsibility.
