DEV Community: informat

How Should Scripting Work in a Low-Code Platform?

informat — Mon, 10 Aug 2026 13:41:58 +0000

In the previous post about automation, I ended with a question:

Once automation connects business actions, where should the complex logic live?

The answer is scripts.

Scripting is easily misunderstood in a low-code platform.

Some people ask why a low-code product needs scripts at all. Others worry that adding scripts turns low-code back into traditional software development.

My view is that scripting is not the opposite of low-code.

It is the controlled escape hatch that a low-code platform needs when it encounters genuinely complex business requirements.

The important questions are not whether scripts exist. They are where scripts run, how they are invoked, which boundaries apply, and whether the platform can govern their lifecycle.

Without boundaries, scripts pull the platform back toward scattered custom code. Without scripts, the platform becomes rigid when it meets real enterprise complexity.

A scripting system should not let users write arbitrary code anywhere. It should provide a controlled runtime for logic that cannot be expressed clearly through configuration.

Why low-code platforms need scripts

Low-code configuration can handle a large share of common requirements:

Field validation
Conditional form behavior
Approval workflows
Permission control
Automation orchestration
Data queries and updates

The platform should provide these capabilities directly whenever possible.

Enterprise applications still contain logic that is difficult to express elegantly as configuration.

Examples include complex quotation calculations, signing requests to external APIs, cleaning data across several tables, generating identifiers from historical rules, transforming imported data, validating purchase lines against maximum material prices, or assigning an owner based on industry, region, customer level, and sales workload.

Trying to convert every one of these cases into visual configuration makes the configuration system increasingly complicated. Each new option requires UI, expressions, validation, compatibility rules, boundaries, and performance considerations.

Eventually, the platform can reach an awkward outcome: in an attempt to avoid code, it creates a configuration language that is harder to understand than code.

That is not the goal of low-code.

Scripts should carry logic that the configuration system would otherwise express poorly.

Scripts should not swallow the entire business process

Once scripting is available, the easiest mistake is to put everything inside it.

Consider the actions that follow customer creation. One script could check for duplicates, assign an owner, update the customer, send notifications, call external services, and write logs.

This is fast in the short term. A developer can open the editor and implement the complete path in one place.

It is painful in the long term.

Business users cannot see the process. Implementation teams have difficulty troubleshooting it. The automation log only says that a script ran. Permission boundaries are easier to bypass. Even changing a notification rule requires someone to search through code.

I prefer a clear division of responsibility:

Automation handles orchestration.

Scripts handle complex logic.

An automation can query data, invoke a script to calculate a result, then use that result to update records, send notifications, and return a response.

A script should not consume the entire business process. It should behave like a calculation, validation, or transformation node inside automation.

This preserves the flexibility of code without losing the visual governance of automation.

Server-side and client-side scripts need different boundaries

The first distinction in a scripting system is where the code runs.

Some scripts belong on the server. Others belong in the client. They solve different problems and require different security models.

Server-side scripts are suited to business logic such as querying and writing data, calling external services, performing complex calculations, processing batches, and generating structured results.

They run in the platform backend, where they can access a richer business context and where permissions, logging, timeouts, and error handling can be enforced consistently.

For INFORMAT, JavaScript is the practical language for server-side scripting.

It is familiar to frontend and full-stack developers, which reduces the learning curve. Most enterprise scripts are not large applications. They implement a business rule, data transformation, or integration call, and JavaScript is flexible and lightweight enough for those jobs.

Server-side scripts access platform functions through the informat object. Their runtime state is isolated by application so that one application's script context cannot leak casually into another.

This makes server-side scripting especially useful in two areas:

Business processing behind APIs
Complex calculations that become too cumbersome in visual automation

The point is not to replace automation. It is to give automation an efficient execution layer when a step needs to calculate something, query something, transform data, sign a request, or assemble a complex result.

Client-side scripts are better suited to interface behavior.

A form may calculate one field immediately after another field changes. A button may update local page state. A custom control may need lightweight logic. The interface may display instant feedback based on user input.

These actions are close to the user experience and should not always require a round trip to the server.

Client-side scripting still needs restraint. It must not become a permission backdoor. A page script cannot be allowed to read data that the user cannot access or modify protected fields through a direct request.

Client scripts should handle interaction and lightweight calculations. Actions that affect persistent data or business state should return to server-side scripts, automation, or governed platform actions.

The `informat` object is the capability gateway

A business script cannot be only bare JavaScript.

The language alone can manipulate strings, arrays, and objects, but it cannot participate in enterprise operations. Scripts need controlled access to platform capabilities.

The informat object is that gateway. It exposes platform, utility, and integration functions to scripts through a consistent interface.

Its capabilities can be viewed in several groups.

The first group covers platform business objects, including applications, companies, departments, designers, and BPMN workflows. These APIs give a script access to the relevant application, organization, and process context.

The second group covers data and integration, including data sources, JDBC, HTTP, FTP, and LDAP. These functions let scripts communicate with external systems and existing enterprise infrastructure.

The third group covers files and documents, including files, CSV, Excel, and PDF. Importing, exporting, handling attachments, and generating documents are routine parts of enterprise digital operations. They should not require every team to rebuild the same foundation.

The fourth group contains general utilities and runtime support, such as dates, console logging, encoding, and email. These capabilities look ordinary, but scripts use them constantly.

The fifth group provides AI capabilities through AI agents.

This opens interesting possibilities. Scripts can use AI for text generation, content extraction, data explanation, or business suggestions instead of limiting themselves to deterministic calculations.

AI output requires stricter boundaries. It should not be written directly into critical business data without validation. A safer design lets AI generate a candidate result, then uses scripts or automation to validate its structure and business constraints.

In this model, scripting becomes more than a place to write code. It is a programmatic gateway to platform capabilities.

That role differs from visual automation. Automation emphasizes visible process orchestration. Scripts emphasize logic and function calls. The two should cooperate instead of competing for the same responsibility.

Code snippets belong inside local automation steps

Automation also needs a local form of scripting. I think of this as a code snippet rather than an independent script module.

A code snippet handles a specific piece of logic inside one automation step.

Suppose an automation loops over purchase order lines and evaluates whether each material exceeds its maximum purchase price. A simple comparison belongs in a visual condition.

But the rule may become more complicated:

Different suppliers use different pricing policies.
Material categories allow different variance percentages.
Purchase types use different approval thresholds.
Historical pricing must use the latest valid quotation.

Encoding all of this in visual conditions makes the automation difficult to read. A code snippet can calculate the result and return it to the automation branch.

The value of a code snippet is that it keeps the canvas readable, gives complex calculations a clear home, and leaves the overall execution path visible in automation.

This is the most natural relationship between scripts and automation.

Automation decides what happens first, what happens next, and what should occur after failure.

The code snippet decides how one particular step is calculated.

Script functions should be reusable

Logic used in one place can remain a code snippet. Logic shared by several automations, buttons, or listeners should become a script function.

Common examples include:

Generating a business identifier
Calculating a quotation
Validating inventory
Parsing an external API response
Building notification content
Converting imported data into a standard structure

These functions should not be copied into every automation. They should be reusable platform assets.

A script function needs an explicit contract:

What are its inputs?
What does it return?
Does it modify data?
Does it call an external service?
What happens when it fails?
Does it depend on the current user?
Does it depend on the current application?

Once a function is reused, its author cannot be the only person who understands how to call it. The platform should make its parameters, return value, description, and effects visible to callers.

This resembles ordinary software engineering, but there is an additional constraint in a low-code platform: the people using script functions may not be full-time developers.

Readability matters more than cleverness.

Permission boundaries cannot depend on author discipline

Permissions are the most sensitive part of scripting because scripts are highly flexible.

