Create, test, version, and run scripts
Build an executable library entry with explicit parameters, test the current editor contents on one device, and inspect saved versions and results.
Before you start
- Know the target OS and interpreter required by the script.
- Use a suitable enrolled device for a real test; a test executes the current code on that device.
Screenshots show the Rapport interface with example data. Use your organization’s devices and values. Select an image to view it at full size.
Find an existing script or create one
Open Scripts. Search by name and use Platform, Language, State, category, and sort controls. Select a script to inspect it. To add one, use New Script, Starter scripts, or Generate with AI. Review any starter or generated body before running it.
Import a starter or generate a draft when useful
In Starter scripts, select the desired scripts by platform and click Add … to library; scripts already present are marked. In Generate with AI, fill Describe what the script should do, select Platform, Language, and Category, and click Generate. Review and edit the returned Name, Description, Script body, and Parameters. Use Refine for a specific revision, then Save to Library. Saving does not run the code.
Define identity and the runtime
In the editor, enter Name, Category, and Description, then choose Platform, Language, and Default timeout (seconds). Changing platform can change the available languages. Paste or write the executable code in Script body.
| Field or control | What to do |
|---|---|
| Default timeout (seconds) | Use 5–3,600 seconds. Individual runs can override it; timeout stops the script and is reported as exit code −2. |
| Enabled | Disabled scripts cannot be dispatched or scheduled. |
| Shared (read-only to others) | Other users view the saved shared script read-only; they can clone it to make their own edits. |
| Script body | Runs with the interpreter displayed below the editor. Line endings are normalized on save. |
Define parameters and use them in the code
Under Parameters, add each input with a unique Name, Type, optional Default, Description, and Required setting. Names use letters, digits, and underscores, start with a letter or underscore, and have at most 64 characters. Use the generated runtime help to map each definition to the script.
| Field or control | What to do |
|---|---|
| string / int / bool | Free text, a whole number, or a true/false value; defaults must match the selected type. |
| secret | A masked input passed through an environment variable. Its argument slot is empty and values are masked in run history. |
| Environment | Each input is exported as DEXIQ_<NAME> with the name uppercased. Use the runtime help for the selected language’s syntax. |
| Parameter order | Move up/down changes positional ordering. Avoid assuming that a reordered input still has the same argument position. |
Run the current draft on one test device
Open the editor’s test panel, choose one compatible endpoint, and fill Parameter values. Click Run test. This uses the code currently in the editor, saved or unsaved, as a short-lived draft; it is a real execution and follows approval policy. Inspect the stage, output, and exit code before choosing Run again.
What you should see: You have a recorded test result for the exact current draft on a particular device. Saving the script is still a separate step.
Save and maintain versions
Choose Create script or Save changes; Ctrl/Cmd+S is also supported. Existing scripts have a versions panel where View opens a prior body and Restore asks for confirmation. Save or intentionally discard local edits before restoring. For a shared script you do not own, choose Clone to create an editable copy.
What you should see: The library contains a saved script and a version history that can be inspected independently of test runs.
Run or schedule the saved script
Open the script’s detail page. Review Overview, use its run action to open Run a task with the script selected, or use Schedules for recurrence. A disabled script must be enabled before dispatch. Review parameters and target compatibility again for a production run.
Inspect Results and rerun a known target
Use Results on the script detail page to inspect recorded executions. Expand a row for stdout/stderr, truncation indicators, duration, and exit code. A Run again action returns to the task flow for that device so you can review the next request. Use Refresh result history from the library if result coverage is stale.
What you should see: The saved definition, test evidence, schedules, and execution results are all traceable.
If something doesn’t work
A parameter cannot be saved.
Check its name, uniqueness ignoring case, type, and default. Integer defaults must be whole numbers; boolean defaults must be true or false.
No test devices are eligible.
Check Platform and Language together, then refresh the endpoint picker. A device with an incompatible OS will not be eligible.
The editor is read-only.
The script is shared and belongs to another user. Use Clone and edit your copy.
A test succeeded but the library run behaved differently.
The test may have used unsaved editor contents. Compare the saved version, parameters, timeout, and target device with the test.