Studio Help · Forms

Concept of Forms

In Studio, a form is more than a set of visual fields on a page. It is an autonomous functional entity, with its own lifecycle, that collects structured data, validates information, triggers notifications, stores submissions, and makes data available for consultation and export.

General concept of a form

In practice, the form has two complementary dimensions. The functional dimension defines submission behaviour, messages, notifications, data storage and export logic. The visual dimension organises field blocks, hierarchy, layout and the filling experience.

Form mental model

Structure before layout

In Studio, the form should first be conceived as a data collection structure, and only afterwards as a layout. The team should define the objective, the essential data, the recipient of the information and the actions after submission before creating the visual fields.

Objective

What the user is expected to do or deliver.

Data

Which fields are essential for the action in question.

Destination

Who receives the submission and how it is followed up.

Response

What the user sees or receives after submission.

Simple reading: first define the logic of the form, then design how that logic is presented to the user.

Lifecycle of a form

From creation to submission

The lifecycle of a form in Studio includes the following steps.

Creation of the form entity in the backoffice.
Configuration of the initial setup and messages.
Definition of internal and/or automatic notifications.
Visual construction with the appropriate input blocks.
Publication of the form on a page.
Submission by the user.
Storage of the response and later consultation or export.

When it makes sense to use a form

When to use and when to avoid

When to use

Contact requests
Registrations
Applications
Restricted downloads
Quote requests
Feedback collection
Internal processes that require centralised information

When to avoid

When the action can be resolved with a button, link or phone call
When the effort required to fill in the form outweighs the value of the information collected
When there is no real need to collect structured and comparable data

Practical rule: if you are not going to use the collected information in a useful way, the form probably should not exist — or it should be shorter.

Quality criteria of a good form

Clarity, usefulness and consistency

Clear objective immediately understandable to the user.
Number of fields compatible with the intention and context.
Messages, labels and CTAs that are consistent and understandable.
Useful data for the team, without unnecessary redundancies.
Submission flow tested from start to finish, including notifications and export.

Cross-cutting best practice: a form should not be evaluated only by its visual appearance. It should be thought of as a complete flow: collection, validation, delivery, storage and follow-up.