Without runtime controls, scripts can bypass the platform's existing boundaries. A script may retrieve a field that the current user cannot view, modify an approved amount, or query company-wide data for a user limited to one department.

The platform cannot rely on every script author to avoid these mistakes voluntarily. It must enforce the boundaries at runtime.

Data reads must pass permission evaluation.

Data writes must have an explicit execution identity.

External calls must record their source.

Scripts running as the system require stronger auditing.

Scripts invoked by automation must inherit the relevant automation permission boundaries.

System identity is the difficult case. Some background work genuinely needs it, including nightly synchronization, repairing historical records, and receiving status updates from external systems.

But system identity cannot mean unlimited authority. It needs an authorization scope that defines which applications it can access, which tables it can read or write, which scripts it can call, and which external resources it can reach.

The more capable the scripting runtime becomes, the more important these boundaries become.

Logging and errors are first-class capabilities

Once scripts enter real business operations, logging is not optional.

For every execution, the platform should be able to answer:

Who triggered it?
Where was it triggered?
Which parameters were passed?
Which script version ran?
How long did it take?
What did it return?
Did it throw an exception?
What was the stack trace?
Which data did it affect?

When automation invokes a script, the two execution records should be linked. An operator should be able to open the script step from an automation run and inspect its inputs, output, duration, and exception details.

That is what makes scripting governable.

Error handling also needs a unified model.

After a script fails, should automation continue or terminate? Should the script return a structured error or throw an exception? Should the failure be shown to the user or recorded only in backend logs?

These decisions should not be improvised in every script. The runtime needs consistent error behavior so callers can handle failures predictably.

Script management is more than a code editor

When people imagine script management, they often begin with an editor: syntax highlighting, a save button, and a run button.

That is only the visible surface.

The real challenge is managing the script lifecycle.

How should scripts be organized and searched? How are they published into the runtime? Can they synchronize with a Git repository? Which automations depend on a changed function? Can a new version be rolled out gradually? Can it be rolled back? Who sees failures? Which NPM packages does a script depend on? Which platform objects does it call? Does it introduce a permission risk?

Repository URL, branch, synchronization path, and authentication may sound like developer concerns. Once an application contains many scripts, however, they determine whether teams can collaborate, review changes, recover from mistakes, and synchronize environments.

Scripts should not exist only as text stored in a database. They need a management model closer to software engineering.

The editor is where a person writes a script. Script management governs everything from creation and dependency tracking to publishing, execution, auditing, and rollback.

If the lifecycle is not managed, every additional script makes the platform harder to maintain.

What matters in the initial version

I would not begin by building a complete browser-based IDE. I would first clarify the runtime model and governance boundaries.

First, distinguish server-side and client-side scripts. Server scripts carry business logic; client scripts handle interface interactions and lightweight calculations.

Second, support reusable script functions with clear inputs, return values, descriptions, and invocation contracts.

Third, support code snippets inside automation so local complex calculations do not consume the entire process.

Fourth, establish a unified execution context containing the current user, current application, invocation source, input parameters, and execution instance.

Fifth, keep permissions restrictive by default. Data access, platform functions, and external resources must remain behind platform boundaries.

Sixth, expose capabilities through allowlists. NPM packages and Java objects should not be opened without control. Begin with a small, stable surface and expand deliberately.

Seventh, implement logging and a unified error model early. Every execution must be traceable across automation, listeners, buttons, and other callers.

Eighth, provide version management. At minimum, the platform should record who changed a script, what changed, when it became active, and whether it can be rolled back.

Only after these foundations are stable would I invest heavily in the editor experience.

A beautiful editor cannot compensate for an ungoverned runtime.

The direction

Scripting is not an exception inside a low-code platform. It is a necessary capability for real business complexity.

But scripts must be placed correctly.

They do not replace forms, workflows, automation, or the permission system.

They carry complex logic that configuration cannot express clearly.

Automation handles orchestration.

Scripts handle calculations, validation, transformation, and limited complex processing.

The platform handles permissions, logs, runtime limits, and lifecycle management.

With those boundaries, scripting does not pull low-code back toward uncontrolled customization. It makes the platform capable of addressing the business cases that visual configuration alone cannot handle.

Learn more about INFORMAT.

Automation Is Not a Scheduled Task. It Is Business Action Orchestration

informat — Sun, 09 Aug 2026 14:05:12 +0000

In the previous post about plugin mechanisms, I made one distinction clear:

Plugins provide entry points.

Listeners are event entry points.

APIs are external entry points.

Custom controls are interface entry points.

Automation should organize the business actions that follow.

So this post continues with automation.

In INFORMAT, automation is not simply a scheduled task. A more accurate description is a visual programming environment.

It uses variables, flow control, and automation steps to organize business actions into a program that can be invoked, accept parameters, and return a result.

This positioning matters. If automation is understood only as "run a task at a particular time," its role in a low-code platform is severely underestimated.

Enterprise automation is more often about reliably completing a chain of actions after a business event occurs.

A new record may need additional fields populated automatically.

An approved process may need to generate a project.

A button may open a form so the user can provide additional information before execution continues.

An external system may call an automation over HTTP and receive the processing result.

None of these scenarios is primarily a scheduled task. They are business action orchestration.

Automation should behave like a small program

When I first thought about an automation module, I did not imagine a task list.

A task list can express when an action should run. Enterprise processes need much more.

An automation often needs input parameters. It needs variables, conditional logic, and loops over collections. It may query or update tables, invoke scripts, and return a result. In some cases, it must pause halfway through, ask a user to complete a form, and then resume.

Automation is therefore closer to a small program.

The difference is that developers do not have to write the whole program from scratch. They assemble it from steps on a visual canvas.

This makes the business path visible.

Who triggered the automation?

Which parameters were provided?

Which conditional branch ran?

Which steps were executed?

What result was returned?

When all of this is hidden inside code, troubleshooting is expensive. When it is expressed on an automation canvas, both implementation teams and developers can understand the execution path.

Input parameters are the automation entry point

An automation needs input parameters if it is going to be called from multiple places.

A listener can pass the current record.

A button can pass the current page context.

An external system can pass request parameters through an HTTP call.

Another automation can pass the result of an earlier step.

Input parameters turn an automation from an isolated task into a reusable capability.

Consider an automation that generates customer numbers. It may be called by a listener when a customer is created, by an import automation, or by an external customer synchronization. With a clear input contract, the same automation can serve every entry point.

There is an important design detail here: the selected parameter type mainly improves expression suggestions at design time. The runtime does not strictly validate the type of every incoming value.

That means an automation must treat its input carefully. It cannot always assume that every caller passed a valid value.

Critical automations should begin with conditional checks or use a script to normalize parameters. Once an automation is exposed through several entry points, invalid input can otherwise make failures deep in the execution path difficult to diagnose.

Variables let steps hand data to each other

Automation rarely ends after one step. It is usually a sequence.

Data found by one step must be used by the next. A calculated result may need to be written back to a record. A response from an API call may determine whether processing should continue.

This requires variables.

Variables hold temporary state inside the automation context. They may come from input parameters, be created by a variable step, or contain the return value of another automation step.

For example, an automation could:

Query a customer record.
Store the customer's region in a variable.
Select a sales team based on that region.
Update the customer owner.
Return the owner information.

Each step passes data to the next. Without variables, automation can express only simple sequential actions. With variables, it can express business logic.

But variables should not accumulate without discipline. The more variables a canvas contains, the harder it becomes to read. Interactive steps also require the runtime to persist the current execution state, so excessive variables have a performance cost.

I prefer to distinguish between two kinds of variables:

Business variables that genuinely need to survive across steps
Temporary variables used only for intermediate calculations

