Configure the form
Configure the form
A form describes what and how to extract: fields with stable ids, the prompts extraction follows, and the model configuration. There are two ways to define one:
- Configured in the workspace — your code only holds its reference; fields, prompts and models change without a release.
- Defined in code — a plain object shipped with your app, recorded in your workspace on first use.
Both produce the same sessions and the same values; they differ in who changes the form and how a change reaches production.
| Configured in the workspace | Defined in code | |
|---|---|---|
| Where the definition lives | In your workspace. Your code names it: key, version, language. | In your code, as a form object built with FormField. Recorded in your workspace on first use. |
| Change fields or prompts | Edit a draft, publish — no release of your app. | Edit the code, deploy. |
| Who works on it | Anyone with workspace access — product, ops, a prompt engineer. | Developers, in the repository, with code review. |
| Testing prompts | The Engineer tab: speak, watch what lands, adjust. | From a local deployment. |
| Choose it when | The form's wording will keep evolving after launch, or non-developers own it. | The form is generated, per-tenant, or you want one source of truth in the repo. |
In this section
- In the workspace
You configure the form in your workspace: what a form is, the Define page and the import, Engineer for prompts and testing, and the form's Settings.
Overview · Define the form · Engineer the extraction · Settings
- In code
You define the form with FormField in your app: factories, prompts in code, version strings, and generated definitions.
source · key · version · language · fields · prompts · models
Next: the workspace needs an API key in the right mode before code can name the form — Authentication and usage.