Runnable Editor

The runnable editor sits in the bottom panel of the app editor. It’s where the actual logic behind an app lives: every script or flow a component calls, plus any background runnables that aren’t tied to a specific component, get written and edited here.

Panel structure

The panel is split in two:

Runnables list: every runnable in the app, click one to open it.
Runnable editor: the selected runnable’s code, with full editing.

Header components

Above the code editor, the runnable’s header gives you:

An editable runnable name, with a small dot next to it that turns red if Orvanta can’t currently parse the runnable’s main function signature.
A tag popup, for pinning the runnable to a specific worker tag.
A cache button, for configuring result caching (see Caching app inline scripts below).
An Orvanta AI button, to generate or edit the code from a prompt.
An editor settings button.
A delete button, to remove the runnable.
A “Full Editor” button, which expands the runnable into the full-screen script editor drawer.
A Format button (also triggered on save).
A Run button, to execute the runnable immediately.

Types of runnables

Inline scripts

Written directly inside the app editor and attached to a single component — the most common way to give a component its data or its action.

Workspace/Hub runnables

Instead of writing a new inline script, a component can call an existing script or flow from the workspace or from the Orvanta Hub.

Background runnables

Not attached to any single component. They run server-side on app refresh or when their inputs change, and their result can be reused by any component that references them — useful for a query several components need without re-running it per component.

Frontend scripts

Plain JavaScript that runs in the viewer’s browser instead of on a worker. Frontend scripts can read and write client-side app state directly and have access to the frontend script helpers. Like other runnables, they can be attached to a component or run in the background.

Evals

A lightweight inline expression (not a full script) used to connect one component’s output, or a runnable’s result, into another component’s parameter. By default an eval only re-runs when the values it reads actually change; this can be turned off per-eval.

Runnable configuration

Transformer

An optional frontend script that runs right after the component’s runnable finishes, receiving its output as result. Use it for a quick browser-side reshape of the data (renaming a field, filtering an array) without needing a second server-side runnable.

Triggers

Run on start and app refresh: for background and data-source runnables, whether they fire automatically when the app loads or is refreshed.

Recompute on Any Input Change: for background and data-source runnables, whether a change to any of their inputs re-triggers them. Individual inputs can be excluded from this.

Trigger runnables on success: lets a button, form, or background script kick off another component’s runnable once its own execution succeeds.

Connection configuration

Static connection select only / Connections from users allowed: apps run on behalf of their publisher by default, so a viewer’s own connections aren’t normally usable. If a runnable’s input should be allowed to come from a viewer-supplied Connection select component rather than only the publisher’s static one, enable “Connections from users allowed.”

Manual dependencies

For frontend scripts, you can list dependencies by hand so the script re-runs when those specific values change, instead of relying on automatic dependency detection.

Caching app inline scripts

To avoid re-running an inline script every time its component is triggered with the same inputs:

Open the Cache popup from the runnable’s header.
Toggle “Cache the results for each possible inputs”.
Set a cache duration, in seconds.

While the cache is still valid, re-triggering the script with an input combination it already has cached returns the stored result instantly instead of running the script again.

Frontend scripts helpers

Global variables and functions

Helper	Description
`ctx`	Access the context object containing app metadata like email.
`state`	Client-side store for data persistence. Updates require reassignment for reactivity.
`goto(path, newTab?)`	Navigate to specified URL; optionally open in new tab.
`setTab(id, index)`	Set active tab for tab components by ID and index.
`recompute(id)`	Recompute a specific component by ID.
`globalRecompute()`	Recompute all components and trigger their runnables.
`getAgGrid(id)`	Retrieve the AG Grid instance of a table.
`setValue(id, value)`	Manually set a component value.
`setSelectedIndex(id, index)`	Select a table row by index.
`open(id)`	Open a modal or drawer component.
`close(id)`	Close a modal or drawer.
`validate(id, key)`	Mark a form field as validated.
`invalidate(id, key, error)`	Invalidate a form field with an error message.
`validateAll(id)`	Validate all form fields.
`clearFiles(id)`	Clear file input files.
`showToast(message, error)`	Display a toast notification.
`waitJob(jobId)`	Wait for job completion (returns a promise).
`askNewResource(id)`	Request user connection creation on a UserResourceComponent.
`downloadFile(input, fileName?)`	Download a file from URL, base64, dataURL, or S3 object.

Security policy

When you deploy an app, Orvanta computes an execution policy from it: the exact set of scripts and flows the app is allowed to call, and their static parameters, as they exist at deploy time. Viewers run the app on behalf of its publisher against that frozen policy — they can’t call anything outside it and can’t override a static parameter with their own value, so an app can’t be used to reach a connection or a runnable it wasn’t built to expose.