License availabilityAi Chat: Custom add-on only

Scripts

Overview

The Scripts page is the catalogue of every shared, reusable script on the platform. Scripts are small, named pieces of source code — Aster expressions, XSLT stylesheets, XPath queries, Regex patterns, plus free-form JSON, XML, and Template assets — that participate in integration testing. They are typically used to transform payloads, evaluate conditions, or assemble validation logic during test-case design and execution. Scripts also power features elsewhere in the platform: an Aster script can serve as a custom validation that runs after the result comparison of a test run, or as a transformation step in a business-object action.

Aster is the platform's own scripting language, purpose-built for shaping payloads and variables during testing. It exists so that a power user can express data transformations and bespoke checks that the standard, no-code configuration cannot capture — without leaving the testing platform. One property is worth understanding before you write one: an Aster script does not, by itself, mark a test as passed or failed. Ordinarily it just shapes data, and the only way it can force a test to fail is by failing itself — a typo, an invalid operation, an undefined function, or an explicit stop in the script. The single exception is a custom validation, where the script deliberately returns a pass/fail verdict (see Tips & edge cases).

Custom validations are the place where you write arbitrary check logic that the built-in payload comparison cannot express — for example, asserting a relationship between two values, or a condition that depends on data the comparison does not look at. The script must return a truthy verdict for the test to pass, and it can also return an extra table to be shown alongside the verdict on the test-run report. An automation object can attach such a script so that the check runs automatically after the normal result comparison.

Each script has a human-readable identifier (for example, Z_MY_TRANSFORM) and is version-controlled: every edit creates a new version while preserving the previous one for history and revert. Scripts in this catalogue live in a flat, shared namespace — they are not organised in folders and they are not scoped to a project — so the same script can be referenced from anywhere in the platform that supports scripting. Scripts that belong to a specific automation object are managed inside that automation object and do not appear in this list.

From this page you can browse the catalogue, search for a script by ID or description, open a script to view or edit it, create a new one, or check where an existing script is referenced before changing or removing it. Four of the seven script types (Aster, XSLT, XPath, Regex) can be executed directly; the remaining three (JSON, Template, XML) are stored as versioned text assets that other parts of the platform consume.

Tasks

How to create a new script

1. Click Create New in the toolbar.
2. The script editor opens. Enter a script ID (any text up to 100 characters — a short, recognisable name like Z_MY_TRANSFORM is recommended), pick a type, optionally write a description, then enter the source code.
3. Save. The new script appears in the list at version 1.

Script IDs must be unique across the shared catalogue. If you try to save a script whose ID is already taken by another current script, the save is refused.

How to check where a script is used before changing or removing it

Scripts can reference other scripts through INCLUDE('...') or LOAD('...') calls in their source. Before you rename or delete a script, check its consumers.

1. Click a row to select it (the row becomes highlighted).
2. Click Where Used in the toolbar.
3. A dialog opens listing every other script whose source mentions the selected script. Each row links to the consumer; click through to inspect it.

If no other script references the selected one, the dialog reads This script is not referenced by any other scripts..

This check is also enforced automatically: deleting a script that is referenced by another script is refused with an error message naming the consumers.

Note that the dialog only lists other scripts. Automation objects that use the script as a custom validation, and business-object actions that use it as a transformation step, are not listed here and do not block deletion — check those configurations separately before removing a script.

Field reference

Column	Description
Script ID	The human-readable identifier of the script, unique within the shared catalogue. Click to open the script. Any text up to 100 characters is accepted; avoid quotes and parentheses, since other scripts reference this one by quoting its ID.
Type	The kind of script. One of Aster (default), XSLT, JSON, Template, XPath, XML, Regex. Only Aster, XSLT, XPath, and Regex are directly executable; JSON, Template, and XML are stored verbatim for downstream consumers.
Description	Short label describing the script's purpose. Optional, up to 500 characters.
Version	The version number of the current row. Increments by one each time the script is edited.
Last Modified	When the current version was saved, shown as a relative date (for example, "3 days ago").
Modified By	The user who saved the current version.

If the list is empty, the grid shows No scripts found. If loading fails, it shows Failed to load scripts (or the specific error message returned by the platform).

Tips & edge cases

