How Should Scripting Work in a Low-Code Platform?

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.