The first group should have clear names. The second should be discarded after use or kept within the smallest practical scope.

Flow control determines how far automation can go

Without flow control, automation can only execute from top to bottom.

That solves simple problems, but real business logic quickly reaches the limit.

Imagine validating a purchase order. The automation first queries the order details, loops through each line item, retrieves the related material, and compares the tax-inclusive price with the material's maximum purchase price.

If a condition fails, execution stops. Otherwise, the automation continues by updating status, displaying a message, and refreshing the form and table modules.

This is no longer "run a task." It is a business program expressed visually.

Real processes contain branches:

Different customer levels use different assignment rules.
Different contract amounts notify different people.
Different data sources require different validation.
Every row in an import must be processed individually.

Conditional branches and collection loops are therefore foundational automation capabilities.

A condition uses an expression to control the path. When the expression evaluates to true, the matching branch runs. Otherwise, execution follows the alternative branch.

A collection loop executes a group of child steps for every item in a list.

These capabilities look ordinary, but they determine whether automation can perform a few simple actions or express an entire business procedure.

Another essential step is terminate execution.

Termination is not merely stopping. It ends the automation and rolls back the transaction after the latest blocking step.

This behavior acknowledges that automation needs transaction boundaries and data consistency. Many enterprise automations modify data. If a critical validation fails, later writes must not continue.

In that situation, termination is not a convenience. It is a safety mechanism.

Automation steps must represent real business actions

An automation ultimately performs work through steps. Those steps need to cover the actions that enterprise applications actually use.

Table steps handle querying, creating, updating, and deleting records, as well as recalculating lookup and summary fields.

Control and variable steps handle loops, conditions, variable assignment, variable updates, termination, code snippets, script calls, automation calls, return values, and execution progress.

Function steps handle HTTP requests, notifications, waiting, application events, client events, and messages shown inside modules.

AI-related steps can invoke language models such as ChatGPT.

Together, these steps make automation more than a flowchart. They make it part of the platform runtime.

Consider a customer lead entering the system:

Query whether a duplicate customer already exists.
If no duplicate exists, create the customer record.
Select an owner based on region and industry.
Update the customer owner.
Send a notification.
Invoke a script to generate follow-up suggestions.
Return the processing result to the caller.

This sequence combines table operations, conditions, scripts, notifications, and a return value. Writing every step as custom code is expensive. Providing them as configurable automation steps lets the platform carry a large share of everyday enterprise operations.

Return values make automation composable

Many automations should not simply finish after executing their actions. They need to return a result to the caller.

An application API may use the automation result as its HTTP response.

An expression may invoke an automation and continue calculating with its result.

Another automation may choose its next step based on the returned value.

A script may also invoke an automation and consume its result.

This makes the ability to set an automation return value essential. It changes automation from a background action into a composable platform capability.

The model is similar to a function. A function without a return value can only perform side effects. An automation with an explicit return value can participate in larger programs.

Consider a quotation automation. It accepts a customer, products, quantities, and discounts. Internally, it queries pricing rules, calculates taxes, and evaluates available promotions. Finally, it returns the quotation details.

The same automation can be called from a form button, an API, another automation, or a script.

It is no longer merely an action behind a button. It is a business function inside the platform.

Interactive steps connect automation with human judgment

Automation is usually associated with background execution, but INFORMAT also supports interactive steps.

When execution reaches such a step, the system persists the current variables and asks a user to complete an interaction. It may open a custom form, for example. After the user submits it, the runtime restores the variables and continues from the paused step.

This design is valuable because many enterprise processes are only partially automatic.

The system may complete most of the work while still requiring a person to provide information or make a judgment in the middle.

After importing a spreadsheet, the system may parse the data but ask the user to map several incomplete fields.

Before generating a contract, it may retrieve the customer and products but ask the salesperson to confirm the reason for a discount.

Before starting a project, it may create a draft from the contract but ask the delivery owner to confirm the start date.

Pure background automation is too rigid for these cases. Turning every step into a separate page loses the continuity of the automation.

Interactive steps connect the two models.

Automation pauses. A user participates. After submission, automation resumes.

This allows automation to carry business processes that include both machine execution and human judgment.

HTTP calls turn automation into a business API

An automation can also be invoked over HTTP. Once enabled, an external system calls a dedicated endpoint, passes parameters, and receives the automation's return value.

This gives automation a natural API capability.

An external system does not always need direct access to a collection of low-level APIs. It can call one automation that performs input validation, data queries, business decisions, record updates, and result construction internally.

The exposed interface then represents a business action instead of a scattered set of data operations.

Suppose an external ERP needs to synchronize a customer status. It could call a generic "update record" API. A better option may be to call a "synchronize customer status" automation.

That automation can verify that the customer exists, validate the new status, write a status-change record, update the customer table, send a notification when necessary, and return a structured result.

This model is closer to the real needs of enterprise integration.

An automation invoked through HTTP cannot contain interactive output steps. That restriction is reasonable. An HTTP call requires a single request and response; it cannot pause indefinitely while waiting for a user.

Automations exposed as APIs must therefore distinguish synchronous processing paths from interactive business paths.

Limits are part of the design

Unrestricted automation is easy to misuse.

A loop can accidentally become infinite. Processing a large dataset can take too long. Automations can call other automations recursively until the execution path becomes impossible to control.

The runtime increments a step counter each time a step runs. Once execution exceeds the configured limit, the system terminates the automation and raises an error.

This may look like a technical limit, but I see it as part of platform governance.

The more open a low-code platform becomes, the more clearly it needs boundaries. A single configuration error should not be able to exhaust the resources of an entire application.

Large loops and complex calculations are often better implemented as code snippets. This follows the same boundary described in the previous article:

Automation is for orchestration.

Scripts are for complex logic.

The two should not try to replace each other. Automation connects business steps. Heavy calculations, complicated loops, and data cleansing belong in scripts or code snippets so the visual canvas remains readable and execution remains manageable.

What matters in the initial version

I would not begin by pursuing an extremely sophisticated orchestration engine. I would first make the core runtime model clear.

First, automation needs input parameters and return values so listeners, buttons, APIs, scripts, and other automations can call it.

Second, automation needs a variable context. Steps must pass data to each other, scopes must be clear, and expressions should provide useful suggestions.

Third, automation needs basic flow control. Conditions, collection loops, termination, automation calls, and script calls form the foundation for business logic.

Fourth, automation needs stable business steps. Table operations, HTTP requests, notifications, logging, progress updates, and application events should come first.

Fifth, automation needs interactive steps. Many enterprise processes are not purely background actions. The ability to pause, preserve variables, wait for user input, and resume is critical.

Sixth, automation needs HTTP invocation so it can serve as a business interface for external systems.

Seventh, automation needs runtime limits and termination controls. Step-count limits, infinite-loop protection, and execution monitoring are baseline requirements for platform stability.

Once these capabilities are reliable, automation becomes more than a set of configured actions. It becomes a business runtime unit.

The direction

Automation occupies a central position in a low-code platform.

Forms collect data.

The data model organizes it.

The workflow engine handles approval and state transitions.

The plugin mechanism defines extension entry points.

Scripts carry complex logic.

Automation determines how business actions move across all of them.

It can be triggered by a listener or a button. It can be called by another automation, a script, or an external HTTP request.

It can accept parameters, assign variables, evaluate conditions, process collections, invoke scripts, interact with users, and return results.

That is no longer a scheduled task.

It is the business action orchestration layer of a low-code platform.

Learn more about INFORMAT.

Why Low-Code Platforms Need a Plugin Mechanism

informat — Sat, 08 Aug 2026 12:43:16 +0000

In the previous post about workflow engines, I ended with a distinction:

