Scripts is the add-on for the cases where the built-in features are not enough: to pull data out of an external system, send it where it is needed, or count something your own way. A script is a small self-contained piece of Python code that lives next to the product’s data, is switched on and off as needed, and leaves a line about every run.
Why your own code
The product ships a wide set of ready-made actions, but life is inventive: one customer keeps their warehouse records in an old system, another counts prices in a spreadsheet on a shared drive, a third needs to reconcile customers with an external service every night. Writing a dedicated feature into the product for each such case is slow, and sometimes simply impossible to foresee. Scripts close that gap: the code is written by your engineer or by an AI agent, while the product takes care of running it, the access it gets, the journal and the limits.
Where a script’s description lives
A script’s description lives in the settings tree next to the product’s data: a separate file per script, and the file name is the script’s name. Beside it sits the section’s own settings file: the master switch for scripts, the default waiting time, the number of simultaneous runs and the journal retention. All of it is ordinary settings that go into the shared edit history together with the rest of the product’s data, so you can see who changed what and when.
The code itself can be written straight into the description or kept in a separate file in the same folder. In the second case, edits apply from the next run onwards with nothing to restart or rebuild. Descriptions are changed through the agent: every edit is validated first, and a faulty one simply does not take effect — the last working version keeps running, and the error is visible in the answer. Previous versions of descriptions are kept, so something spoiled can always be brought back.
If scripts need third-party libraries, the list of them lives in the same folder, and the product installs them once into a shared environment that all scripts use. There is no separate set of libraries per script — a deliberate simplification: it is easier to update and avoids keeping a dozen different environments.
Four connection points
The same script can be used in four ways:
- On a schedule. The description says “every N minutes”. The product itself watches for the right moment, never starts the same script twice at once, and does not lose its footing if one run failed: the schedule stays, and the next run comes at its own time.
- By hand. A “Run script” button — for checks and one-off tasks. What happened during the last runs is visible right there, in the scripts console.
- Receiving outside data. A script can have a protected address to which an external system sends data, presenting a secret key. That way any external service — a website, a warehouse program, a payment provider — can hand events straight to the product, without the product itself being modified. The key is stored hidden and never shown back; a foreign attempt without the key is refused and starts nothing. There is also protection against a flood of calls: overly frequent requests are slowed down.
- As an automation step. A rule or process gets the action “run script”, naming the script and its parameters. If the name does not exist, the rule simply will not save — the product names it. If a step fails, the reason is visible in the step’s journal.
What a script sees and what it returns
A script has a simple contract with the product. As input it receives a description of what happened: which connection point started it, for which reason (schedule, manual, an outside call, an automation step), which record is involved and what data came with the event. The script answers with a single reply in the agreed format, while everything it printed along the way for its own debugging the product simply ignores.
For its own needs — remembering where it stopped, saving an intermediate file — every script has its own working folder whose contents survive between runs.
Of the environment variables a script sees only its own: those listed in its description. The product’s management key, passwords and the data store address are not available to it — it receives exactly what was written out for it. The values of secret variables are replaced with asterisks on read: a secret cannot be looked at through the description, and overwriting it with random emptiness by accident is not possible either.
Journal and limits
Every run leaves exactly one line in the journal — even if the script died outright. You can see the script’s name, the connection point, the reason it was started, the start time and duration, how it ended, the exit code and the cause of the error. Emergencies are distinguishable by kind: scripts switched off, Python unavailable, time exceeded, an error in the code, an invalid answer, too much data. The journal is kept for 30 days by default, and the term is configurable.
The limits are visible numbers too:
- The time of one run — one minute by default, ten minutes maximum; if a script hangs, it and every process it started are killed forcibly.
- Simultaneous runs — two by default: scripts cannot take all of the server’s strength.
- The amount of data on input and in the answer — up to one megabyte; anything larger is refused with a clear reason rather than quietly trimmed.
- A master switch — one setting turns every script off at once. The run then honestly records “disabled” instead of pretending everything is fine.
Where trust begins and ends
Let us say it plainly: there is no sandbox. A script runs with the product’s own process rights — it sees the same files and has the same network access as the server everything runs on. That is a deliberate choice: the code is considered trusted, written by your engineer or your agent, and it lives in the settings tree next to the data, which means it lands in the shared edit history.
A few simple rules follow from that:
- run only those scripts you trust as much as your own code;
- only Python is supported — another language will not do;
- references to code files are allowed only inside the scripts folder — you cannot step outside it;
- the product never shows secrets from a description back and never writes them into the journals;
- if you need real isolation, run the scripts on a separate instance of the product.
The limits above are working limits, not security limits: they save you from hung runs and a flood of data, but they do not separate the code from the rest of the system. That is exactly what the product’s own reference says: this is trusted code from a trusted operator, and it deserves to be treated as such.
Next → Management API