# How Should a Low-Code Platform Design Its Data Model? > Source: > Published: 2026-08-04 23:00:48+00:00 In the previous post about the form engine, I mentioned one judgment: A form is not a page. It is the entry point into a business model. Following that thought leads to a deeper question inside low-code platforms: how should the data model be designed? When many people think about low-code platforms, they first see visible capabilities such as forms, pages, workflows, reports, and dashboards. But what really determines how far a platform can go is often not how quickly pages can be assembled, but whether the underlying data model can carry complex business. If the data model is weak, forms become isolated pages. If the data model is messy, workflows, permissions, reports, and AI all become difficult to build. So in this post, I want to write about data-model design in INFORMAT. When many systems start designing a data model, it is easy to understand it as "create a few tables and add a few fields." For CRM, create customer, contact, and follow-up tables. For project management, create project, task, and member tables. For inventory and sales, create product, inventory, purchase order, and sales order tables. These are certainly part of the data model, but they are far from enough for a low-code platform. The problem a low-code platform faces is that these tables and fields are not hard-coded once by developers. Users must be able to dynamically create, adjust, and extend them inside the platform. That brings a new requirement: The platform must store business data, and it must also store the data that describes business data. That is metadata. A "customer table" is itself a piece of configuration. Fields such as customer name, customer level, owner, and contact list are also configuration. Field type, display style, validation rule, permission rule, and relationship are configuration too. So the data model of a low-code platform has two layers: The first layer is the platform's own metadata model. The second layer is the business data model created by users. The former decides the platform's capability boundary. The latter carries the specific business of each company. When designing the data model, I first ask one question: What objects truly exist in the business? A customer is an object. A contract is an object. An order is an object. A project is an object. A task is an object. Equipment is an object. An approval request is also an object. These objects are not pages, and they are not just collections of fields. They are things in enterprise business that can be identified, moved, related, and measured. If the design starts only from pages, the system becomes "what fields does this page have?" If the design starts from objects, the system becomes "what attributes, relationships, and behaviors does this business object have?" These two ways of thinking are very different. For example, a customer object is not only fields such as customer name, phone number, and address. It may also have an owner, customer level, lifecycle stage, follow-up records, contacts, contracts, orders, payments, and service tickets. When we treat the customer as a business object, workflows, permissions, reports, and AI analysis all gain a shared foundation. Field design is not simply choosing text, number, or date. The truly important part of a field is whether it can express business semantics. Take the same "owner" field. If it is designed as plain text, the system only knows that there are a few characters. But if it is designed as a user field, the system can know: That is the value of field semantics. Field types in a low-code platform cannot serve only page display. They must also support data queries, permission checks, workflow conditions, automation triggers, report statistics, and AI understanding. For example, date fields can support time filtering and due-date reminders. Amount fields can support aggregation and threshold checks. Status fields can support workflow transitions and kanban grouping. Relationship fields can establish relationships between business objects. User fields can connect to the organization structure and permission system. The more semantic the field types are, the easier it is for the platform's later capabilities to grow. Many business systems are complex not because there are many fields, but because relationships are complex. A customer and contacts are one-to-many. A customer and contracts are one-to-many. A contract and orders may be one-to-many. A project and tasks are one-to-many. Tasks and members may be many-to-many. A purchase order and product line items are master-detail. If these relationships are not expressed well, the system can only become a pile of isolated data tables. Isolated data tables quickly run into problems: So relationships must be taken seriously in the data model. In a low-code platform, relationships are not only database-level relationships. They also affect page display, permission control, data linkage, workflow conditions, and report analysis. A good relationship field should not merely store an ID. It should let the platform know what relationship exists between two business objects and how that relationship can be used. Low-code platforms naturally pursue dynamism. Users can dynamically create tables, add fields, adjust views, and configure workflows. But enterprise systems cannot be infinitely dynamic. The system also has to consider performance, querying, analytics, permissions, security, upgrades, and maintenance. This creates a long-term tension: If the model is too dynamic, the platform is flexible, but the underlying system becomes increasingly complex. If the model is too fixed, the platform is stable, but it loses the value of low-code when the business changes. So the most important part of data-model design is not absolute flexibility. It is drawing the boundary. Which capabilities should users configure? Which capabilities should the platform fix in place? Which changes can be driven by metadata? Which changes must go through development extensions? For example, fields, views, form layouts, and basic validation are suitable as configuration. But data permissions, system audit, underlying storage, transaction boundaries, and performance indexes cannot be handed over entirely to arbitrary user configuration. The platform should give users freedom, but it should also help them hold system boundaries. In enterprise systems, the data model and permission model cannot be separated. Who can view which data? Who can edit which fields? Who can delete records? Who can export data? Who can view related objects? These questions all depend on the data model. If the data model does not have clear boundaries around objects, fields, and relationships, permissions can only be hard-coded. Once permissions are hard-coded, the flexibility of the low-code platform declines. So in a system like INFORMAT, the data model must leave room for permissions. Data tables can correspond to data permissions. Fields can correspond to field permissions. Actions can correspond to operation permissions. Relationships can affect visibility scope. Workflow nodes can change whether certain fields are editable. From this perspective, permissions are not a late add-on. They are a foundational capability that must be considered during data-model design. The workflow engine also depends on the data model. A purchase request workflow moves the purchase request business object. A contract approval workflow moves the contract business object. A project initiation workflow moves the project business object. Workflows do not run in the air. They always happen around a certain type of business data. Condition checks on workflow nodes also depend on fields. For example, an amount greater than 100,000 goes to general manager approval. A contract type marked as strategic customer goes through special review. Different applicant departments take different approval paths. Different current owners lead to different task assignments. All of this requires the data model to be read reliably by the workflow engine. If fields are only page controls, workflows can hardly understand them. If fields have clear types and semantics, workflow conditions can become configurable, visual, and maintainable. After many enterprise systems go online, report requirements appear almost immediately. Customer count by source. Contract amount by month. Project tasks by owner. Inventory quantity by warehouse. Sales by region. These look like reporting problems, but they are data-model problems first. If fields do not have types, amounts cannot be aggregated correctly. If date fields are not standardized, trend charts will not work well. If relationships are unclear, cross-object statistics become painful. If status fields are arbitrary text, future kanban views and statistics become messy. So reporting should not be left until the end. When designing the data model, the platform must already consider how the data will later be filtered, grouped, aggregated, and analyzed. When designing a low-code platform now, AI must be part of the consideration. If AI wants to truly enter enterprise business, it cannot rely only on a chat window. It needs to understand business objects, field meanings, relationship structures, permission scopes, and executable actions. For example, when a user asks: "Help me analyze the sources of customers won in the last three months." AI needs to know what a customer is, what won means, which field represents source, and which field represents win time. When a user says: "Add a customer level field to the customer table." AI needs to know where the customer table is, what field type should be used, whether options are needed, and whether views and permissions are affected. When a user says: "When this contract amount exceeds 100,000, send it to the general manager for approval." AI needs to understand the contract object, amount field, workflow condition, and approver rule. All of these capabilities depend on a clear data model. Without a data model, AI can only generate content that looks plausible. With a data model, AI has a chance to become an assistant that can truly participate in building and operating business systems. If I focus only on the initial design, I would not try to finish every complex capability at once. I care more about a few fundamentals. First, business objects must be clear. The platform must know what business object each data table represents, not only that it is a table. Second, field types must have semantics. Fields cannot be only input controls. They must be usable by querying, permissions, workflows, reports, and AI. Third, relationships must be expressible. At minimum, the platform should support common scenarios such as one-to-one, one-to-many, master-detail, related records, and related aggregation. Fourth, the model must be able to evolve. When users later add fields, adjust relationships, or modify views, the system should not break easily. Fifth, the platform must hold boundaries. Low-code is not infinite freedom. It is allowing business to change quickly within controlled boundaries. There are several common mistakes in data-model design. The first mistake is treating fields as page controls. This is fast early on, but when workflows, permissions, statistics, and AI arrive later, the fields lack semantics. The second mistake is underestimating relationships. Enterprise business is rarely single-table business. The relationships between customers, contracts, orders, projects, and tasks are the real source of system complexity. The third mistake is being overly dynamic. Letting users configure everything looks powerful in the short term, but it makes the platform uncontrollable in the long term. The fourth mistake is adding permissions late. If permissions do not enter the data model, field-level permissions, data scopes, and workflow-node permissions all become heavy later. The fifth mistake is leaving no semantics for AI. If fields, relationships, and actions are only technical configuration, AI will struggle to understand business meaning. The data model is one of the deepest and easiest-to-ignore capabilities in a low-code platform. Forms, workflows, permissions, reports, and AI look like different modules, but they all return to the same question: Does the platform have a clear, stable, and evolvable data model? In my view, the real value of a low-code platform is not that users write a few fewer lines of code. It is that enterprise business can be abstracted into models that continue to evolve. Forms are the entry point. The data model is the foundation. Workflows, permissions, reports, and AI are capabilities that continue to grow from that foundation. This is something I have become increasingly certain of while building INFORMAT: Platform products cannot only pursue more features. They must get the underlying model right. When the model is clear, features have roots. In the next post, I want to write about the permission system. The data model defines business objects, while the permission system decides how those objects can be safely viewed, operated on, and moved through the enterprise organization.