Workflows determine how business moves forward. Automation and plugins determine how the platform extends those actions beyond its core.

This post is about the plugin mechanism.

But first, the term "plugin" needs some clarification.

In INFORMAT, a plugin is not a package where developers install a large block of isolated business logic. I think of it as a set of extension points.

Automation and scripts still carry most of the business logic. Event listeners, APIs, and custom controls act as entry points and connection points. At the right moment, they pass events, data, and user actions into automation or scripts for processing.

This distinction matters because a low-code platform should not encourage teams to scatter logic everywhere.

It should provide enough entry points for business-specific extensions while keeping the actual logic inside a unified automation and scripting system.

A plugin should not be an isolated block of code

When designing a plugin mechanism, it is tempting to begin with a simple idea: open up a place where developers can write code.

That sounds flexible.

In practice, it can make a platform difficult to control. Every customer adds a little code. Every project introduces another rule. Every page hides one more condition. Delivery may be fast in the short term, but long-term maintenance becomes painful.

A sustainable plugin mechanism should answer three questions:

When does the business need an extension?
Where should that extension enter the platform?
What should execute the actual business logic?

My answer is that entry points can be distributed, but logic should be centralized.

Listeners can respond to data changes.

APIs can expose platform capabilities to external systems.

Custom controls can introduce specialized interactions into a page.

But these entry points should avoid accumulating complex logic themselves. Whenever possible, they should invoke automation, scripts, or reusable platform actions.

That separation prevents the platform from turning into a collection of scattered custom code.

Listeners are event entry points

An event listener has a direct job: when a particular event occurs, it triggers a configured automation or invokes a script.

Common events include:

Before a table record is created
After a table record is created
Before a table record is updated
After a table record is updated
Before a table record is deleted
After a table record is deleted

These events may look basic, but they are critical extension points in enterprise systems.

After a customer is created, the system may generate a customer number.

Before a contract is updated, it may validate the amount against the available budget.

After an order is created, it may synchronize the order with an external ERP system.

Before a record is deleted, it may determine whether deletion is allowed.

After data changes, it may notify the responsible team.

If every requirement is implemented inside the core table logic, the platform becomes heavier with every new use case. If the platform emits events through listeners and lets automation or scripts handle the response, its core can remain stable.

That is the value of a listener.

It is not the business logic itself. It is the entry point that triggers the business logic.

APIs are entry points for external systems

Listeners primarily handle events inside the platform. APIs connect INFORMAT with the systems around it.

Enterprise digital operations never depend on a single system. A company may already use ERP, finance, MES, office automation, collaboration tools, or an internal data platform.

INFORMAT should not assume that it will replace every one of them. It needs APIs so external systems and the platform can call each other.

For example:

An external system creates a customer record.
A finance system writes back a payment status.
A button in a collaboration tool triggers an INFORMAT workflow.
An AI assistant calls a business API to retrieve authorized data.

These are also plugin entry points. An external system enters through an API, and INFORMAT uses automation and scripts to perform the subsequent actions.

The difficult part is not merely making the request succeed. The platform must also handle permissions, logs, errors, and business state after the call.

A bare API eventually produces a collection of disconnected integrations. An API connected to the automation and scripting system can bring external actions into the same runtime as internal processes.

Custom controls are interface entry points

Standard form and page controls cover most common scenarios: text, numbers, dates, users, departments, attachments, related records, and sub-tables.

Enterprise applications still encounter specialized interactions:

Selecting a location on a map
Scanning a code to enter data
Displaying an equipment status panel
Editing contract clauses
Building a complex quotation component
Calling an external pricing service when a user clicks a button

Building every possible interaction into the platform would make the core product bloated. Custom controls should therefore serve as extension points for the interface.

But a custom control should not become a container for all business logic either.

The control handles interaction.

Automation handles business actions.

Scripts handle complex calculations.

APIs handle external calls.

With these boundaries, a custom control does not become a black box. It collects a user action and hands that action to the platform's unified runtime.

Automation is the orchestration layer

If listeners, APIs, and custom controls are entry points, automation is the orchestration layer.

It determines:

When a process is triggered
Which conditions must be satisfied
Which actions should run
What happens after a failure
Whether subsequent actions should continue
Whether users should be notified
What should be written to the execution log

Consider what happens after a customer record is created.

A listener captures the event. Automation checks whether the customer came from the company website. If so, it assigns the customer to a salesperson, sends a notification, and creates a follow-up task. If the customer is rated as level A, it also alerts a manager.

This business chain should not live inside the listener.

The listener triggers it. Automation organizes it.

That makes the system easier to understand and much easier to troubleshoot.

Scripts are the complex logic layer

Automation is effective for orchestration, but not every kind of logic belongs in visual configuration.

Some logic is inherently complex:

Quotation calculations
Budget validation
Data cleansing
Signing external API requests
Evaluating complicated conditions across multiple tables

Forcing all of this into configuration can make the visual editor harder to use than code. Scripts are necessary for logic that automation cannot express well.

Scripts still need clear boundaries. They should run inside a context provided by the platform. A script should be able to:

Identify the current user and application
Access the current table and record
Read only permitted fields
Return a structured result
Be invoked by automation
Produce an execution log

With this model, scripts are not fragments of code hidden around the system. They become governed parts of the platform runtime.

Why these layers should remain separate

Separating entry points, orchestration, and logic keeps the platform manageable.

Complex logic inside listeners becomes difficult to maintain.

Direct external calls from custom controls turn pages into business black boxes.

API calls that modify core data without automation or logging become difficult to trace when something goes wrong.

I prefer a structure with explicit responsibilities:

Listeners handle event entry points.
APIs handle external entry points.
Custom controls handle interface entry points.
Automation handles orchestration.
Scripts handle complex logic.
Permissions enforce boundaries.
Logs provide traceability.

Together, these parts form a sustainable plugin mechanism for a low-code platform.

This is not primarily a plugin marketplace. It is an extension architecture.

Extension mechanisms must be observable

Once extensions enter real business operations, the greatest risk is often not missing functionality. It is being unable to find where a failure occurred.

Did the listener fire?

Did the automation run?

Did the script fail?

Did the API call time out?

What parameters did the custom control send?

Which fields were ultimately changed?

Did the failure prevent the main process from continuing?

The platform must be able to answer these questions. Every execution should leave a record that includes:

The event source
The identity that triggered it
The application, table, and record involved
The automation that was called
The script that was executed
Its input and output
Execution time
The reason for any failure
Whether the action was retried
Whether it blocked subsequent processing

Without these records, every increase in extensibility makes the system harder to govern.

Extensions must not bypass permissions

Plugin entry points introduce another risk: they can accidentally become permission backdoors.

A user may be unable to edit a field in the standard interface, while a custom control modifies it through an API.

A user may only be allowed to view their own customers, while a script queries every customer.

An AI assistant may call an API and retrieve data that the current user should never see.

Listeners, APIs, custom controls, automation, and scripts must all remain inside the permission system.

They can extend business capabilities, but they cannot bypass business boundaries.

Every execution needs an explicit identity. Is it running as the current user or as the system? If it uses a system identity, what is that identity allowed to do?

The platform must define which fields can be read or written, which external services can be called, and which actions require an audit record.

These boundaries must be designed from the beginning. Otherwise, a mechanism that looks flexible in the short term creates significant data risk over time.

What matters in the initial version

I would not begin by building a sophisticated plugin marketplace. I would first complete the internal extension path.

First, listeners should support the core data events: before and after create, update, and delete.

Second, listeners should be able to trigger automation. They remain entry points while automation owns the business sequence.

Third, automation should be able to invoke scripts. Scripts handle special validation, complex calculations, and external integrations.

