What is underneath HubSpot's cards and boards

The short version

There's no SQL you or Ishwarya can reach. HubSpot hosts the databases and you work through the screens, reports, workflows and the API. The SQL below is a way of picturing what each screen action does, not real queries.

One lead, start to finish

A café owner sees a Meta ad and fills in the Revenue form. Here is everything that happens, with the "table" each step touches.

1. The form creates a contact. HubSpot's form system adds a row to the contacts table: name, phone, email and the form's answers. HubSpot's own tracking fills Original Source = Paid Social and its drill-downs (Facebook, the campaign). That source tracking only exists on contacts, which is why contacts can't be switched off.
2. The form submission is an event. The workflow engine sees "form submitted" and finds the workflows that trigger on it: [SG] Revenue IB Leads Routing (triggers on any of 18 forms).
3. Routing creates the company and the deal. It's a contact workflow, so it reads the contact's fields to decide the path. Then it adds a row to companies, a row to deals (pipeline Revenue Team SG, stage New Inbound, owner Reinie Lim), and the association rows linking all three. It also sets the contact's owner.
4. The new deal is another event. "Deal created" triggers Set Channel & Sub-Channel. It waits 2 minutes, then reads the contact's source fields and writes Deal Channel and Sub-Channel on the deal.
5. HubSpot's own sync moves the contact's lifecycle. Because the contact now has an open deal, HubSpot sets its Lifecycle Stage to Opportunity. This isn't a workflow, it's built in, and workflows can't move it backwards (we saw this in the live test).
6. Reinie works the card. She calls, books a demo and drags the card to Demo Scheduled. That's one change: the deal's Deal Stage value. It's also an event, so stage-change workflows run. After the switch, new workflow 3 sees the stage's probability is 40% and sets the deal's Lead Stage to SQL.
7. Every change is kept. HubSpot stores the history of each value: old value, new value, when, and what changed it (a person, a workflow, an import). That history is how I measured, for example, that the old BlueTap workflows overwrite the contact's source within 20 seconds.

sequenceDiagram
  autonumber
  actor Owner as Café owner
  participant Form as Meta ad form
  participant C as contacts table
  participant E as Workflow engine
  participant D as deals and companies tables
  participant A as associations (links)
  actor Reinie
  Owner->>Form: fills it in
  Form->>C: new contact row (name, phone, Original Source = Paid Social)
  C-->>E: event: form submitted
  E->>D: Routing: new company, new deal (Revenue, New Inbound, owner Reinie)
  E->>A: link contact, deal and company
  E->>C: Routing: contact owner = Reinie
  D-->>E: event: deal created
  E->>E: Set Channel waits 2 minutes
  E->>D: Deal Channel and Sub-Channel, read from the contact's source
  D-->>C: HubSpot's lifecycle sync: contact becomes Opportunity
  Reinie->>D: drags the card to Demo Scheduled (Deal Stage changes)
  D-->>E: event: deal stage changed
  E->>D: Lead Stage = SQL (new workflow 3)

The data, pictured as tables

If HubSpot were one SQL database, your portal would look roughly like this. Each object is a table. Your portal has 476 contact properties (87 made by EPOS), 436 deal properties (161 by EPOS) and 285 company properties (41 by EPOS). Most of them are empty on most rows.

erDiagram
  CONTACTS ||--o{ ASSOCIATIONS : "linked by"
  DEALS ||--o{ ASSOCIATIONS : "linked by"
  COMPANIES ||--o{ ASSOCIATIONS : "linked by"
  DEALS }o--|| STAGES : "Deal Stage"
  STAGES }o--|| PIPELINES : "belongs to"
  DEALS }o--|| OWNERS : "Deal owner"
  CONTACTS }o--|| OWNERS : "Contact owner"
  CONTACTS {
    id record_id
    text name_phone_email
    text original_source "set by HubSpot tracking"
    text lifecycle_stage "Lead, MQL, SQL, Opportunity, Customer"
    text enquiry_status "EPOS field"
    text lead_stage "EPOS field"
    text more "476 properties"
  }
  DEALS {
    id record_id
    text deal_name
    id pipeline "Revenue Team SG or MA Team SG"
    id deal_stage "the Kanban column"
    id owner
    text deal_channel_sub_channel
    text industry_parent_industry
    text lead_stage
    text more "436 properties"
  }
  COMPANIES {
    id record_id
    text name
    text more "285 properties"
  }
  ASSOCIATIONS {
    id from_record
    id to_record
    text type "contact-deal, deal-company, contact-company"
  }
  PIPELINES {
    id pipeline_id
    text label
  }
  STAGES {
    id stage_id
    text label "New Inbound, Demo Scheduled"
    number probability "0.1 to 1.0"
  }
  OWNERS {
    id owner_id
    text name "235 users"
  }

What the screens do, as SQL

The two Revenue ideas this explains

A stage is just a value. The pipeline and its stages are a short lookup list (Revenue has 14 stages, each with a probability: New Inbound 10%, Demo Scheduled 40%, Closed Won 100%). A deal "is in" a stage because its Deal Stage property holds that stage's ID. That's why workflow 3 can say "probability 40% or more" instead of listing stages.

The same fact is often kept twice. Source, industry, owner and lead stage exist on the contact and on the deal, and 90% of deals have exactly one contact. So for most leads, one lead is stored as two rows that workflows keep copying between. That copying is what the project removes: the team reads and writes the deal, and the contact becomes the name-phone-email row that forms, calls and ads need.

The workflow engine

A workflow is a saved rule with three parts. HubSpot stores each one as a document (we read them as JSON): a trigger, a list of numbered steps, and the arrows between the steps.

How it runs

• Queued, not instant. A change goes onto a queue and the engine picks it up within seconds. In the live test new 3 set SQL about 3 seconds after the stage change, and the old BlueTap workflows rewrote the contact's source 16 to 20 seconds after the contact was created.
• One copy per record. Each enrolled record walks through the steps on its own, so 50 new deals means 50 separate runs.
• Workflows set each other off. A value one workflow writes is a change, which is an event for every other workflow. That's how routing, then Set Channel, then the source fixes run in a chain. It's also the main risk: new 5 leaves the drop reason empty on purpose, so "[MA] Create Deal for Dropped Revenue F&B Leads" doesn't fire a second time.
• Timing is set with waits. Set Channel waits 2 minutes, so new 4 waits 5 minutes to make sure it corrects the channel after Set Channel has written it.
• HubSpot also has built-in automation outside the workflow list: form-to-contact, source tracking, and the lifecycle sync (deal created moves the contact to Opportunity). These can't be edited as workflows.

Your portal has 123 workflows, before our six: 44 on contacts (23 on), 71 on deals (48 on), 6 on tickets and 2 on companies.

The whole picture, in layers

The bottom layer is from HubSpot's annual report to the US SEC, which says it runs on HBase, Kafka, Vitess (to run MySQL at scale) and Elasticsearch. Which store holds what isn't public, so don't present the bottom layer in detail. It's there to show that the tables above are a mental model, not something EPOS manages.

How the new workflows were built and checked

This is the part that's ours. Everything lives in C:/dev/epos (git, on your Forgejo).

Switching over is all in HubSpot's own screens: turn the new workflow on, turn the old ones off. No code runs in production and nothing new has to be hosted.