Auto-generated UIs

When a script or flow declares its inputs, Orvanta automatically generates a form to collect those inputs, with no front-end code required. This is the input form you get whenever you run or test a script or flow — from the editor, from its deployed page, or from a schedule or trigger that needs input. The form is derived from the input schema, so it stays in sync with the code.

How it works

A script’s inputs are inferred from the parameters of its main function. From the signature, Orvanta infers:

• the fields to render,
• their types (string, number, boolean, object, …),
• which are required,
• and any default values.

def main(customer_id: str, dry_run: bool = False):
    ...

The example above renders a required text field for customer_id and a checkbox for dry_run that defaults to off.

Type-to-control mapping

Declared type	Rendered control
string	Text input
string with enum	Dropdown
boolean	Checkbox
number	Number input
object	JSON editor

Where it shows up

• Testing in the editor. Before anything is deployed, the script or workflow editor renders the same form so you can run a test with real inputs.
• Running a deployed script or flow. Its page renders the form so anyone with permission can trigger a run without reading the code.
• Triggers that need input. A schedule or webhook that supplies static or mapped values uses the same schema to validate what it sends.

Why it matters

Auto-generated forms mean any script or flow becomes a self-service tool the moment it’s published, with no UI to design or maintain separately. Non-technical teammates can run it safely, with validation handled before execution. Because the form comes from the schema, there’s no separate UI to build or keep in sync when the inputs change — this is the only generated UI Orvanta produces; there is no separate app-building layer on top of it.

Related

• Scripts: Declaring inputs and outputs.
• Triggers: How inputs are passed when a run starts.
• Editor overview: Where forms are surfaced.