Enforce Required Fields & Data Governance in HubSpot Programmatically
Stop reps from skipping fields. Enforce email formatting, enum values, and required properties from YAML specs with full audit trail.
The Problem
Reps skip fields. Data rots. Reports break. Your pipeline reviews are based on incomplete records with missing deal sources, invalid emails, and freeform text where there should be enums.
You are paying a contractor to manually configure validation rules in the HubSpot UI — clicking through each property, each object, one at a time. There is no version control, no audit trail, and no way to replicate the setup across portals.
HubSpot's Governance Surface Area
HubSpot's notion of "required field" varies by surface.
There is no single "make this field required" toggle that works everywhere. Instead, HubSpot provides three different mechanisms, each with its own scope and API surface. Understanding which mechanism applies is critical to getting governance right.
"Required on create" via requiredProperties
Custom objects support a requiredProperties array. When set, the HubSpot API rejects creates missing those fields. Managed via objects apply.
"Validation rules" for format enforcement
Regex, enum, phone, and email normalization rules. Enforced on record save in the UI. Managed via validations apply.
"Stage gating + workflows" for process compliance
Conditional required fields when moving between pipeline stages. Configured in HubSpot UI. g-gremlin can detect drift via snapshot.
How g-gremlin Enforces Governance
Three commands, three surfaces. Each one is plan-first, idempotent, and produces receipts.
validations apply
Formatting rules
Apply regex, enum, phone, and email validation rules per property. Rules are enforced on record create and update in the HubSpot UI.
objects apply
requiredProperties on custom objects
Set requiredProperties on custom object schemas. The API rejects creates missing those fields. Standard objects do not support this API surface.
props apply
Property definitions
Define correct types, field types, options, and descriptions. Prevent drift from manual UI changes. Idempotent on re-run.
Example: Email & Deal Source Governance
Two spec files enforce email/phone formatting and enum constraints on deal source.
version: 1
rules:
- object_type: contacts
property_name: email
rules:
- rule_type: EMAIL_VALIDATION
rule_arguments: []
- object_type: contacts
property_name: phone
rules:
- rule_type: PHONE_VALIDATION
rule_arguments: []
- object_type: deals
property_name: deal_source
rules:
- rule_type: ENUMERATION
rule_arguments:
- inbound
- outbound
- partner
- eventversion: 1
objects:
deals:
properties:
- name: deal_source
label: "Deal Source"
type: enumeration
field_type: select
group_name: dealinformation
description: "How this deal originated"
options:
- label: "Inbound"
value: "inbound"
- label: "Outbound"
value: "outbound"
- label: "Partner"
value: "partner"
- label: "Event"
value: "event"Plan & Apply
Pack the governance specs and apply. Every validation rule is tracked.
# Validate first
$ g-gremlin hubspot doctor
✓ Token valid · Portal: acme-corp · 12 scopes OK
# Preview the governance plan
$ g-gremlin hubspot pack plan ./governance_pack
⟳ Plan generated:
+ Validation rule: contacts.email (EMAIL_VALIDATION)
+ Validation rule: contacts.phone (PHONE_VALIDATION)
+ Validation rule: deals.deal_source (ENUMERATION)
+ Create property: deal_source (enumeration/select, 4 options)
✓ Dry-run complete. 3 validation rules, 1 property to create.
# Apply
$ g-gremlin hubspot pack apply ./governance_pack --yes
✓ Validation rule applied: contacts.email (EMAIL_VALIDATION)
✓ Validation rule applied: contacts.phone (PHONE_VALIDATION)
✓ Validation rule applied: deals.deal_source (ENUMERATION)
✓ Property created: deal_source (4 options)
✓ Applied. Snapshots: artifacts/20260127_150044/before · after
The Receipts
Compare snapshots to verify every governance rule was applied.
$ g-gremlin hubspot compare-snapshots snapshots/baseline artifacts/20260127_150044/after_snapshot
✓ Comparison complete.
Validation Rules:
+ contacts.email — EMAIL_VALIDATION — added
+ contacts.phone — PHONE_VALIDATION — added
+ deals.deal_source — ENUMERATION — added
Properties:
+ deal_source (deals) — added
Summary: 4 added · 0 changed · 0 removed
Limitations
We are explicit about the boundaries of CLI-managed governance.
- Validation rules cover specific rule types (EMAIL_VALIDATION, PHONE_VALIDATION, ENUMERATION, REGEX, etc.). Not all HubSpot validation surfaces are CLI-managed.
- Standard object "required" fields (contacts, companies, deals, tickets) require the HubSpot Settings UI or workflow enforcement — g-gremlin does not flip UI-only "required" toggles. However, you can still detect drift via snapshot comparison.
- Pipeline stage requirements (conditional properties when moving to a stage) are managed via HubSpot UI, not the g-gremlin CLI.
- For full process compliance, combine g-gremlin governance specs with HubSpot workflow automation.
Bottom line: g-gremlin covers the API-managed governance surfaces (validation rules, custom object requiredProperties, property definitions). For UI-only surfaces (standard object "required" toggles, conditional stage requirements), use the HubSpot Settings UI and detect drift with snapshot + compare-snapshots.
The 5-command loop — the signature g-gremlin workflow:
g-gremlin hubspot doctor
g-gremlin hubspot snapshot --out snapshots/baseline
g-gremlin hubspot pack plan <pack_dir>
g-gremlin hubspot pack apply <pack_dir> --yes
g-gremlin hubspot compare-snapshots snapshots/baseline <after_snapshot_dir>
Ready to Enforce Data Governance?
Define your validation rules and property specs in YAML. Apply in minutes. Get receipts.