• Scripts are never edited in place. Every save creates a new version, and the previous version is preserved. The list always shows the current version; use the script detail page to view history or revert.
• Renaming a script can silently break callers. Other scripts call this one by its script ID, not by an internal identifier. If you change the script ID of a script that other scripts INCLUDE or LOAD, those callers will fail the next time they run. Use Where Used first to assess the impact.
• Deletion is blocked when other scripts reference this one. Up to five blocking callers are named in the refusal message; resolve those references (rename, remove, or rewrite the callers) before retrying the delete.
• "Where used" is text-based. The platform looks for INCLUDE('name') or LOAD("name") in script source. A script ID that appears in a comment or a quoted string still counts as a reference (could falsely block deletion). Conversely, an INCLUDE whose name is computed at runtime is not detected — such a caller will not appear in Where Used and will not block deletion, but it will fail at execution time.
• "Where used" does not cover non-script consumers. Custom validations on automation objects and transformation steps in business-object actions reference scripts directly; they are not shown in Where Used and do not block deletion. Deleting a script those features depend on succeeds — and the dependent test run or action fails the next time it runs.
• Pick clean script IDs. Any text is accepted as a script ID (which makes importing legacy scripts with unconventional names possible), but an ID containing quotes or parentheses cannot be reliably referenced from other scripts via INCLUDE/LOAD and may evade the "where used" check. Stick to letters, digits, and underscores for scripts you intend to reuse.
• Aster scripts can call the platform's AI model. The LLM_BASIC_REQUEST function sends a one-shot prompt to the configured AI provider and returns the response text. It is available only when your licence includes the AI chat feature; without it, the script stops with an error. The call also waits for the AI provider, so a slow provider slows the script down.
• Aster scripts can act as custom validations. A custom validation is the one situation where a script gives a test an explicit verdict: it is check logic you write to assert something the built-in payload comparison cannot. A script whose result is a two-element array — a pass/fail verdict followed by a table in JSON form — is recognised as a custom validation. The verdict element decides pass or fail; the optional table element lets the validation render its own extra table on the result report. Running such a script from the script editor previews the verdict and the same table that would appear on a test-run report. Automation objects use these scripts to add extra checks after the result comparison of a test run.
• A script can be shared or private to one automation object. The scripts in this catalogue are global — shared across the whole platform. An automation object can also own private scripts that belong only to it; these are managed inside the automation object and used for that object's variable processing, payload processing, and custom validations rather than platform-wide. Private scripts never appear in this list, in script pickers, or in global search.
• Three types are not executable. Saving a JSON, Template, or XML script stores it as a versioned text asset; trying to run it from the script detail page reports that the type is not executable. Use these types when another part of the platform consumes the asset.
• Script execution leaves no audit trail of runs. The version history of the script itself is kept (who saved what, when), but individual runs are not recorded. If you need a permanent record of an execution, capture the output yourself or run the script as part of a test case.
• The catalogue is global — but shows shared scripts only. There is no folder scoping or project scoping for scripts; everyone with Script: Read sees the same catalogue. Plan script IDs accordingly — a prefix convention (for example, Z_TEAM_…) helps avoid collisions. Scripts that belong to a specific automation object are managed inside that automation object and never appear in this list, in script pickers, or in global search.

Prerequisites & permissions

About permissions. Int4 Suite controls what you can see and do through roles and permission groups assigned to your user. Each role grants permissions on a specific resource (for example, Test Case, Automation Object, System Under Test) at one of four levels: Read, Write, Delete, or Execute. Some permissions are further narrowed by project scope, so you may have access to one part of the system but not another.

If a button is disabled or a list comes back empty, missing permissions are the most likely cause. Ask an administrator to review your role assignments, or check IAM → Users if you have the User: Read permission.

Specifically for this page:

• Seeing the list and opening a script requires the Script: Read permission.
• The Create New action requires the Script: Write permission.
• The Where Used action requires Script: Read (it does not modify anything).
• Editing, copying, and reverting a script require Script: Write.
• Deleting a script requires Script: Delete.
• Running a script (from the script detail page) requires Script: Execute.

Scripts are not scoped to a project or folder — anyone with Script: Read sees the entire shared catalogue.

Was this page helpful?Send a quick note to the documentation team.

0 / 2000 characters