CRM · Customer Data

Stop forcing structured data into a notes field

Custom Fields let you extend any contact or deal with typed, validated properties — KYC status, birth date, lifetime value, preferred language, JSON blob of feature flags. Fields populate from flows, imports, the API or by hand. They drive segments, gate flows, personalise templates, and never decay into free-text mush.

  • Text, number, date, boolean, select, JSON, file types
  • Validation rules and required-field enforcement
  • Bound to forms, flows, imports and API
  • Full change history per contact per field
The problem

The "notes" field where data goes to die

Watch what happens when a team without a proper data model needs to track something new — say, KYC status. First week: a rep starts typing "KYC done" into the notes field for each verified contact. Second week: another rep types "verified" instead. Third week: someone wants a list of all unverified customers and discovers they need to regex through 80,000 unstructured strings. By month two: a spreadsheet appears, lives in someone's laptop, drifts from CRM reality, gets emailed around as the source of truth for the compliance audit.

This is what happens when structured data has no home. The notes field is a graveyard — convenient to write to, impossible to query against, drifts with every new typist. Promoting a signal to a structured field is the fix, but only if the platform makes it cheap: easy to define, validated, exposed to every consumer, and tracked over time.

Custom Fields in SabNode CRM is built to make field creation cheap. Five clicks to define `kyc_status` as a single-select with three values. Five more clicks to backfill from a CSV. The new field shows up in segments, flow nodes, form bindings, broadcasts, the API and exports — all without engineering touch. Change history per field per contact gives compliance the trail they need. The notes field goes back to being notes.

What it is

Custom Fields, in depth.

A Custom Field is a typed property attached to a contact, deal, or company entity. Eight built-in types: short text (up to 255 chars), long text (up to 50,000 chars), number (int or decimal with precision), date (with or without time), boolean, single-select (controlled vocabulary), multi-select (multi-value controlled), and JSON (arbitrary structured blob). Each field has validation rules — required, regex pattern, min/max for numbers, allowed values for selects, JSON schema for JSON. Validation runs on every write path so bad data never enters the system.

Fields populate from every direction. Manually via the contact UI. From a flow node that sets a field after an event — `set kyc_status = "verified"` after the verification flow completes. From CSV imports with column-to-field mapping. From the REST API with bulk update endpoints. From web forms via a field-binding component that creates and updates contacts with the form's field map. Every write path validates, audits, and propagates to segments and downstream consumers in real time.

Fields are first-class everywhere they appear. Segments filter on field values with type-appropriate operators (string equals, number greater than, date within last N days, JSON path equals). Flow Branch nodes test field values to route execution. WhatsApp template variables interpolate field values — `{{contact.birth_date | date:dd MMMM}}` renders "15 August" inline. Broadcasts personalise from fields. AI Studio assistants access fields as part of the conversation context. The field is defined once and consumed everywhere by reference, not by copy.

Change history is preserved field-by-field, contact-by-contact, write-by-write. Every value change captures the timestamp, the source (flow node ID, API call, manual user edit, import job), the previous value and the new value. Queryable per contact ("show every change to `kyc_status` for contact X") and exportable for compliance. Retention is two years on standard plans, seven on enterprise — sufficient for most regulatory windows (DPDP, GDPR, RBI audit, HIPAA-aligned).

Capabilities

Everything you get with Custom Fields.

7 capabilities
01

Eight typed field types

Short text, long text, integer, decimal, date, datetime, boolean, single-select, multi-select, JSON, file reference. Each carries type-specific validation. JSON fields accept a JSON Schema for structured validation. File references point to SabFiles entries with permissions inherited.

02

Validation rules built in

Required, unique, regex pattern, min/max length, min/max value, allowed values list, JSON schema. Validation runs on every write path — form, flow, API, import — so bad data is impossible to enter. Errors surface to the writer with field-level detail.

03

Multi-source population

Manual edit, flow node action, CSV import with column mapping, REST API bulk update, web form binding. Every source validates and audits the same way. No "this came from the import so we did not validate" surprises.

04

First-class everywhere

Fields surface in segments (filter), flows (branch and set), broadcasts (personalise), templates (interpolate), AI assistants (context), the API (CRUD), exports (column), and forms (binding). One definition, every consumer.

05

Change history per field

Every field write captures timestamp, source, previous and new values. Queryable per contact for compliance and debugging. Retention is two years standard, seven on enterprise. Hard-purges on contact delete after the retention window.

06

Field-level RBAC

Restrict who can read or write specific fields. Sales reps see `lifetime_value`, finance edits it. Support sees `account_tier`, only admins change it. Sensitive PII fields (Aadhaar, PAN) gated to ops with audit trail. RBAC enforced on every read and write path.

07

Backfill and migrations

When you add a new field, the backfill tool runs a one-shot population from a CSV, a flow execution, or a rule evaluated against existing contacts. Schema migrations (rename, type change) handled atomically with downstream reference updates. No half-migrated state.

Use cases

Built for the way teams actually work.

Financial Services
Case 01

Fintech KYC structured tracking

Fields: `kyc_status` (single-select: pending, verified, rejected), `pan_number` (text with regex validation, PII-restricted), `kyc_verified_at` (datetime). Segments filter on status. Flows gate transactions on verified. Audit log proves to RBI inspectors exactly when each customer was verified.

