A practical guide to event-driven, user-driven, scheduled and API automation, this post explains key blockly script types you may encounter.

Build ERP workflows visually—without writing conventional source code.

Blockly script categories in Automation Customization

Visual automation inside ERPAG

ERPAG Blockly scripts provide a visual programming layer for adapting ERP processes to a company’s own rules. Users assemble blocks for logic, dates, lists, JSON, documents, attachments, APIs and database operations. The result is automation that stays close to real ERP objects such as sales orders, purchase orders, work orders, invoices, customers and items.

The most important design decision is not which block to use—it is which script type should own the task. Each script type has a different execution model and a different level of access.

Quick selection guide

1. Trigger scripts

The word trigger in English means a trigger or a button to start. A real life situation as an example would be – when you are entering a store, a sensor sees that you are about to enter and triggers the glass door to open! The blockly scripts make them easier to be configured, since the whole codding looks like putting together a big jigsaw puzzle. One part of the script tells ERPAG when to perform a specific action, and the other part of the script tells ERPAG software what to do.

A Trigger script runs automatically when an event occurs on a specific document type. The change may be made directly by a user—for example, by saving a sales order—or indirectly by another automation such as a BOT. Status transitions, including a document becoming invoiced, can also cause the configured event to run.

Create a Trigger script for a specific ERP document type.

Available events

• On data change (Old)
• Before save
• After save
• Before delete
• After delete

A Sales order Trigger script configured for the Before save event.

Trigger toolbox context

• Doc variables contains blocks for the selected document and company-level parameters.
• Doc functions contains actions available for that document.
• Attachments contains blocks for working with document attachments.
• Database exposes other ERP documents, but these are mostly read-only in Trigger scripts.

Typical uses include validating required business data before saving, setting a document field automatically, preventing an invalid change by throwing an error, or notifying another service after a successful save.

2. On-demand scripts

In plain English ‘’On-demand’’ means ‘whenever I need’. Unlike Trigger scripts that work on their own, because they are triggered by specific system action or change, on-demand script runs only when you click on a button ‘execute’ to run it.

An On-demand script performs an operation for one specific document. It can be started by a user from an action button on a document, used as a bulk action from a document list, or called from BOT, API and Scheduled scripts.

Create an On-demand script for an ERP entity or document type.

The script can read and update its target document, but it cannot create a new instance of that document or delete it. This makes it a good fit for controlled, reusable actions such as sending a sales order to an external API, recalculating values or applying a user-selected operation.

An On-demand script that sends the current sales order through an HTTP POST request.

The On-demand script appears as an action button on the Sales order form.

Parameters, prompts and return values

On-demand scripts can accept typed input parameters and return a typed result. When a user starts a bulk action, ERPAG requests the parameter values once, at the beginning of the operation.

• Input types include Text, Number, Amount, Text Selection, JSON, True/False, Date, Date and time, List, QR/barcode, File and Formatted text.
• Return types include no return value, Text, Number, Amount, True/False, Date, Date and time, JSON, List, Image and several file formats.
• The Parameters toolbox also provides Confirm, Prompt, Select and Alert dialogs. These pause an interactive run until the user responds or the dialog times out.
• Dialogs are ignored when the On-demand script is called by another script; they only operate during a user-initiated action.

3. BOT scripts

BOT scripts (short for ROBOT scripts) are real little virtual workers that work independently. It performs tasks in the background by following it’s own rules. For example, Bots on Reddit forum that ban users who leave inappropriate comments. They often work on loops, looking for the next task to do.

BOT scripts are the orchestration layer for complex ERP automation. Unlike an On-demand script, a BOT can create new documents, read and update existing records, and delete records when the business process requires it. A BOT can also call other BOT scripts and On-demand scripts.

A BOT that finds eligible sales orders and invoices each selected order.

How BOT scripts can run

• Manually by a user
• As a command on a selected ERP list
• From an API script
• From a Scheduled script
• From another BOT script