Fourth, custom controls should be able to trigger platform actions. They pass user interactions to automation or scripts instead of carrying heavy logic in the frontend.

Fifth, API calls should enter the unified logging system. The platform should trace their source, parameters, results, and effects.

Sixth, permissions and auditing should be restrictive by default. The more powerful an extension mechanism becomes, the less reasonable it is to grant broad access automatically.

Only after these foundations are reliable does a broader plugin ecosystem become meaningful.

The direction

A plugin mechanism should not turn a low-code platform back into a conventional coding platform.

Its purpose is to leave room for differentiated enterprise requirements without destabilizing the platform core.

For INFORMAT, the most accurate model is a set of extension points:

Listeners provide event entry points.

APIs provide external entry points.

Custom controls provide interface entry points.

Automation orchestrates business actions.

Scripts carry complex business logic.

Permissions and logs keep the system governable.

That architecture creates space for customization while preserving a coherent runtime. For an enterprise low-code platform, that balance matters far more than simply allowing more code.

Learn more about INFORMAT.

A Workflow Engine Is More Than an Approval Diagram

informat — Thu, 06 Aug 2026 13:59:42 +0000

In the previous post about permissions, I ended with one judgment:

Permissions define boundaries. Workflows define how business moves forward.

This post continues with the workflow engine.

When many people hear "workflow", their first reaction is approval flow.

Leave approval, reimbursement approval, contract approval, purchase approval. Draw a few nodes, configure approvers, add a few conditional branches, and it feels like the workflow engine is finished.

I used to think this way too.

But after building a low-code platform, I realized that a workflow engine is far more than drawing approval flows.

It has to answer a deeper question: can the platform stably describe, execute, and trace the entire process of a business record from creation, submission, review, rejection, modification, completion, and then onward into automation and data changes?

In other words, the workflow engine is not an isolated feature. It is part of the business runtime.

A workflow is not a diagram, but state change

The most visible part of a workflow designer is the diagram.

Start nodes, approval nodes, conditional branches, copy nodes, and end nodes.

These shapes matter because users need them to understand the business path.

But for the system, the truly important thing is not the diagram. It is state change.

A contract moves from draft to under approval, then to legal review, finance review, approved, rejected, and archived. These state changes are what actually happen in the business.

If a workflow stays only at the diagram level, a problem appears:

The diagram may look beautiful, but data state, permissions, notifications, logs, and downstream automation are not really connected.

So I prefer to understand workflow as a state machine.

Nodes are states.

Lines are state-transition paths.

Approval actions are triggers for state transition.

Workflow records are the history of state transition.

With this design, workflow is no longer only about who approves. It is about which state a business object enters under which conditions.

Workflows must bind to business objects

Workflows in a low-code platform cannot exist apart from the data model.

If a workflow is only an empty approval template, it is hard for it to truly enter the business.

A workflow must bind to a specific business object.

Contract approval binds to the contract table.

Expense reimbursement binds to the reimbursement table.

Purchase requests bind to the purchase request table.

Project initiation binds to the project table.

Once bound, the workflow can read business fields.

What is the contract amount?

What is the customer level?

Which department submitted the request?

What is the project budget?

Does it involve an external vendor?

These fields decide how the workflow moves.

For example, if a contract amount is below 100,000, it may only need department-lead approval. If it exceeds 100,000, it may also require finance review. If it contains special terms, it may require legal review.

This shows that workflows do not run in the air. They depend on the data model.

The clearer the data model is, the more stable workflow expression becomes.

Approvers should not be hard-coded

One easily underestimated problem in workflow design is the approver.

In simple scenarios, a specific person can be assigned directly.

But real enterprise workflows are rarely that simple.

The approver may be the initiator's direct manager.

It may be the head of the initiator's department.

It may be a role such as finance, legal, or procurement owner.

It may come from a form field, such as project owner, customer owner, or contract owner.

It may also change dynamically based on amount, region, or business line.

If approvers can only be hard-coded, workflows quickly lose flexibility.

So the workflow engine must support dynamic approvers.

This involves organization structure, roles, user fields, department fields, and rule expressions.

In other words, the workflow engine naturally depends on the permission system and organization model.

That is why I do not like treating workflow as an isolated module.

It appears to handle approval, but it is actually scheduling responsibility relationships inside the enterprise organization.

Conditional branches must not become black boxes

Conditional branches are also critical in workflows.

A branch may look like a simple judgment:

Amount greater than 100,000 goes to finance.

Customer level A goes to senior approval.

The R&D department goes to a technical lead.

An empty field returns for completion.

When there are only a few rules, this is fine.

But as rules grow, branches can easily become black boxes.

Users will ask:

Why did this request go to legal?

Why did it not go to finance?

Why was my request returned?

Why did two contracts with the same amount take different paths?

If the system can only answer "because that is how the workflow is configured", that is not enough.

I think the workflow engine should at least leave explainable execution records.

Which branch was hit.

Which fields were read during evaluation.

What the field values were at that time.

Which condition was true and which condition was false.

This information is extremely important for troubleshooting.

Otherwise, when a workflow goes wrong, the final answer is often that developers have to check logs, while business users cannot understand the process themselves.

Rejection is not simply going back one step

Many workflow engines have "reject" or "return" actions.

But returning is actually complex.

Return to the initiator?

Return to the previous node?

Return to a specified node?

After return and resubmission, should the workflow start from the beginning or continue from the returned node?

Which fields can be modified during return?

Should the return record be kept?

Are previous approvers' opinions still valid?

For example, in contract approval, legal may return the contract to sales to add terms. After sales modifies it, does it need to go through the department lead again? Does the previous finance review still count?

There is no single answer to these questions. It depends on the business.

So the workflow engine should not implement return as one fixed action.

It should be a configurable transition.

Where to return, whether to rerun previous steps, which fields can be opened for modification, and how previous approval opinions are handled should all enter workflow design.

Workflows change permissions

In the previous post about permissions, I wrote that workflows and permissions cannot be separated.

From the workflow perspective, this becomes even clearer.

For the same reimbursement form, permissions differ across workflow states.

In draft state, the initiator can edit it.

After submission, the initiator can no longer change the amount.

During department-lead approval, the approver can fill in approval comments.

During finance review, finance can modify the expense category.

After the workflow ends, ordinary users can only view it.

This shows that workflow nodes change field permissions and action permissions.

If the workflow engine is not connected to the permission system, temporary frontend controls become the only protection.

That is dangerous.

Users may bypass frontend restrictions through APIs, imports, automation, or AI.

So permissions on workflow nodes must become part of backend permission evaluation.

Where the workflow goes, permissions should follow.

Workflow is not only approval; it also includes automatic actions

In enterprise workflows, not every step should require human handling.

Many nodes should be completed automatically.

After contract approval, automatically generate a contract number.

After purchase request approval, automatically create a purchase order.

After project initiation approval, automatically create a task template.

When a customer stage becomes won, automatically notify the implementation team.

After reimbursement approval, automatically write into the payment plan.

If all these actions require manual handling, the workflow only moves responsibility from one person to another. It does not truly reduce work.

So the workflow engine must support automatic nodes.

Automatic nodes can update fields, change status, send notifications, create records, call APIs, execute scripts, or trigger automation.

This turns workflow from an approval tool into a business orchestration tool.

I think this is an important difference between a low-code platform and an ordinary approval system.

Workflow records matter more than workflow diagrams

A workflow diagram describes the design.

Workflow records describe the facts.

When an enterprise needs accountability and review, it looks at facts.

Who submitted at what time?

Who approved?

Who returned it?

What was the return reason?

Which conditional branch was hit?

What automatic action did the system execute?

Did the API call succeed?

