Writing Settings Forms

A settings form (settingsForm) is the form the Celigo UI renders to collect a resource's settings: which fields appear, their labels and choices, how they're grouped, and which show when. The values it collects are stored in the same resource's settings, and that's what steps read at run time -- {{settings.flow.region}} in a template, options.settings.flow.region in a script.

Seven places carry a form, each with its own settings: an integration, each of an integration's flow groups (flowGroupings[]), a flow, an export, an import, a connection, and an iClient. An Integration App's settings are a different mechanism, driven by the app's own code -- see managing-integrations > Integration Apps.

What a form is not:

• Not validation. Only the UI renders the form and applies its rules. An API, CLI, or MCP write of settings stores the object it's given: a field the form marks required can be missing, keys the form doesn't define are kept, and nothing checks types or choices.
• Not checked on save. A layout entry or a condition naming a field the form doesn't have is stored as sent. Only form and init are kept: any other top-level key in settingsForm is dropped without an error.
• Not what steps read. Steps read settings, never the form. A new field gives steps nothing until its value is in settings, so write the value along with the field.

How to Run the Steps

This skill names each step by what it reads or changes; the exact calls depend on how you reach the account. Read the one reference that matches your tools -- both follow the step numbers of How to Build a Settings Form, then How to Check a Form: