Form Builder Feature Landscape
Where OnRamp's form builder sits against best-of-breed form tools, the near-term authoring features the shipped foundation unlocks, and the one hard problem that gates the biggest differentiator.
🔬 Scope — this is the product surface and roadmap: authoring UX, the capability gap against Typeform / Jotform / SurveyJS / Vueform, and the sequencing that follows. The storage/engine/AI design underneath is a separate doc, Form Builder Architecture. Where a feature depends on that foundation, it is called out.
TL;DR
Generic form builders are standalone; OnRamp's forms live inside the platform
They sit inside projects, data fields, CRM sync, a customer portal, playbooks, and AI agents. The winning strategy exploits that context, not widget parity.
The unfair advantage is context + AI — and it's mostly unbuilt
Semantic prefill from the onboarding record, write-back to the data model, and AI form generation are where OnRamp wins rather than matches. Prefill/binding is missing almost entirely today.
Foundation first, then context + AI, then breadth
The registry foundation is the AI-authorability unlock. Build context/data binding and AI on top of it, harden governance/accessibility alongside the portal, and fill category breadth opportunistically — never a knob without a real second case.
Question & scope
The form-builder foundation makes the definition declarative, versioned, and AI-authorable. Given that, what should get built, and in what order, to make OnRamp's form builder best-of-its-kind rather than a Typeform clone? This doc answers by laying the current baseline against the category and ranking the roadmap by leverage.
The V1 baseline
Stated plainly so the roadmap doesn't chase what already exists:
| Capability | Today |
|---|---|
| Form-level settings | global margin + spacing only — no title, theme, layout, cover, progress, thank-you, submit-label, or field width |
| Element types | ~22, none of the survey family (rating/NPS/scale/matrix/ranking/slider) or structured contact types (address/phone) |
| Conditionals | visibility only — no conditional-required, conditional-disabled, or calculated value |
| Prefill / binding | none — only the Signature element loads a saved value |
| Answer piping | merge fields work only in static Paragraphs, not in field labels or headings |
| Validation | required + table row-count + in-table number/date bounds — no regex, email, length, cross-field, or masks |
| Containers | columns / group / list / table — no page / section / stepper |
| History | no undo/redo |
The framing that matters: those gaps split into ones that match the category and ones that exploit OnRamp's context. The second kind is where the leverage is.
Near-term authoring workstreams
Ranked by value × fit, all riding the declarative registry foundation:
The visibility dependency graph already exists as a derivable edge list. Surface it: an in-canvas overlay with hover-illuminate (hover an element, light up what it controls / what controls it) as the primary UX, plus a full "Logic Map" graph view for troubleshooting. Cycle highlighting and orphan/broken-ref surfacing fall out of the same edge list.
One optional settings overlay — a defaults object plus per-form overrides, spelling out only genuine deviations. Blocks: layout (max-width, label placement, density), per-element field width (retiring the rigid columns container), chrome (title, cover, submit label, thank-you), progress, theme, behavior. A pure resolveFormSettings() resolver reads by every render surface, so what the author previews is structurally what the customer gets.
A page container in the adjacency list, rendered as a stepper. Ship layout first, then add page-level visibility conditions — which unifies branching onto the one conditional engine and lets legacy branching be retired from the authoring UI while runtime support stays. This reframes pages from "a layout feature" into the vehicle that converges branching.
Presentation and Embed become content-element plugins (known config shapes, no answers, no external state) so those subtask types leave the palette. E-sign consolidation is deliberately deferred — the drawn/typed Signature element and the Adobe-template signing model don't trivially merge, and merging pulls external state + webhooks into the builder.
A history stack of canonical-envelope snapshots (flat, diffable), composing with AI patch-by-id edits so "undo the AI's last change" is free. The save model is a deliberate asymmetry: the definition is manual-commit with local draft recovery (it's a shared live artifact), the opposite of the answer side which autosaves because it's the user's own data.
Once the JSONLogic engine is in place, reuse it for a read-only value slot — totals, scores, concatenations, derived dates. High perceived value, low marginal cost after the engine ships.
The capability ladder against the category
Ranked by leverage, not by how the category orders its feature lists.
Tier 1 — Context & data intelligence · the unfair advantage
A generic form is a blank silo; an OnRamp onboarding form should already know the customer. This tier is the single biggest differentiator and is missing almost entirely.
- Prefill / data-field & CRM binding — populate fields from the project's data fields, contact/account records, and Salesforce/HubSpot on load. The category tops out at URL-param/hidden-field prefill; OnRamp can do semantic prefill from the onboarding record.
- Write-back / bidirectional field mapping — answers map back to data fields / CRM, so the form is part of the data model, not a dead end.
- Answer piping everywhere — reference earlier answers and project/contact data in later labels, headings, and content, not just static paragraphs.
- Lookup / dynamic option sources — dropdown/radio options from a dataset or API, not hand-typed lists.
Tier 2 — AI authoring & response intelligence · the moat
- AI form generation from a prompt — the declarative registry is precisely what makes a form LLM-emittable; the highest-leverage AI feature, enabled because the foundation work is done.
- AI-assisted logic & validation — author speaks intent ("hide these for SMB customers", "make this a valid EIN"), the engine gets the expression.
- AI response summarization / extraction / risk-flagging — summarize a submission, extract structured signals, feed Insights and the CS team.
- Conversational fill — complete a form by chatting with the agent; answers still land as structured values.
Tier 3 — Enterprise governance & trust · the gate to selling up-market
- Accessibility (WCAG 2.2 / EAA) — the portal renderer is customer-facing, so this is real liability, not polish; treat it as a first-class renderer principle.
- PII / compliance — masking, retention/erasure, consent capture with timestamp + policy version, residency. Masking scope is a live product decision because masking webhook payloads collides with the untouched answer contract.
- Versioning + audit trail, submission approval workflows, role & field-level visibility, localization / RTL.
Tier 4 — Respondent completion experience
Save-and-resume + autosave, conversational one-question-per-page mode, inline validation, accessible error summary, progress + time estimate, mobile-first. Completion rate is the onboarding KPI, and the portal is phone-heavy.
Tiers 5–8 — breadth & polish
Survey family (NPS, scale, matrix, ranking); structured contact (address, phone, typed email/URL); consent/legal blocks; scheduling; rich validation + input masks; field-level funnel / drop-off analytics into Insights; export; authoring collaboration (copy/paste across forms, comments, import/export, keyboard shortcuts).
Competitive rule. Do not out-Vueform Vueform feature-for-feature. Win on project context + CRM + portal + playbook AI + Insights — the surfaces standalone tools can't touch. Tiers 1–2 are where OnRamp wins; Tier 3 is the gate that makes it sellable to enterprise; Tiers 4–8 keep parity with the category.
The cross-context binding problem · Tier 1's hard part
Tier 1 is the biggest differentiator and has stayed unbuilt because its real blocker isn't UI — it's that a form's data bindings are authored in an abstract context but must resolve in a concrete one, and the two don't share data.
Library task / module — has reusable structure; has no vendor, project, customer, data fields, or CRM connection. The most abstract context, disconnected from everything a binding would target.
So authoring "bind this field to the account's industry" in a playbook template references something with no value — or even no definition — in the current context, and the reference must survive and be re-pointed as the artifact crosses each boundary (library → playbook → project). Why it's genuinely hard:
- Authoring context ≠ resolution context. The binding must be symbolic at author time (a named slot, not a concrete id) and resolve late against whatever the project has.
- The reference must survive and remap across the cascade — the same way module link-state and merge-field usage are remapped when artifacts clone across contexts.
- Unresolved is the normal state, not an error — an abstract context often has no target yet; it needs a graceful unresolved state and an authoring-time signal ("resolves at project creation"), never a silent failure.
- Ids are environment-dependent — bind by stable key/uuid, never a numeric id.
The shape of the solution is a unified, cascade-aware reference layer: one grammar to name a piece of data symbolically at authoring time — over data fields, CRM fields, project/account/contact attributes, and prior answers — that a resolver turns into a value (or write target) at instantiation/render, with the cascade carrying and remapping it at each boundary. The machinery to generalize already exists: CRM/Workflows field mapping (the closest "late binding across a boundary" pattern) and the clone-time merge-field remap. This reference grammar is reserved in the envelope today (the binding key — see Form Builder Architecture); the resolver generalizes outward from prefill-at-project-create to the fuller catalog.
Recommendation
Finish the near-term authoring workstreams that ride the foundation — they are what enable AI and are immediately felt by authors. The settings overlay and undo/redo depend on nothing else and can start now.
Tier 1 (context/data binding) and Tier 2 (AI). Tier 1's real prerequisite is the cross-context binding layer above — generalize the existing field-mapping machinery rather than building binding UI first.
Harden governance and accessibility (Tier 3) alongside the portal's component work, then fill category breadth (Tiers 4–8) opportunistically as onboarding use-cases demand — never adding a knob or an element type without a real second case.
Risks & open questions
The pull to match Typeform feature-for-feature is strong, and it spends effort where OnRamp only ties.
Mitigation: the competitive rule — breadth is opportunistic; context + AI + Insights come first.
Masking webhook payloads would change what existing Zapier/CRM mappings receive.
Mitigation: raw-at-rest is fixed regardless; which serialization surfaces mask (UI / exports / webhooks) is an explicit product decision, not an engineering default.
Open questions
When does a binding resolve — at project creation, or at each render? Decided for the sources that exist today (defaulted by source); reopens only for a genuinely new source or a live-refresh feature.
What's the referenceable-slot catalog per context, and how does it degrade abstract → concrete? What can a library task even offer when it has no project? This is the core of the cross-context binding spike.
Related
- Form Builder Architecture — the storage/engine/AI foundation these features ride on.
- Task as One Document — the substrate-convergence horizon beyond this roadmap.