How long did the workflow take?

How long was a certain node blocked?

This information is not only logs. It is part of business data.

If workflow records are incomplete, later statistics, audit, and AI analysis all become difficult.

For example, if managers want to know the average contract approval time, they cannot only look at the current contract status. They need the start and completion time of each node.

If AI wants to summarize "this week's approval bottlenecks", it also depends on workflow records.

So the workflow engine should design execution records from the beginning.

Adding them later is painful.

What matters most in the initial workflow engine

A workflow engine can easily grow very large.

BPMN, countersign, either-or approval, additional signing, transfer, withdraw, return, subprocesses, timers, message events, exception boundaries, compensation mechanisms...

All of these capabilities matter, but the initial version cannot swallow everything at once.

If I were building the initial version, I would first make sure of several things.

First, workflows must bind to data tables.

Workflows cannot be isolated templates. They must run around business objects.

Second, node types should be controlled at the beginning.

Start, manual approval, conditional branch, automatic action, and end should first make the main path work.

Third, approvers must support dynamic configuration.

At minimum, the platform should support specified members, roles, department heads, user fields, and the initiator's manager.

Fourth, workflow state must be written back to business data.

A business record should know whether it is in draft, under approval, approved, rejected, withdrawn, and so on.

Fifth, node permissions must enter backend permission evaluation.

Which fields are visible, which fields are editable, and which actions are executable cannot rely only on the frontend.

Sixth, workflow records must be complete.

Every submission, approval, return, and automatic execution should leave structured records.

Seventh, automatic nodes should first support the most common actions.

Field updates, record creation, notifications, and API calls are among the most practical actions.

After these capabilities are stable, countersign, additional signing, subprocesses, and more complex event mechanisms can be added gradually.

Common mistakes in workflow design

The first mistake is focusing only on the workflow diagram.

Drawing the diagram does not mean the workflow can truly run. State, permissions, records, and exception handling must all follow.

The second mistake is hard-coding approvers.

It is simple at the beginning, but once the organization changes, people move, and cross-department workflows increase, maintenance becomes very hard.

The third mistake is making return logic too rough.

Returning is not simply "go back one step." It affects data modification, approval opinions, and later paths.

The fourth mistake is separating workflow and permissions.

If node permissions do not enter the permission-evaluation system, workflow state can easily be bypassed.

The fifth mistake is leaving no records for automatic actions.

If the system automatically changes fields, creates records, or calls APIs without logs, problems become hard to investigate.

The sixth mistake is making the workflow engine too complex from the beginning.

A workflow engine can certainly be very complex, but the first version of a low-code platform needs stability, explainability, and extensibility more.

It is more important to make common enterprise workflows run steadily than to chase every advanced capability.

The direction

The workflow engine is a module that is very easy to misunderstand in a low-code platform.

On the surface, it draws processes and configures approvers.

But deeper down, it connects the data model, permission system, organization structure, automation, integration, and audit.

The data model tells the workflow what object it is handling.

The permission system decides what each node can see and change.

The organization structure decides who should take responsibility.

Automation makes the workflow more than human handoff.

Integration lets the workflow connect to external systems.

Workflow records make the business process traceable and reviewable.

So the workflow engine is not an approval plugin.

It is the track on which enterprise business runs.

For INFORMAT, the workflow engine is not about whether a user can draw an approval diagram. It is about whether business objects can move forward along clear, controllable, and traceable paths.

In the next post, I want to write about automation and the plugin mechanism.

Workflows define business paths. Automation and plugins define how the platform extends actions outward.

Why Permission Systems Are So Hard in Low-Code Platforms

informat — Wed, 05 Aug 2026 14:35:34 +0000

In the previous post about data models, I left one question:

The data model defines business objects, but in an enterprise organization, who can view, edit, approve, and export those objects eventually becomes the responsibility of the permission system.

I underestimated permissions at the beginning.

When first building enterprise software, it is easy to think permissions are mostly roles, menus, and buttons. Administrators can see everything. Ordinary employees can only see their own data. Department managers can see their department. That sounds almost enough.

After building a low-code platform, I realized this understanding was far too light.

In a fixed business system, permissions can be complex, but the boundaries are relatively clear because objects, fields, workflows, and pages are determined during development.

But in a low-code platform, users can create tables, add fields, configure workflows, modify pages, and build automation by themselves. Business objects are dynamic. Organization structures are dynamic. Workflow nodes are dynamic too.

At that point, permissions are no longer just about who can open which menu. They become an underlying platform question:

When the business model keeps changing, can the system still stably and accurately decide whether a person has permission for a record, a field, or an action?

The hardest part of permissions is not menus

Menu permissions are the easiest to understand.

Sales can enter CRM. Finance can enter the payment collection module. Administrators can enter the configuration center.

This type of permission is usually not hard because it controls the entrance.

The real trouble in enterprise systems is not the entrance. It is the data.

Inside the same customer module, different people may see completely different data.

Salespeople can only see the customers they own.

Sales managers can see customers in their department.

Regional leaders can see data for certain regions.

The CEO wants to see everything.

There are also special cases, such as a customer being shared by multiple salespeople, or a project temporarily authorized for an external consultant to view.

Now the problem appears:

Everyone opens the same customer module, but each person sees a different customer list.

Menu permissions cannot solve this.

This is data permission.

A record is not only "visible" or "invisible"

Data permission is also not simply visible or invisible.

In real business, a record usually has many operation layers.

Can the user see it in the list?

Can the user view the detail page?

Can the user edit it?

Can the user delete it?

Can the user export it?

Can the user start approval?

Can the user transfer this record to someone else?

Can the user modify several sensitive fields?

For customer data, an ordinary salesperson may edit customer name, phone number, and source, but cannot change the customer owner.

A manager may change the owner, but cannot delete the customer.

Finance may view contract amount and payment collection, but may not see customer follow-up records.

Administrators may be able to do everything, but their operations must leave audit records.

This shows that permissions cannot stop at whether a record can be viewed.

They must be split into data scope, field permission, action permission, special rules, and audit requirements.

Field permissions are more troublesome than they look

Field permissions are often added late in enterprise systems.

For speed, many systems build the form first. Later, when a customer says certain fields cannot be shown to certain people, temporary controls are added.

But in a low-code platform, if field permissions do not enter the design from the beginning, the cost later becomes painful.

Fields are not fixed.

Today a user adds "contract amount." Tomorrow they add "customer rating." The day after that, they add "cost budget." Any of these fields may need permission control.

More troublesome, field permissions have many states.

Hidden.

Read-only.

Editable.

Required.

Editable inside a workflow node.

Editable under specific conditions.

For example, in an expense reimbursement form, the amount can be edited before the initiator submits it. After submission, the initiator can no longer change the amount, but finance may modify the expense category during review. After the workflow ends, everyone can only view it and cannot modify it anymore.

The same field may have completely different permissions under different roles, workflow nodes, and data states.

That is the real complexity of field permissions.

It is not a static configuration. It changes together with workflow, state, role, and conditions.

Row permissions and field permissions affect each other

There is another easily overlooked issue in permission design:

Row permissions and field permissions are not isolated.

Row permissions decide whether a person can see a record.

Field permissions decide which fields are visible or editable after that person sees the record.

But often, fields themselves participate in row permission checks.

For example:

Owner equals current user, so the record is visible.

Department equals the current user's department, so the record is visible.

Customer level is strategic customer, so only specified roles may view it.

Project status is confidential, so only project members may view it.

Owner, department, customer level, and project status are all fields.

In other words, the system must first read field values before it can decide whether the record is visible to the current user.

If the boundary between field permission and row permission is unclear, a loop appears:

The user has no field permission, so the system cannot read the field.

