Author: Skydu
Summary: A form engine may look like the most basic capability in a low-code platform, but it is really the entry point for business modeling, data structure, permissions, workflows, and future AI understanding.
Opening
In the previous post, I wrote about why INFORMAT is not meant to be only a low-code tool. Starting from this post, I want to go into specific modules.
The first module I want to write about is the form engine.
The reason is simple: in a low-code platform, forms look basic, but a form is not just a page. Many enterprise business systems begin with a form. Customer registration, contract approval, project initiation, purchase requests, inventory receiving, equipment inspections, and production reporting are all, at their core, ways to collect, organize, and move business data.
So a form engine is not about dragging a few input boxes onto a canvas. It is the entry point for the platform's business modeling capability.
The initial requirement looked simple
Before building the form engine, my most straightforward idea was this: users should be able to create business forms, configure fields, and let the system automatically generate data-entry pages and data lists.
That idea does not sound complicated. A form name, a group of fields, a save button, and a data list seem like enough.
But once implementation begins, a series of questions appear quickly. What field types should exist? Can fields be grouped? Can fields depend on each other? Should data be validated? Should a workflow be triggered after submission? Can different people see different fields? How will form data be used by reports, automation, and AI?
When these questions stack together, the form engine stops being only a frontend component. It becomes a core module that connects the data model, permission system, workflow system, and automation system.
A form is not a page, but a business model
I gradually became more certain of one judgment: forms in a low-code platform should not be designed only as pages. They should be designed around business models.
A page answers the question of what users see and how they fill it in. A business model answers what the business object is, how the data is stored, how relationships are expressed, and how the object moves later.
For example, a customer form may appear to be only fields such as customer name, contact person, phone number, source, and owner. But behind it is a customer object. This object may relate to follow-up records, contracts, orders, payments, and projects. It may also participate in CRM workflows, sales dashboards, and customer segmentation analysis.
If a form is treated only as a page, every capability that comes later becomes fragmented. If a form is treated as the entry point to a model, workflows, permissions, reports, and AI can continue to expand around the same business object.
Core objects in the first design
When designing the initial form engine, I first split the form system into several core objects.
The first is the application. An application is the container for a business system, such as CRM, project management, procurement management, or equipment management.
The second is the data table. A data table carries one type of business object, such as customer, contract, order, task, or equipment.
The third is the field. A field describes an attribute of a business object, such as text, number, date, option, user, department, attachment, or related data.
The fourth is the view. A view decides how data is presented, such as table view, detail page, form page, kanban, calendar, or dashboard.
The fifth is the action. An action decides what users can do with data, such as create, edit, delete, submit for approval, import, export, or trigger automation.
After this split, a form is no longer an isolated page. It becomes one interaction shape assembled from data tables, fields, views, and actions.
Field design is the first hard problem
The easiest thing to underestimate in a form engine is field design.
A field may look like a type selector, but different fields carry completely different data structures and business semantics. Text fields can support fuzzy search. Number fields can be aggregated. Date fields can support time filtering. User fields can connect to the organization structure. Relationship fields can establish links between business objects.
So fields cannot serve only data entry. They must also support querying, statistics, permissions, workflow conditions, and AI understanding.
For example, if an "owner" field is only plain text, the system does not know who that person is. It cannot evaluate permissions, send notifications, or create user-based statistics. But if it is a user field, it can connect to organizations, roles, data permissions, notifications, and workflow approvers.
That is the value of field type design: it stores business meaning inside the platform model.
The second hard problem is balancing dynamism and stability
A low-code platform requires fields to be dynamically configurable, but enterprise systems also require data to be stable and reliable.
There is a very real tension here. If everything is too dynamic, the system is flexible, but queries, analytics, performance, and maintenance all become more complex. If everything is too fixed, the system is stable, but every business change requires new development.
So the core of form-engine design is not to pursue absolute dynamism. It is to find the boundary between dynamism and stability.
Which things should users be able to configure? Which things should the platform fix in place? Which capabilities can be metadata-driven? Which areas must retain engineering constraints? These questions matter more than whether something can be dragged on a canvas.
Forms and permissions must be considered together
Many systems start by designing forms only around fields and pages, leaving permissions for later.
But in enterprise systems, permissions are not an add-on. They should enter form design from the beginning.
For the same form, different roles may see different fields. For the same field, some people may edit it while others can only read it. For the same record, a department lead, creator, collaborator, and administrator may all have different permissions.
If the form engine does not leave room for field-level permissions, record-level permissions, and action permissions, connecting real business scenarios later becomes painful.
So in INFORMAT, I want forms to connect naturally to the permission system instead of being isolated generated pages. Form fields, data scopes, and operation buttons should all be controllable by permission rules.
Forms and workflows cannot be separated
In enterprises, many forms are not simply saved after completion. They enter a business process.
Purchase requests need approval. Contracts need legal review. Project initiation needs owner confirmation. Expense reimbursements need finance processing.
This means the form engine must work with the workflow engine. Forms collect and display data; workflows move that data across different nodes.
More importantly, each workflow node may have its own form permissions. Which fields can the initiator fill in? Which fields can the approver modify? What can a copied recipient only view?
So the form engine, as I understand it, is not only a data-entry page generator. It is the carrier layer for business data inside workflows.
Form data must also be understood by AI
When building a form engine now, AI has to be considered.
If AI is expected to help users generate forms, analyze data, configure workflows, and answer business questions, then the form model must be clear enough.
AI needs to know what each field means, which fields represent users, which represent amounts, which represent status, which represent time, and which relate to other business objects.
If a form is only a set of input boxes without semantics, AI will have a hard time truly understanding the business. It may generate a page, but it will struggle to participate safely and accurately in enterprise processes.
So AI plus low-code is not about adding a chat box outside the form. It is about making the platform's internal models, fields, relationships, and permissions understandable and callable by AI.
What matters most in the initial design
If I am only building the initial design, I would not try to finish every advanced capability at once.
There are three things I care about most.
First, the model must be clear. The relationships between applications, data tables, fields, views, and actions must be stable so the platform can keep expanding later.
Second, fields must have semantics. Field types cannot be only frontend controls. They must support querying, analytics, permissions, workflows, and AI.
Third, the boundaries must be prepared. Forms should be able to connect to permissions, workflows, automation, and reports, even if the first implementation does not push every capability to the extreme. The key is that the architecture must not block those paths.
For platform products, the biggest risk is not that the initial feature set is small. It is that the initial model is wrong. Missing features can be added. A wrong model makes every later step heavier.
Some mistakes I ran into
I also ran into plenty of mistakes while building the form engine.
The first mistake was paying attention to the interface too early. Drag-and-drop experience, control styling, and layout details are exciting, but if the underlying model is unclear, the prettier the interface is, the more painful later changes become.
The second mistake was underestimating field dependencies and validation. In real business, fields are not isolated. Selecting a customer may bring out contact people. Selecting a department may restrict the user range. An amount above a threshold may trigger approval. These all require rule capabilities inside the form.
The third mistake was treating lists and forms separately. Many business scenarios do not only need data entry. They also need filtering, sorting, batch operations, import and export, and aggregation. Forms and lists are really two views over the same data model.
The fourth mistake was adding permissions late. If permissions do not enter the model at the beginning, adding field-level permissions, data permissions, and workflow-node permissions later affects almost everything.
The direction
The form engine is the most basic module in a low-code platform, but basic does not mean simple.
It connects the most central question in enterprise business systems: how to settle business objects, business data, and business rules into the platform.
In my view, a good form engine should not only help users build pages faster. It should help companies define their business more clearly.
That is also the direction INFORMAT keeps moving toward: starting from forms, but not stopping at forms; starting from low-code, but ultimately serving enterprise digitization and intelligence.
In the next post, I want to continue with the data model. Forms are only the entry point. What really supports the platform's long-term evolution is the data model behind the forms.
Top comments (0)