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.