But the system needs to read the field to decide whether the user has data permission.

This problem is not obvious in simple systems, but it is amplified in platform products.

So the permission system must distinguish between fields required for system permission evaluation and fields visible to users.

The system can read necessary fields to evaluate permissions, but that does not mean those fields must be displayed to the user.

This boundary must be very clear.

Permissions cannot rely only on roles

Many enterprise systems start with role-based permissions.

Sales, sales manager, finance, administrator.

Roles are necessary, but if permissions rely only on roles, they quickly become rigid.

Real enterprise permissions are often not decided purely by roles.

They also depend on organization structure.

They depend on data ownership.

They depend on workflow nodes.

They depend on temporary collaboration.

They depend on business state.

The same sales manager may manage the East region or the South region.

The same finance role may only process data for one legal entity.

The same project member may view costs, while another can only view tasks.

If all of this is expressed through roles, the number of roles explodes.

Sales manager, East sales manager, South sales manager, project member who can view cost, project member who cannot view cost...

Eventually the system contains a pile of roles nobody can explain clearly.

So I now prefer splitting permissions into several categories:

Roles answer "what identity do you have?"

Organization answers "where do you belong?"

Data ownership answers "what relationship does this data have with you?"

Workflow nodes answer "whose turn is it now?"

Rule expressions answer "how should special conditions be evaluated?"

Only then does permission pressure stop being pushed entirely onto roles.

Workflow permissions are the easiest to get wrong

If a system has no workflow, permissions are already complex enough.

Once workflows exist, permission complexity rises another level.

Workflows change data state, and they also change the boundary of user operations.

For example, in a contract approval workflow:

Before submission, the initiator can edit contract content.

After submission, the initiator can no longer change core fields.

During department-lead approval, the approver can fill in review comments but cannot change contract amount.

During legal review, legal terms can be modified.

During finance review, the payment plan can be viewed.

After the workflow ends, the contract enters archived status and ordinary users can only view it.

Permissions here are not static.

The same person may have different permissions for the same record before, during, and after the workflow.

If a low-code platform supports user-configured workflows, it also has to support this dynamic permission change.

That is why I think workflows and permissions cannot be designed separately.

A workflow does not only push a task to the next person. It also affects which fields can be seen, which fields can be edited, and which actions can be performed at each node.

Permissions must also serve AI

Permission design now has a new question that did not exist before:

Can AI safely access business data?

If AI is only a chat tool, the issue is less severe.

But if AI connects to a low-code platform and helps users query data, analyze data, generate reports, modify configurations, and trigger workflows, permissions must keep up.

When a user asks AI:

"Help me look at this customer's recent contracts and payments."

AI cannot bypass user permissions just because it is a system capability.

It should only see the data the current user is allowed to see.

When a user asks AI:

"Change this customer's owner to Alex."

AI must first check whether the current user has permission to modify the owner field.

When a user asks AI:

"Export all contracts from this month."

AI needs to check export action permission, data-scope permission, and field masking requirements.

So after AI enters the platform, permissions do not become simpler. They become more important.

AI should be an extension of user capability, not a permission backdoor.

This is the baseline that enterprise AI applications must hold.

What matters most in the initial permission system

The permission system should not be made omnipotent from the beginning.

If permission configuration is too complex, users will be afraid of it, and development will also lose control.

I care more about several basic capabilities in the initial design.

First, role permissions must be clear.

Whether a user can enter an application, module, or page, and whether they can perform actions such as create, edit, delete, and export, should be clearly configurable.

Second, data scope must be expressible.

At minimum, the platform should support common patterns such as self, department, department and sub-departments, all, field-based ownership, and expression-based rules.

Third, field permissions must enter the model.

Field visibility, read-only state, and editability cannot rely only on temporary frontend checks. They must become platform capabilities.

Fourth, workflow-node permissions must be configurable.

At each workflow node, which fields are editable and which actions are executable should be configurable.

Fifth, system permission evaluation and user display must be separated.

The system can read necessary fields for permission evaluation, but what users ultimately see must be decided by field permissions.

Sixth, permission results should be explainable.

When a user asks "why can't I see this data?", the system should ideally give a reason instead of only returning "no permission."

This is difficult, but it matters a lot in enterprise systems.

Common mistakes in permission design

The first mistake is only building menu permissions.

Menu permissions may look enough, but once real business arrives, data permissions and field permissions appear immediately.

The second mistake is pushing all permissions into roles.

Roles keep growing until nobody knows what each role actually means.

The third mistake is adding field permissions late.

If field permissions do not enter the model at the beginning, combining them later with workflows, forms, lists, exports, and AI becomes very hard.

The fourth mistake is doing too much permission evaluation on the frontend.

The frontend can control display, but real permission checks must be held on the backend. Otherwise, a different entry point may bypass the restriction.

The fifth mistake is having no audit for permissions.

In enterprise systems, who viewed what, who changed what, and who exported what can sometimes be even more important than the permission itself.

The sixth mistake is making permission configuration too flexible.

That sounds like a good thing, but without boundaries, users can easily create contradictory rules, and the system becomes hard to explain.

A permission system is not better just because it is freer. It should make common scenarios simple and leave exits for complex scenarios.

The direction

Permissions are the least feature-like feature in a low-code platform.

They are not as intuitive as forms, not as easy to demonstrate as workflows, and not as topical as AI.

But they decide whether a platform can truly enter core enterprise business.

Whether a company is willing to put customer, contract, order, project, and financial data into the platform depends heavily on whether it trusts the permission system.

For INFORMAT, the permission system is not an auxiliary module.

It should form the foundation together with the data model, form engine, and workflow engine.

The data model defines business objects.

The form engine carries data entry and display.

The workflow engine moves business forward.

The permission system answers throughout the whole process:

Who can do what to which data under what conditions?

If this question is not answered well, the more flexible the platform is, the greater the risk becomes.

If this question is answered well, a low-code platform has a chance to move from building tools to carrying business.

In the next post, I want to write about the workflow engine.

Permissions define boundaries, while workflows define how business moves forward.

How Should a Low-Code Platform Design Its Data Model?

informat — Tue, 04 Aug 2026 23:00:48 +0000

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.

A data model is not just table creation

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.

Start by abstracting business objects

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.

Fields need business semantics

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:

which user this owner corresponds to
which department the user belongs to
whether the user can receive notifications
whether the user participates in data permission checks
whether the user can act as a workflow approver
whether the user can be used in user-dimension statistics

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.

Relationships are easier to underestimate than fields

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:

customer details cannot show historical follow-ups
contracts cannot find related customers
orders cannot be traced back to projects
reports cannot aggregate across objects
AI struggles to answer questions such as "What contracts and follow-up records does this customer have recently?"

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.

Balancing dynamism and stability

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.

The data model must support permissions

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 data model must support workflows

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.

The data model must support reports

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.

The data model must support AI

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.

What matters most in the initial data model

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.

Some mistakes I ran into

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 direction

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.

Designing a Form Engine from Zero to One

informat — Tue, 04 Aug 2026 06:50:06 +0000

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.

Why I Am Rebuilding Enterprise Low-Code for the AI Era

informat — Sun, 02 Aug 2026 13:43:49 +0000

Low-code has become a familiar phrase.

Drag-and-drop forms. Generated pages. Approval flows. Dashboards. Internal tools. We have all seen the demos, and many of them are genuinely useful.

But after spending years around enterprise digitization projects, I became less interested in how quickly a page can be assembled, and more interested in a harder question:

Can the system still be understood, maintained, governed, and extended after the business changes?

That is the question behind INFORMAT, the international version of the enterprise low-code platform I have been building.

This post is the first entry in a development log. It is not a polished product announcement. It is a record of why I think enterprise low-code needs to be rebuilt as a durable digital foundation, especially now that AI is becoming part of how software is designed, configured, and operated.

The problem was not "no software"

When I first worked with enterprise digital transformation, the problem I saw most often was not that companies had no tools.

Usually, they had too many.

Customer information lived in spreadsheets. Approvals happened in chat groups. Contracts were stored in cloud drives. Tasks lived in project management tools. Finance had a separate system. Each tool made sense on its own, but once the real business process crossed those boundaries, things began to break.

Data did not match.

Nobody knew where a process was stuck.

Permissions were unclear.

Renaming one field could affect pages, reports, import templates, APIs, and approval conditions.

Business users felt the system was hard to use. Developers felt requirements never stopped changing. Managers no longer trusted the data. Eventually, people quietly moved back to manual spreadsheets and offline communication.

That pattern shaped my view of enterprise software:

A company does not just need another app. It needs the ability to continuously model, run, and govern its business.

Low-code is the entry point, not the destination

Low-code is valuable because it shortens the path from business idea to working system.

If the goal is a customer registration form, a leave request flow, or a task list, low-code can help build it quickly.

But enterprise work rarely stops at one form.

A customer record leads to contacts, follow-ups, contracts, orders, payments, support tickets, and renewal risk.

A leave request connects to organization structure, attendance rules, payroll, and permission boundaries.

A project task connects to members, workload, cost, timeline, risk, and reporting.

If a platform only answers "how do we generate this page?", then relationships, workflow, permissions, analytics, and integrations will eventually become isolated again.

This is why I do not want to define INFORMAT as only a low-code tool.

I think of it as an enterprise digital foundation.

Low-code is the entry point because it helps teams create business systems faster. The foundation is the real goal because companies need those systems to keep running, keep changing, and stay internally consistent over time.

A platform is different from an application

When you build a fixed business application, many decisions can be hard-coded.

In a CRM, you can define the objects, fields, flows, roles, and reports ahead of time.

A low-code platform is different.

Users create their own applications. They define tables, add fields, configure views, design workflows, set permissions, and connect automations. Today the app may be customer management. Tomorrow it may be procurement approval, equipment inspection, or project delivery.

That means the platform cannot only know how to render the current page.

It has to understand:

what the business object represents
what each field means
how objects relate to each other
who can see or change which data
how a workflow moves under different conditions
which tools automation and AI are allowed to call

In other words, the platform must store business data and also the metadata that describes the business.

This idea drives many design decisions in INFORMAT:

A form is not just a page.
A field is not just an input control.
Permission is not just a menu setting.
A workflow is not just a diagram.
AI is not just a chatbot attached to the side of the product.

Why AI makes this worth rebuilding

AI coding tools are already very good at producing screens, APIs, scripts, and small features.

But an enterprise system is not just a collection of generated code snippets.

Enterprise systems need to answer precise operational questions:

What is the relationship between a customer and a contract?
Who is allowed to view this record?
Which fields can be edited during approval?
How do we trace a failed automation?
Can AI-generated changes be audited?

If that knowledge is scattered across code, prompts, documents, and people's memory, the system becomes harder to govern as it grows.

Low-code platforms have an important advantage here: they can make business objects, fields, relationships, permissions, workflows, and operation logs explicit.

Once those structures are explicit, AI can work inside a real business context instead of guessing from thin air.

To me, AI plus low-code should not mean placing a chat box next to a traditional builder. It should mean allowing AI to understand the platform's models, rules, and tools, then participate in modeling, configuration, analysis, and execution within authorized boundaries.

That is the direction I want INFORMAT to move toward.

What matters in the first stage

From an engineering perspective, the first stage is not about piling up as many features as possible.

It is about getting the foundation right.

There are five things I care about most:

Business objects must be clear. Applications, tables, fields, views, and actions need a coherent model.
Fields must carry semantics. Text, numbers, dates, users, departments, related records, attachments, and statuses should support querying, analytics, permissions, workflows, and AI understanding.
Permissions must be modeled early. Retrofitting permissions after data, workflows, and reports are already running is painful and risky.
Workflows and automation should happen around data. A workflow is not an isolated approval chart; it changes the state of a business object.
The system must be traceable. Who changed what, where a workflow is, whether an automation succeeded, and which tools AI used should all leave records.

These capabilities are less visually impressive than a drag-and-drop page builder.

But they decide whether the platform can support real enterprise operations.

Why I am writing this log

Writing development logs is also a way to force myself to review the design.

Platform products easily become complex. If the motivation behind a design is not written down, even the builder can forget why certain trade-offs were made.

So this series will try to stay close to the engineering process:

what the feature is
why it exists
where the boundary is
what turned out harder than expected
what still needs to be improved

In the next posts, I plan to write about:

why the form engine is not just a page generator
how the data model of a low-code platform should be designed
why permissions are more complicated than they look
how workflow, automation, reporting, integration, and AI connect to the same foundation

INFORMAT is not trying to be another tool that only makes page creation faster.

It is my attempt to build a system foundation where enterprise business can be continuously modeled, continuously operated, and continuously evolved.

You can learn more about the overseas version here: https://www.ainformat.com/

DEV Community: informat

How Should Scripting Work in a Low-Code Platform?

Why low-code platforms need scripts

Scripts should not swallow the entire business process

Server-side and client-side scripts need different boundaries

The informat object is the capability gateway

Code snippets belong inside local automation steps

Script functions should be reusable

Permission boundaries cannot depend on author discipline

Logging and errors are first-class capabilities

Script management is more than a code editor

What matters in the initial version

The direction

Automation Is Not a Scheduled Task. It Is Business Action Orchestration

Automation should behave like a small program

Input parameters are the automation entry point

Variables let steps hand data to each other

Flow control determines how far automation can go

Automation steps must represent real business actions

Return values make automation composable

Interactive steps connect automation with human judgment

HTTP calls turn automation into a business API

Limits are part of the design

What matters in the initial version

The direction

Why Low-Code Platforms Need a Plugin Mechanism

A plugin should not be an isolated block of code

Listeners are event entry points

APIs are entry points for external systems

Custom controls are interface entry points

Automation is the orchestration layer

Scripts are the complex logic layer

Why these layers should remain separate

Extension mechanisms must be observable

Extensions must not bypass permissions

What matters in the initial version

The direction

A Workflow Engine Is More Than an Approval Diagram

A workflow is not a diagram, but state change

Workflows must bind to business objects

Approvers should not be hard-coded

Conditional branches must not become black boxes

Rejection is not simply going back one step

Workflows change permissions

Workflow is not only approval; it also includes automatic actions

Workflow records matter more than workflow diagrams

What matters most in the initial workflow engine

Common mistakes in workflow design

The direction

Why Permission Systems Are So Hard in Low-Code Platforms

The hardest part of permissions is not menus

A record is not only "visible" or "invisible"

Field permissions are more troublesome than they look

Row permissions and field permissions affect each other

Permissions cannot rely only on roles

Workflow permissions are the easiest to get wrong

Permissions must also serve AI

What matters most in the initial permission system

Common mistakes in permission design

The direction

How Should a Low-Code Platform Design Its Data Model?

A data model is not just table creation

Start by abstracting business objects

Fields need business semantics

Relationships are easier to underestimate than fields

Balancing dynamism and stability

The data model must support permissions

The data model must support workflows

The data model must support reports

The data model must support AI

What matters most in the initial data model

Some mistakes I ran into

The direction

Designing a Form Engine from Zero to One

Opening

The initial requirement looked simple

A form is not a page, but a business model

Core objects in the first design

Field design is the first hard problem

The second hard problem is balancing dynamism and stability

The `informat` object is the capability gateway