Skip to main content
The CRM module lets you define custom entity types, fields, pipelines, and stages — then store structured data entries linked to any record in the system. Think of it as both a customer relations management tool and a general-purpose data platform (like Webflow CMS Collections). You can create traditional pipeline-based entities (deals, contacts) or standalone data collections (properties, inventory, cities).

How entries attach to records

Each CRM entry is linked to a record in your funnel or store through two values: This pattern lets you attach structured data to customers, orders, or custom reference types you define.

Concepts

Entries vs. Fields: An entry is a single record or document stored in the CRM (like a row in a database, representing e.g. a specific check-in for a customer). A field is a specific piece of data that lives inside an entry (like a column, e.g. “current_weight” or “deal_value”).

Entity Modes

Entities operate in one of two modes: When creating an entity, choose “Data Collection” to skip pipelines entirely. Data-mode entities focus purely on fields and entries.

Entities

An entity defines a type of CRM record (e.g. “Deals”, “Contacts”, “Properties”). Each entity has:
  • A name and slug (machine-readable identifier)
  • An entity mode (crm or data)
  • Fields that define the data structure
  • Pipelines with stages for workflow tracking (CRM mode only)

Fields

Fields define what data can be stored on entries. Each field has:

Supported field types

The type in CRM settings controls how the field appears and behaves in the admin UI. It does not change what you pass from code: setCrmField always sends a JavaScript value — a string, number, boolean, or a JSON object. For fields configured as date in the CRM, pass a date-time string from scripts, typically ISO 8601 (e.g. new Date().toISOString() or '2026-03-15').

UI-editable fields

Set ui_editable: false on fields that should only be updated programmatically (via backend scripts). These fields display with a lock icon in the admin UI and cannot be inline-edited. Use reporting_config to mark fields as reportable and suggest how the Reports tab should aggregate and chart them. Supported values include reportable, aggregation_type (numeric, categorical, date, boolean), baseline (min/max), bucket_size, and preferred_chart (kpi, histogram, pie, bar, line).

Relations

Relations link entries across entities. A field of type reference or multi_reference creates a relation between the current entity and a target entity. Relations are stored in Elasticsearch alongside the entry data.

Configuring reference fields

When creating a reference field, specify:
  • Target entity: Which entity the reference points to
  • Display field: Which field from the target entity to show as the label (defaults to title)

Working with relations programmatically

Use SetCrmRelation and RemoveCrmRelation to manage relations. These two are template-engine functions — they are not available in backend scripts:

Pipelines & Stages

Pipelines represent workflows (CRM mode only). Each pipeline contains ordered stages with optional colors and semantic statuses (e.g. won, lost, active). Entries move through stages as they progress.

Customer CRM Data

The most common pattern is linking CRM entries to customers. When a customer visits a page, their session supplies the customer context so CRM defaults attach to the right person (creating the customer record when needed).

Example: Weight Loss Tracker

  1. Create a CRM entity called “Weight Tracker” with slug weight-tracker and fields like current_weight, goal_weight, last_checkin
  2. Create a pipeline “Progress” with stages “Starting”, “In Progress”, “Goal Reached”
  3. Store data via backend scripts or the template engine:
slug identifies the CRM entity (board/type). referenceType / referenceId default to the current customer when omitted. For another record: setCrmField({ slug: 'weight-tracker', referenceType: 'order', referenceId: '12345', fieldKey: 'status', value: 'shipped' }). See Data Functions.
  1. Read it back on any page:

Viewing Customer CRM Data

Customer CRM entries are visible in the Customer Details page under the CRM tab. This shows all CRM entries linked to that customer across all entity types.

Functions

Write functions accept an optional async parameter (default false). When true, the write runs in the background for faster response times. Read functions are always synchronous.
The function names differ between the two runtimes, and calling the wrong one takes the page down.
  • Template engine ({{ }} / @if inside a page or component) — PascalCase: SetCrmFields({...})
  • Backend scripts (<script scope="backend"> and standalone scripts/*.js) — camelCase: setCrmFields({...})
An undefined function is not ignored — it aborts the render, and a live page starts returning 404. Three functions exist in templates only (CreateCrmEntry, SetCrmRelation, RemoveCrmRelation) and reassignCrmReference exists in backend scripts only; there is no createCrmEntry in a backend script. To create an entry from a backend script use addCrmFieldValue({...}), or setCrmFields({...}) to upsert.Test with a draft and open the preview URL before publishing.
The table below uses the backend-script (camelCase) spelling. For the template engine, capitalise the first letter. slug is always required (the entity’s slug from CRM settings). Reference defaults: customer + session customer id.

Common options

Every CRM function accepts these optional properties: Write functions also accept:

Single-value fields

Use setCrmField / getCrmField for fields that hold one value per key (e.g. weight, goal, last check-in date):
When you need to read multiple fields at once, use getCrmFields and pass an array of fieldKeys:
When writing multiple fields in one script, prefer setCrmFields so all values are merged in one read/write cycle:
If you need to keep separate setCrmField calls, pass force: true to skip the per-key scan and merge directly into the newest entry — much faster for sequential writes:

Multi-value fields

Use addCrmFieldValue / getCrmFieldValues when a key can have multiple values over time (e.g. weigh-in history). Each addCrmFieldValue call creates a separate CRM entry:

Clearing entries

Use clearCrmEntries to delete all entries for an entity + reference:

Pipeline and stage movement

Use moveCrmLead to move a CRM entry to a specific pipeline and stage by id or slug:
Returns { ok, moved, totalMatched, pipeline_id, stage_id }. moved is the number of entries updated (1 unless allEntries: true). Use moveCrmToStage when you only know the stage — the pipeline is resolved automatically:
Use moveCrmToPipeline to move an entry into a pipeline; it lands on the first stage:
Use moveCrmToEntity to copy field values from one entity type to another (e.g. promoting a lead to a deal):
Returns { ok, moved, removed_from_old }. Pass allEntries: true to any move function to update all matching entries instead of just the newest one.

Ensuring entities programmatically

Use EnsureCrmEntity at the top of a backend script to idempotently provision an entity. Re-runs never overwrite admin edits — only missing fields are added.

Creating entries

Use CreateCrmEntry to create a new entry and get back its ID (useful for setting relations). This is a template-engine function — from a backend script use addCrmFieldValue({ slug, fieldKey, value }) or setCrmFields({ slug, fields }) instead, as there is no createCrmEntry there:

Managing relations

Use SetCrmRelation to link entries:
Use RemoveCrmRelation to unlink:

Async writes

For non-critical writes where you don’t need immediate consistency, pass async: true so the write runs in the background:
See Data Functions for full parameter details and examples.