On this page

Jump to any section using the links below

The Hubhus data model is flexible and campaign-driven.
There are no predefined “standard fields” in a campaign — each campaign defines its own structure depending on the workflow it represents. This article explains how Hubhus organizes data, how core entities relate to each other, and how you can design clean, scalable data structures.

Core entities in Hubhus

Campaign

A campaign is a self-contained workflow module.
Each campaign defines its own:

• Fields

• Select lists

• Statuses

• Booking forms & pages

• Automations & listeners

• Filters

• Integrations

Examples of campaigns:

• Quotes

• Service visits

• Product orders

• Support cases

• Installations

• Vehicle preparation

• Documentation collection

Each campaign has its own data model, and leads in one campaign do not share fields with leads in another.

Lead

A lead is an instance of work inside a campaign — a single customer journey, task, order, or case.

A lead contains:

• Field values (defined by the campaign)

• Select values

• Status

• Files

• Checklists

• Events

• History

• Relations to other leads or campaigns

The same person may appear as different leads across multiple campaigns (e.g., Quote → Installation → Invoice), each with different fields and rules.

Event

An event is a calendar booking created either:

• by a customer through a booking form, or

• manually by an internal user.

Events always belong to:

• a resource, and

• optionally a lead, depending on the campaign flow.

Events include:

• Start/end time

• Duration

• Address

• Assigned resource

• Travel and buffer requirements

• Metadata (origin, creation time, booking form used)

Events drive scheduling and availability but do not define the lead’s data model.

User

A user is a person who logs into Hubhus with specific permissions.

Important distinction:
A user is not automatically a resource.

A user:

• has access rights

• can edit leads

• can manage campaigns

• may appear as assigned_person

…but is not used for availability unless also configured as a resource.

Resource

A resource is anything that can be booked:

• A technician

• A consultant

• A team

• A vehicle

• A room

Resources have:

• Calendars

• External sync options

• Business hours

• Special dates

• Travel rules

• Tags

Events attach to resources, and resource availability determines what booking forms can show.

Relationships between entities

Campaign → Lead

Every lead belongs to exactly one campaign.
Each campaign defines its own data structure; leads cannot share fields across campaigns.

Lead → Event

A lead can have zero, one, or multiple events.
Events are linked back to the lead but remain independent scheduling objects.

Event → Resource

Every event must have at least one resource.
Availability depends on that resource’s calendar, driving rules, and sync.

User ↔ Lead / Event

Users appear indirectly via:

• assigned_person

• created_by

• updated_by

…but they do not control availability unless configured as resources.

Fields (all fields are custom fields)

Hubhus does not provide predefined fields inside campaigns.
Every campaign defines its own fields based on purpose.

You decide:

• Field names

• API slugs

• Types (text, number, date, select, JSON, checkbox, etc.)

• Validation rules

• Visibility rules

Fields define what data exists on a lead and what can be used in:

• pages

• templates

• automations

• filters

• API requests

• conditional logic (@if)

There is no assumption that leads have email, name, phone, or address unless you create those fields.

Relations

Relations are not fields — they are links between objects.

Examples:

• Linking a “Quote” lead to its “Installation” lead

• Linking uploaded documentation to a lead

• Linking an invoice campaign lead back to the original request

• Linking an event to the lead that created it

Relations allow multi-campaign workflows without merging data structures.

They enable clean flows like:

Quote campaign → Installation campaign → Invoice campaign
(each with its own fields and logic)

Data hierarchy

Hubhus follows a clear structure:

1. Account
   Contains all campaigns, users, and resources.

2. Campaign
   Defines the data model (fields, selects, statuses, rules).

3. Lead
   Implements the campaign’s data model.

4. Event
   Schedules work via resources.

5. Resource
   Controls availability and sync.

6. User
   Controls permissions and access.

7. Relations
   Connect objects across campaigns.

Best practices for organizing your data

1. Use multiple campaigns for different workflows

Don’t mix unrelated processes into one campaign.

2. Only create fields you actually need

Avoid unnecessary fields that clutter the data model.

3. Keep field API slugs stable

Once a field is used in automations or API, avoid renaming.

4. Use select fields for categorization

Cleaner filtering, better automations, more consistent reporting.

5. Use relations for cross-campaign workflows

This avoids duplicated data and keeps processes modular.

6. Treat events as independent scheduling objects

An event is not “just a timestamp”—it represents actual scheduled work.

Learning outcome

After reading this, you should understand:

• How leads, campaigns, events, users, and resources relate

• That all fields are campaign-defined (no system fields)

• How Hubhus structures data in a modular way

• How relations link workflows together

• How to design clean, scalable data models in Hubhus

Related articles

Understanding custom fields
What is the Hubhus API?
Building workflows in Hubhus
Understanding action listeners
What is automation in Hubhus?