Skip to main content

Write a Solution Script

Goal​

Write a piece of logic once — "is this expense over the approval limit", "format a reference the way this customer writes it" — and call it from every business rule and command that needs it, instead of pasting the same lines into each one.

Prerequisites​

  • You are signed in as a maker, with a solution and an environment selected.

Steps​

  1. Open your solution and choose Scripts.

  2. Select New. The designer opens with a small example already in it.

  3. Give it a display name. The module path fills itself in as you type — that is the name other scripts will import, and it cannot be changed after you save.

  4. Write your helper, and export it:

    func isOverLimit(amount: int, limit: int): bool {
      return amount > limit;
    }

    export isOverLimit;

  5. Select Save.

Under the name box the designer shows the exact line to copy: import 'par_expense_helpers';

Calling it from a business rule​

You do not have to remember the module path. In the business rule designer, open the Solution scripts panel on the right: it lists every script in the environment, and Import writes the line at the top of your rule for you. A script the rule already imports is marked Imported rather than offered twice.

If the environment has no scripts yet, the panel says so and offers New script, which opens the script designer in a new tab — your unsaved rule stays where it is.

The line it writes is the same one you would type. Everything the script exports is then available as if you had written it there:

import 'par_expense_helpers';

setVisible('par_approval', isOverLimit(getValue('par_amount'), 100));

You can import a single name instead, if you prefer to be explicit about what you are using:

import isOverLimit from 'par_expense_helpers';

The same import works in a command's script. A script belongs to the solution, not to a table, so a rule on Invoice can call a helper written for Expense.

export is not optional​

A script binds only what it exports. A helper you forget to export is invisible to everything that imports the script — so the designer refuses to save one that exports nothing, and says so. That refusal is deliberate: without it, the script would save happily and the failure would land somewhere else entirely, as "function not found" inside a rule you were not looking at.

You can export several names from one script:

export isOverLimit, formatReference;

What travels, and what happens when it does not​

A script is a solution component. It exports with its solution and is installed before the rules that import it, so a package always arrives in a working order.

If a rule imports a script the environment does not have — because it was deleted, or because the solution that provided it was not imported — the rule fails by name, both in the editor as you write it and at runtime. Nothing fails silently.

Troubleshooting​

"Script … exports nothing." Add an export line naming the functions you want to share.

"BS Lang script is invalid: line …" The source does not parse. The editor underlines the problem and the problems list under it names each one; select a row to jump to the line.

A rule says my function is not found. Three things to check, in order: the rule has the import line; the module path in it matches the script's exactly; and the script exports that function by name. The Solution scripts panel writes the first two for you. A quick check for all three: on an empty line of the rule, press Ctrl+Space. Completion lists every function the import brought in, so a function missing from the list is one the rule cannot call.

The panel is empty but I know there are scripts. The list is the environment's, so a script saved in another browser tab appears after you reopen the rule.

I cannot rename a script. Correct — the module path is what every importing rule names, so renaming it would break all of them at once, silently. Create the new one and retire the old.