A BOT exposed as a command on the Sales orders list for bulk processing.

BOT scripts support input parameters, return values and interactive dialogs using the same model as On-demand scripts. Their Database toolbox includes CRUD blocks—create, read, update and delete—for supported ERP documents. This makes BOT the right choice for multi-document workflows, conversions, batch processing and back-office orchestration.

4. Function scripts

Function scripts are basically shortcuts. Instead of repeating the same steps all the time, you can sum all steps in a Function script, and then input the Function script into another blockly script like a scheduled script. It’s main purpose is to save you time from repetitive steps.

A Function script packages reusable logic that is always called from another script. It can read data but cannot write data. This restriction makes functions predictable and safe for calculations, lookups, formatting and validation rules.

Create a Function script by selecting its return type.

Function scripts may define typed input parameters and a typed return value. Supported creation options include Text, Number, Amount, Logic (true/false), List, Date, Date and time, JSON and No return value.

A reusable Boolean function that checks whether a supplied date is in 2026.

Once saved, the function becomes a block that can be placed inside other scripts. In the example below, a Scheduled script calls the date-check function before it starts a BOT.

A Scheduled script calling a Function script and then a BOT script.

5. Scheduled scripts

To put it in plain English, Schedule means ‘to do something at specific time’. This type of script doesn’t wait for you to click on a button (like on-demand script), or to be triggered by a specific document status. This script works on the given timetable or intervals. Like setting up your phone alarm to go off every morning at 6 am.

A Scheduled script starts automatically according to a defined period, without user interaction and even when no users are logged in. It is intended for recurring background work such as daily document processing, weekly synchronization, monthly checks or annual maintenance.

Create a schedule with a daily, weekly, monthly or yearly period.

Scheduled scripts do not have input parameters or a return value. They can call BOT and On-demand scripts, and their Database toolbox supports CRUD operations. A user may also force an execution when a run is needed immediately.

• Day: run at a selected hour each day.
• Week: run on the configured day and time.
• Month: run according to a monthly schedule.
• Year: run according to an annual schedule.

6. API scripts

The abbreviation API means Application Programming Interface. It is used to connect two completely different software solutions, that otherwise would not be able to communicate with each other.

An API script exposes ERPAG logic to another application. It is activated exclusively by an external API request and must produce a response. This makes it suitable for integrations, webhooks, controlled data retrieval and ERP operations initiated by external services.

Create an API script using GET, POST, DELETE, PUT or Webhook.

Request and response blocks

• Read the complete request URL and individual URL parameters.
• Read route segments and HTTP header values.
• Read a JSON request body.
• Return JSON, Text or XML with the appropriate HTTP status code.
• Call BOT scripts and use Database CRUD blocks to implement the endpoint’s operation.

A GET endpoint that returns selected Sales order fields as a JSON response.

How the script types work together

The script types are most effective when each one has a narrow responsibility. A practical automation architecture can be built from small reusable layers:

Recommended design practices

• Choose the least powerful script type that can complete the task. Use a Function for read-only reusable logic and reserve BOT scripts for real orchestration.
• Keep Trigger scripts short. Long-running integrations are usually better delegated to an On-demand or BOT workflow.
• Separate scheduling from business logic: the Scheduled script decides when; the BOT decides what to process.
• Use typed parameters and return values to make reusable scripts easier to understand and safer to call.
• Return clear API responses and meaningful HTTP status codes.
• Test with a limited data set before enabling a BOT, Trigger or Scheduled script in a production company.
• Use descriptions, tags and consistent naming so administrators can identify a script’s purpose and execution context.

Conclusion

ERPAG Blockly scripts cover the full automation lifecycle: responding to document events, running user actions, reusing logic, orchestrating complex ERP changes, processing work on a schedule and connecting external applications. Selecting the correct script type keeps the automation easier to maintain, easier to reuse and safer to operate.

Start with the execution question—what should initiate this logic?—then select the script type that matches that trigger and the required level of data access.