{"slug": "how-should-a-low-code-platform-design-its-data-model", "title": "How Should a Low-Code Platform Design Its Data Model?", "summary": "A developer from INFORMAT discusses the design of data models in low-code platforms, emphasizing the importance of metadata and treating business entities as objects rather than pages. The post argues that field semantics, not just types, are crucial for enabling workflows, permissions, reports, and AI capabilities.", "body_md": "In the previous post about the form engine, I mentioned one judgment:\n\nA form is not a page. It is the entry point into a business model.\n\nFollowing that thought leads to a deeper question inside low-code platforms: how should the data model be designed?\n\nWhen 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.\n\nIf the data model is weak, forms become isolated pages.\n\nIf the data model is messy, workflows, permissions, reports, and AI all become difficult to build.\n\nSo in this post, I want to write about data-model design in INFORMAT.\n\nWhen many systems start designing a data model, it is easy to understand it as \"create a few tables and add a few fields.\"\n\nFor CRM, create customer, contact, and follow-up tables.\n\nFor project management, create project, task, and member tables.\n\nFor inventory and sales, create product, inventory, purchase order, and sales order tables.\n\nThese are certainly part of the data model, but they are far from enough for a low-code platform.\n\nThe 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.\n\nThat brings a new requirement:\n\nThe platform must store business data, and it must also store the data that describes business data.\n\nThat is metadata.\n\nA \"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.\n\nSo the data model of a low-code platform has two layers:\n\nThe first layer is the platform's own metadata model.\n\nThe second layer is the business data model created by users.\n\nThe former decides the platform's capability boundary. The latter carries the specific business of each company.\n\nWhen designing the data model, I first ask one question:\n\nWhat objects truly exist in the business?\n\nA customer is an object.\n\nA contract is an object.\n\nAn order is an object.\n\nA project is an object.\n\nA task is an object.\n\nEquipment is an object.\n\nAn approval request is also an object.\n\nThese 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.\n\nIf the design starts only from pages, the system becomes \"what fields does this page have?\"\n\nIf the design starts from objects, the system becomes \"what attributes, relationships, and behaviors does this business object have?\"\n\nThese two ways of thinking are very different.\n\nFor 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.\n\nWhen we treat the customer as a business object, workflows, permissions, reports, and AI analysis all gain a shared foundation.\n\nField design is not simply choosing text, number, or date.\n\nThe truly important part of a field is whether it can express business semantics.\n\nTake the same \"owner\" field. If it is designed as plain text, the system only knows that there are a few characters.\n\nBut if it is designed as a user field, the system can know:\n\nThat is the value of field semantics.\n\nField 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.\n\nFor example, date fields can support time filtering and due-date reminders.\n\nAmount fields can support aggregation and threshold checks.\n\nStatus fields can support workflow transitions and kanban grouping.\n\nRelationship fields can establish relationships between business objects.\n\nUser fields can connect to the organization structure and permission system.\n\nThe more semantic the field types are, the easier it is for the platform's later capabilities to grow.\n\nMany business systems are complex not because there are many fields, but because relationships are complex.\n\nA customer and contacts are one-to-many.\n\nA customer and contracts are one-to-many.\n\nA contract and orders may be one-to-many.\n\nA project and tasks are one-to-many.\n\nTasks and members may be many-to-many.\n\nA purchase order and product line items are master-detail.\n\nIf these relationships are not expressed well, the system can only become a pile of isolated data tables.\n\nIsolated data tables quickly run into problems:\n\nSo relationships must be taken seriously in the data model.\n\nIn 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.\n\nA 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.\n\nLow-code platforms naturally pursue dynamism.\n\nUsers can dynamically create tables, add fields, adjust views, and configure workflows.\n\nBut enterprise systems cannot be infinitely dynamic.\n\nThe system also has to consider performance, querying, analytics, permissions, security, upgrades, and maintenance.\n\nThis creates a long-term tension:\n\nIf the model is too dynamic, the platform is flexible, but the underlying system becomes increasingly complex.\n\nIf the model is too fixed, the platform is stable, but it loses the value of low-code when the business changes.\n\nSo the most important part of data-model design is not absolute flexibility. It is drawing the boundary.\n\nWhich capabilities should users configure?\n\nWhich capabilities should the platform fix in place?\n\nWhich changes can be driven by metadata?\n\nWhich changes must go through development extensions?\n\nFor example, fields, views, form layouts, and basic validation are suitable as configuration.\n\nBut data permissions, system audit, underlying storage, transaction boundaries, and performance indexes cannot be handed over entirely to arbitrary user configuration.\n\nThe platform should give users freedom, but it should also help them hold system boundaries.\n\nIn enterprise systems, the data model and permission model cannot be separated.\n\nWho can view which data?\n\nWho can edit which fields?\n\nWho can delete records?\n\nWho can export data?\n\nWho can view related objects?\n\nThese questions all depend on the data model.\n\nIf the data model does not have clear boundaries around objects, fields, and relationships, permissions can only be hard-coded.\n\nOnce permissions are hard-coded, the flexibility of the low-code platform declines.\n\nSo in a system like INFORMAT, the data model must leave room for permissions.\n\nData tables can correspond to data permissions.\n\nFields can correspond to field permissions.\n\nActions can correspond to operation permissions.\n\nRelationships can affect visibility scope.\n\nWorkflow nodes can change whether certain fields are editable.\n\nFrom this perspective, permissions are not a late add-on. They are a foundational capability that must be considered during data-model design.\n\nThe workflow engine also depends on the data model.\n\nA purchase request workflow moves the purchase request business object.\n\nA contract approval workflow moves the contract business object.\n\nA project initiation workflow moves the project business object.\n\nWorkflows do not run in the air. They always happen around a certain type of business data.\n\nCondition checks on workflow nodes also depend on fields.\n\nFor example, an amount greater than 100,000 goes to general manager approval.\n\nA contract type marked as strategic customer goes through special review.\n\nDifferent applicant departments take different approval paths.\n\nDifferent current owners lead to different task assignments.\n\nAll of this requires the data model to be read reliably by the workflow engine.\n\nIf fields are only page controls, workflows can hardly understand them.\n\nIf fields have clear types and semantics, workflow conditions can become configurable, visual, and maintainable.\n\nAfter many enterprise systems go online, report requirements appear almost immediately.\n\nCustomer count by source.\n\nContract amount by month.\n\nProject tasks by owner.\n\nInventory quantity by warehouse.\n\nSales by region.\n\nThese look like reporting problems, but they are data-model problems first.\n\nIf fields do not have types, amounts cannot be aggregated correctly.\n\nIf date fields are not standardized, trend charts will not work well.\n\nIf relationships are unclear, cross-object statistics become painful.\n\nIf status fields are arbitrary text, future kanban views and statistics become messy.\n\nSo reporting should not be left until the end.\n\nWhen designing the data model, the platform must already consider how the data will later be filtered, grouped, aggregated, and analyzed.\n\nWhen designing a low-code platform now, AI must be part of the consideration.\n\nIf AI wants to truly enter enterprise business, it cannot rely only on a chat window.\n\nIt needs to understand business objects, field meanings, relationship structures, permission scopes, and executable actions.\n\nFor example, when a user asks:\n\n\"Help me analyze the sources of customers won in the last three months.\"\n\nAI needs to know what a customer is, what won means, which field represents source, and which field represents win time.\n\nWhen a user says:\n\n\"Add a customer level field to the customer table.\"\n\nAI 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.\n\nWhen a user says:\n\n\"When this contract amount exceeds 100,000, send it to the general manager for approval.\"\n\nAI needs to understand the contract object, amount field, workflow condition, and approver rule.\n\nAll of these capabilities depend on a clear data model.\n\nWithout a data model, AI can only generate content that looks plausible.\n\nWith a data model, AI has a chance to become an assistant that can truly participate in building and operating business systems.\n\nIf I focus only on the initial design, I would not try to finish every complex capability at once.\n\nI care more about a few fundamentals.\n\nFirst, business objects must be clear.\n\nThe platform must know what business object each data table represents, not only that it is a table.\n\nSecond, field types must have semantics.\n\nFields cannot be only input controls. They must be usable by querying, permissions, workflows, reports, and AI.\n\nThird, relationships must be expressible.\n\nAt minimum, the platform should support common scenarios such as one-to-one, one-to-many, master-detail, related records, and related aggregation.\n\nFourth, the model must be able to evolve.\n\nWhen users later add fields, adjust relationships, or modify views, the system should not break easily.\n\nFifth, the platform must hold boundaries.\n\nLow-code is not infinite freedom. It is allowing business to change quickly within controlled boundaries.\n\nThere are several common mistakes in data-model design.\n\nThe first mistake is treating fields as page controls.\n\nThis is fast early on, but when workflows, permissions, statistics, and AI arrive later, the fields lack semantics.\n\nThe second mistake is underestimating relationships.\n\nEnterprise business is rarely single-table business. The relationships between customers, contracts, orders, projects, and tasks are the real source of system complexity.\n\nThe third mistake is being overly dynamic.\n\nLetting users configure everything looks powerful in the short term, but it makes the platform uncontrollable in the long term.\n\nThe fourth mistake is adding permissions late.\n\nIf permissions do not enter the data model, field-level permissions, data scopes, and workflow-node permissions all become heavy later.\n\nThe fifth mistake is leaving no semantics for AI.\n\nIf fields, relationships, and actions are only technical configuration, AI will struggle to understand business meaning.\n\nThe data model is one of the deepest and easiest-to-ignore capabilities in a low-code platform.\n\nForms, workflows, permissions, reports, and AI look like different modules, but they all return to the same question:\n\nDoes the platform have a clear, stable, and evolvable data model?\n\nIn 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.\n\nForms are the entry point.\n\nThe data model is the foundation.\n\nWorkflows, permissions, reports, and AI are capabilities that continue to grow from that foundation.\n\nThis is something I have become increasingly certain of while building INFORMAT:\n\nPlatform products cannot only pursue more features. They must get the underlying model right.\n\nWhen the model is clear, features have roots.\n\nIn the next post, I want to write about the permission system.\n\nThe 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.", "url": "https://wpnews.pro/news/how-should-a-low-code-platform-design-its-data-model", "canonical_source": "https://dev.to/informat/how-should-a-low-code-platform-design-its-data-model-j6n", "published_at": "2026-08-04 23:00:48+00:00", "updated_at": "2026-08-04 23:40:45.090836+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["INFORMAT"], "alternates": {"html": "https://wpnews.pro/news/how-should-a-low-code-platform-design-its-data-model", "markdown": "https://wpnews.pro/news/how-should-a-low-code-platform-design-its-data-model.md", "text": "https://wpnews.pro/news/how-should-a-low-code-platform-design-its-data-model.txt", "jsonld": "https://wpnews.pro/news/how-should-a-low-code-platform-design-its-data-model.jsonld"}}