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

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:

1. Query a customer record.
2. Store the customer's region in a variable.
3. Select a sales team based on that region.
4. Update the customer owner.
5. 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:

1. Query whether a duplicate customer already exists.
2. If no duplicate exists, create the customer record.
3. Select an owner based on region and industry.
4. Update the customer owner.
5. Send a notification.
6. Invoke a script to generate follow-up suggestions.
7. 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.