Create a form

Catalyst chat on the left describing a laptop request form, with the form workspace on the right showing version v3 Published, the Check Laptop Stock workflow that runs inside the form, and a live preview of the laptop card grid — Building a form with Catalyst. The workspace on the right previews it live.

Build it

New form

In the compact rail, go to Library → Forms → New form. In the classic sidebar, open Forms in the Service Management section, then select New form. Serval opens the Create a new form gallery with three ways to start:

Describe your form in the top Create a form that… box and let Catalyst build it (the path this guide follows).
Under Or start from a working form, pick a ready-made template such as a laptop request, expense claim, or discount approval. Each template comes with a working submit workflow, so you can submit the new form right away and edit it from there.
Choose Create blank form to open an empty Untitled form.

Whichever you choose, Serval opens the workspace on your new form.

Describe what you want

Be specific about the questions, the options, and what happens on submit:

Create a laptop request form. Options should be MacBook Air, MacBook Pro 14-inch, Lenovo ThinkPad, and Dell Latitude, shown as cards with product photos. Require a business justification. Let people optionally say who it’s for and when they need it. On submit, file an IT ticket with the chosen model.

Refine it

Keep talking to Catalyst: “make the justification field longer,” “only ask for a manager if it’s for someone else.” Each change re-renders the preview.

Name the form before publishing. The name is what employees see in the catalog and what the Help Desk Agent reads to decide the form fits a request. “Laptop Request” beats “IT Form 2.”

The workspace

Area	What it does
Preview	The real form, rendered by the real engine
Can be opened by	Which employees may open and submit it. See audience
Runs inside the form	Workflows called while the form is open, to fetch live data
Runs on submit	The workflow that receives the answers
Version selector	Switch versions, and see which one is published
Publish	Deploys the current draft
Run history	Every session, and the runs it started
Open in service catalog	The published form, exactly as employees see it
Code (`</>`)	The form’s source

Preview and publish

The preview is a live session against your draft. Conditional fields appear, validation fires, and live-data workflows run.

A preview submit runs the latest submit workflow for real, even as an unpublished draft. It doesn’t publish your drafts, but side effects still happen: a ticket, provisioned access, a message.

Edits autosave to a draft. The action bar shows Unpublished changes when your draft differs from what’s live. Click Publish to deploy it.

Publishing never disturbs a submission in progress. A session stays on the version it opened against.

If a publish fails, the error names the problem in the code: an unknown option, an invalid icon name, a workflow reference that doesn’t resolve. If the error says a published form or workflow already uses the name, choose a name that is unique in the workspace where you are publishing. The failed update keeps the existing published version available. For a failed promotion:

Switch to the source workspace and open the form from Forms.
Rename and publish the source form.
Create a fresh review containing the updated form and select Apply promotion. Retrying the saved promotion uses its original name, even after you edit the source.

Independent resources can still apply when one form fails. Check each resource’s status before preparing the recovery review.

The code behind a form

Catalyst writes it, and most builders never open it. It’s under the </> button when you want it.

import { view, field, Form } from "serval/forms";
import orderLaptop from "@serval/workflows/order-laptop";

export const main = view({
  fn: () => {
    const [model, Model] = field.cards("model", [
      { value: "mba", label: "MacBook Air (M-series)", description: "Lightweight macOS laptop for everyday work and travel." },
      { value: "mbp", label: "MacBook Pro 14-inch", description: "High-performance macOS laptop for engineering and design." },
    ], { label: "Choose your laptop" });

    const [justification, Justification] = field.text("justification", {
      label: "Business justification",
      multiline: true,
      maxLength: 500,
    });

    return (
      <Form
        header={{ title: "Laptop Request", subtitle: "Request a new laptop from IT", icon: "laptop" }}
        submit={{ workflow: orderLaptop, args: { model, justification } }}
      >
        <Model required />
        <Justification required />
      </Form>
    );
  },
});

field.<type>(key, …): declares a question, returns [value, Component]
<Form>: the root. header sets the title band, submit names the workflow, and accent / density pick the look
Placement props: required, readOnly, and error go on the component, not the declaration

Because the value is an ordinary variable, logic is ordinary code: {model === "mbp" && <Justification required />}.

Form code runs in a sandbox with no network, no filesystem, and no credentials. The only way it can cause work is by naming one of your workflows, and every call is re-authorized on the server.

Fields and layout

The field-type and validation reference.

Logic and workflows

Conditional questions, live data, and the submit handler.

Overview

End User

Platform

Administration

Help Desk

Ticketing

Catalyst

Workflows

Forms

Skills

Knowledge Base

Databases

Access Management

Journeys

Suggestions

Campaigns

Team Solutions

CLI

Self-Hosting

Build it

The workspace

Preview and publish

The code behind a form

Fields and layout

Logic and workflows

​Build it

​The workspace

​Preview and publish

​The code behind a form

Fields and layout

Logic and workflows

Build it

The workspace

Preview and publish

The code behind a form