Drag-and-Drop Form & Workflow Builder

Forms were never a one-and-done part of the product. Business teams needed to add a field, reorder a section, retire an old question, or stand up an entirely new form on a routine basis, and under the existing setup none of that was something they could do themselves. Every change, however small, had to be translated into a developer ticket, queued alongside other engineering work, implemented in code, and shipped through a release. A single-field tweak carried the same procedural weight as a substantial feature, because both had to travel the same path from request to deployment.

That dependency created a structural bottleneck between the people who understood what a form needed to say and the people who had to write the code to say it. Business users were the ones closest to the requirement — they knew which question needed rewording, which field needed removing, which new form a process required — but they had no direct way to act on that knowledge. Every request went into an engineering queue and sat there until a release cycle had room for it, which meant the pace at which forms could evolve was set by developer availability and deployment cadence rather than by actual business need.

The goal was to close that gap by putting form creation and modification directly in the hands of the people who needed forms changed. Business users needed to design forms visually, with no code of their own to write, and reuse the forms they built across the product rather than recreating similar forms from scratch each time. Just as important, those forms needed to connect to downstream automation — a submission had to be able to trigger the next step in a process rather than sit as a static record — and all of it had to work without engineering standing between a business user and the change they needed to make.

The architecture followed directly from that goal, with each decision building on the one before it:

• Treated forms as data, not code: every form is a portable schema, so adding or editing forms requires zero deployment. If forms had stayed code, every change would have run straight back into the same developer-ticket-and-release cycle the project was meant to eliminate. Representing a form as a portable schema instead turns a business user's edit into a data change rather than a code change, so it can take effect without engineering touching a deployment pipeline. This was the foundational decision the rest of the architecture depended on — it is the piece that actually removed engineering from the loop.
• Built one dynamic renderer driven by that schema, eliminating duplicated form code and keeping behavior consistent. A schema only becomes a usable form if something can interpret it and render it on screen, so a single dynamic renderer was built to do exactly that for any schema handed to it. Because every form passes through the same renderer instead of having its own bespoke implementation, behavior stays consistent regardless of which form a user encounters, and there is no duplicated rendering logic scattered across the product to keep in sync.
• Separated authoring (the builder) from execution (rendering and workflow) so each side evolves independently. The builder, where business users construct a form's schema, was kept as a distinct layer from the renderer and workflow engine that actually execute it. That separation means the two sides can change on their own schedules: the builder's interface can be improved without touching how forms behave in production, and the execution layer can evolve without disrupting the authoring experience business users depend on day to day.
• Modeled the workflow engine around form events, so submissions hand off cleanly into automated downstream steps. Rather than treating a submission as an endpoint, the workflow engine was modeled around form events, so a submission itself becomes the trigger for whatever downstream automation needs to run next. This event-based design is what let forms connect into automation without bespoke integration work for each individual form — the handoff from submission to downstream step follows the same pattern no matter which form triggered it.

• Put form and workflow creation directly in non-technical hands, removing the developer-and-release bottleneck. Business users can now build and adjust forms, along with the workflows attached to them, on their own, without opening a developer ticket or waiting on a release window. The bottleneck the project set out to remove is gone in practice: a form change is something a business user completes themselves, at the pace the business needs, rather than something that has to wait its turn in an engineering queue.
• Reusable schemas — rather than bespoke code — let the team ship and update forms far faster. Because a form is a schema rather than a piece of custom code, building or updating a form is a matter of working with its schema rather than writing and shipping custom code for it, which is what makes both creating new forms and revising existing ones so much faster than the old code-and-release approach.
• One rendering engine keeps form behavior consistent everywhere a form appears across the product. Every form in the product, wherever it appears and whoever built it, is rendered by the same engine, so it behaves identically in every context. That consistency means users get one predictable form experience across the product instead of subtly different behavior depending on which part of the product a form happens to live in, and it means the team only has to reason about a single rendering implementation rather than several parallel ones.