Form Composer

Form Composer Overview

The Form Composer is built into the Joget Form Builder. Instead of dragging fields and clicking through property panels, you describe what you need, and the composer builds it for you.

Everything it produces is standard Joget form configuration — the same output as the visual builder. No code.  Every form it builds is immediately editable in the builder.

One thing that makes it different from most AI builders: it reads the live component schema from your Joget instance. That means it knows every field type you have installed, including custom and third-party plugins, without any additional setup.

Getting Started

Open any form in the Form Builder. The composer panel is available on the bottom-right of the builder.

Two ways to start:

Describe it: type what you want. Fields, layout, requirements. The composer builds the structure.

Show it: upload a screenshot of an existing form, a wireframe, or a hand-drawn sketch. The composer replicates it as a Joget form.

Try this as your first prompt:

Build a clean, visually appealing health insurance form with comprehensive fields. Include clear placeholders, relevant icons, helpful hints, and make important fields mandatory where needed so the form is easy to understand and complete. Keep the layout intuitive and well-structured, with proper grouping, validation, and a polished, user-friendly feel.

Two Modes of Composing

Targeted Edit

Click any field or section on the form canvas. A composer prompt box appears directly on that component. Type your instruction and it applies the change to that field or section only — nothing else on the form is touched.

Use this when you want to:

• Change a specific field's label, placeholder, or properties
• Adjust styling on one section or column
• Make one field read-only or mandatory
• Swap one field type for another

Full Form Composition

Open the composer chat panel and describe what you want at a form level. Use this for bigger changes or building from scratch.

Use this when you want to:

• Build a form from a description or image
• Add a new section with multiple fields
• Restructure the layout across the whole form
• Make changes that span multiple fields at once

Reviewing Composer Output

After the composer runs, three options appear at the bottom of the panel.

Apply: saves the change to your form. Done.

Cancel: discards everything. The form goes back exactly to how it was before.

Nothing is permanent until you hit Apply.

What You Can Build

Form structure

The Composer can create and modify full forms based on simple prompts. You can:

• Build forms from scratch, text descriptions, or images/screenshots
• Create sections with single or multi-column layouts
• Add, remove, reorder, and update fields
• Apply styling to sections and fields (background, borders, spacing, labels, typography)

The Composer automatically organizes fields into logical sections and layouts based on context.

Fields

The Composer supports all field types available in your Joget Form Builder palette, including Basic, Custom, Enterprise, and Marketplace plugins.

You can describe fields naturally, and the Composer will map them to the appropriate components.

Some configurations require more explicit instructions to ensure accurate behavior, so being specific in your prompt will improve results and reduce the need for manual adjustments. Additionally, certain features, such as conditional visibility (showing or hiding fields or sections based on other field values), are not currently supported through the Composer and must be configured manually in the Form Builder (see Section 7).

Prompting Guide

To get the best results, focus on clarity and completeness in your prompt. The Composer performs best when the intent, structure, and requirements are clearly described upfront.

Describe the outcome, not just the field: Instead of asking for a field, describe how it should behave, including validation, formatting, default values, and constraints

✗ Bad: “Add a salary field.”

✔ Good: “Add a Salary field. Store it as a number, show 2 decimal places, include AED prefix with thousand separators, and make it mandatory.”

Be specific where it matters: The level of detail in your prompt directly impacts the quality of the output.

✗ Bad: “Add a leave type dropdown.”

✔ Good: “Add a Leave Type dropdown with options Annual, Sick, Emergency, and Unpaid. Make it required and include a placeholder ‘Select leave type’.”

Provide full context in a single prompt: When creating a new form, describe the structure, fields, and key requirements together to get a more complete result.

✗ Bad: “Add employee details form” (followed by multiple small prompts)

✔ Good: “Build an Employee Details form with fields for Name, Email, Department, and Date of Joining. Group them in a single section, make all fields required.”

Add advanced logic with clear instructions: For configurations such as data loading or dependent fields, include all necessary details so the Composer can configure them correctly.

✗ Bad: “Load departments from another form.”

✔ Good: “Add a Department dropdown that loads options from the department form. Use dept_id as the value, dept_name as the label, and include a blank first option.

Iterate with targeted refinements:  If adjustments are needed, refine specific parts of the form instead of restarting.

✗ Bad: “Redo the whole form.”

✔ Good: “Update the Salary field to include currency formatting, make it mandatory, and add helper text ‘Enter monthly salary in AED’.”

Current Behaviour & Tips

These are known behaviours as of April 2026 based on testing across all form component types. Where something does not work through the composer, the manual path is noted.

Validators do not apply through the composer

The composer can identify the right validator class and properties, and will tell you it has applied them. The validators do not get reflected in the form. This is consistent across all validator types — DefaultValidator, DuplicateValueValidator, MultiFormValidator, NumberValidator, PasswordValidator, BeanShellValidator, and JdbcValidator.

What to do: Build your form with the composer, then configure validators manually. Open the field, go to the Validators tab in the properties panel, and set them there.

Visibility conditions are not supported

Conditional sections — showing or hiding a section based on another field's value — do not work through the composer. The correct Joget pattern uses visibilityControl and visibilityValue properties on the Section element. The composer does not reliably produce this.

What to do: Build the form structure with the composer, then add visibility conditions manually on each Section in the Form Builder.

Hash variables need the exact format on the first prompt

If you describe what you want without giving the hash variable format, the composer often produces an incorrect format. For example, {currentUser:email} instead of #currentUser.email#.

What to do: Always include the exact hash variable format in your prompt. See the table in Section 6.

Complex nested configurations need detailed prompts

FormOptionsBinder, section-level binders, and post-processors work but need explicit instructions. A short prompt will get you part of the way. A detailed prompt that spells out every property gets you the full configuration.

For FormOptionsBinder, always include: form ID, form name, table name, value column, label column, and whether you need a blank first option.

Dependent forms must exist first

If you ask the composer to configure a dropdown that loads from another form, that source form must already exist in your Joget app. The composer wires the binder — it does not create the source form. Build your lookup or reference forms first, then use the composer to connect them.

Prompt Playbook

Video Tutorial