E-commerce
Case 02

E-commerce loyalty tier

Fields: `loyalty_tier` (single-select: bronze, silver, gold), `lifetime_value` (decimal, auto-updated by flow on each order), `last_purchase_at` (datetime). Tier auto-derived from lifetime_value via rule. Segments per tier drive differentiated broadcasts and offers.

EdTech
Case 03

EdTech course preference

Fields: `target_exam` (multi-select: NEET, JEE, CAT, GMAT), `preferred_language` (single-select: Hindi, English, Tamil, Telugu), `study_hours_per_week` (integer). Drives course recommendations from AI assistant and language selection for broadcast templates.

Healthcare
Case 04

Healthcare patient demographics

Fields: `dob` (date, validated > 1900), `allergies` (long text), `preferred_doctor` (single-select from doctor list), `last_consultation` (datetime). PII-restricted to clinical staff. Drives age-appropriate reminders and doctor-affinity in appointment scheduling.

SaaS
Case 05

B2B SaaS account metadata

Fields: `company_id` (text), `company_size` (integer), `mrr` (decimal), `feature_flags` (JSON with schema). Flow branches on feature_flags.advanced_reports to send relevant updates. AI assistant uses MRR for tier-appropriate response style. JSON schema prevents typos in flag names.

How it works

From signup to first send in minutes.

Custom Fields is included on every SabNode workspace. No separate billing, no extra setup — flip it on from your workspace settings.

  1. 01

    Define the field

    Pick entity (contact, deal, company), name, type, validation rules. Set RBAC per field. Save and the field is immediately available everywhere.

  2. 02

    Populate from sources

    Backfill from CSV, set from a flow node, expose in a web form, write via API. Every source validates the same way.

  3. 03

    Reference in consumers

    Build segments filtering on the field. Branch flows on field values. Interpolate into templates. Surface in AI assistant context. All by reference — change once, propagates everywhere.

  4. 04

    Audit and govern

    Change history per contact per field. Field-level RBAC restricts access. Schema migrations atomic across all references. Sensitive fields tagged PII with extra audit.

  5. 05

    Iterate

    Add validation rules as data quality issues surface. Rename and migrate fields atomically when terminology evolves. Archive unused fields. Field library page shows usage and stale candidates.

Plays well with

Works with the tools you already ship on.

ShopifyHubSpotSalesforceGoogle SheetsBigQueryStripeRazorpayZapier
Frequently asked

Questions about Custom Fields.

Can't find what you're looking for? Talk to our team.

Should I make every signal a custom field?
No. Use a custom field when the signal is structured, singular, and queryable — `kyc_status` (one of three values), `birth_date` (one date). Use a tag for binary or multi-value fast-moving signals. Use a custom field with JSON type when the signal is structured but has many sub-properties (feature flags, address blob). The wrong choice is putting structured data in long-text notes, where it cannot be queried or validated.
Can a JSON field have validation?
Yes. Attach a JSON Schema to the field and every write validates against it. Common pattern: `feature_flags` field with a schema declaring known flag names and their value types. Writes with unknown flags or wrong types fail validation with a field-level error. This catches bugs at the boundary instead of letting them propagate through flows and AI prompts.
How are field renames handled?
Atomically. Rename a field once and every reference — in segments, flows, broadcasts, AI prompts, exports, API queries — updates in a single transaction. No "half-renamed" intermediate state. The audit log captures the rename. Old field name is reserved for 30 days after rename to catch any external integrations that referenced it; we surface a warning in the audit page for any access attempts on the old name.
What is the limit on the number of custom fields?
50 fields per entity on Starter plans, 100 on Growth, 200 on Enterprise. In practice most tenants run with 15-40 fields. Beyond 50, consider whether some fields belong on a related entity (deal, company) instead of bloating the contact model. Field-library hygiene matters — the library page surfaces stale fields with zero writes in 90 days as candidates for archival.
Can field history be queried via API?
Yes. The change-history endpoint accepts contact ID, field name, and a time window, returning the full sequence of changes with timestamp and source. Useful for compliance exports, debugging "why did this contact get this template" investigations, and BI ingestion when you need historical state-over-time for cohort analysis. Rate-limited to prevent accidental scrapes.
How do PII fields differ from regular fields?
Mark a field as PII (Aadhaar, PAN, credit card, SSN) and the platform applies extra protections: write requires explicit RBAC permission, reads are logged separately for audit, exports require additional approval, and field values are masked in default UIs (showing last 4 digits only). AI Studio redaction strips these values before prompts reach the model. The field still functions like any other for flows and segments — protections are about who can see the raw value.
Can I prevent two writes from racing on the same field?
Yes via optimistic concurrency. The API accepts an `If-Match` header with the field's version token; writes that race against a concurrent update fail with 412 and surface the current value. For flows, set node modes are atomic — the platform serialises writes per (contact, field) so two parallel flow executions that both want to set the field cannot create a half-update. JSON fields support patch operations that merge rather than overwrite for sub-property writes.
CRM · Customer Data

Ship custom fields into production this week.

No credit card. No sales call required. Spin up a workspace, plug in a number, and your team is live in under an hour.