Forms, Input Widgets, Data Binding, and Feedback Messages

Quick Answer: The Form widget groups Input widgets and exposes a Valid Boolean you check before submitting. Input widgets bind to a Screen Variable or entity attribute via the Variable property for two-way binding. Mandatory and the Email data type provide built-in validation. Feedback Message is a toast triggered by ShowFeedbackMessage. Scaffolding from an entity auto-generates a working Form, Inputs, and Save action.

Form Widget

The Form widget is a container specialized for collecting user input. It groups Input widgets and exposes a Valid Boolean that aggregates the validity of all child Inputs based on their Mandatory and type settings. The standard submit pattern: a Button with Is Form Default = true runs a Client Action whose first node checks Form.Valid; only if true does Save logic proceed.

Exam trap: Form.Valid is the gate. If you run your CreateOrUpdate entity action without checking Form.Valid first, invalid data (empty mandatory fields, malformed email) will still be submitted. The idiomatic flow is If Form.Valid → CreateOrUpdate → Feedback Message(success) → Navigate back; Else → ShowFeedbackMessage(error).

Input Widget and Two-Way Binding

The Input widget collects a single typed value — text, number, date, boolean, email, password. Its defining property is Variable, binding the widget to a Screen Variable, local variable, or entity attribute. This binding is two-way: when the user types, the bound variable updates; when the variable changes in code, the displayed value updates. You write no getter/setter code — the binding handles both directions.

The Input Type determines the HTML input type rendered and the client-side validation. Email renders <input type="email"> and validates email format automatically — no regex needed. Integer and Decimal restrict input to numeric characters and validate on blur.

Built-in Validation

OutSystems provides two layers of built-in validation:

1. Mandatory property: when checked on an Input, the field must have a value. If empty, the Input is marked invalid, a validation message appears, and Form.Valid becomes false.
2. Type validation: the Input Type enforces format. Email validates the email pattern; Date validates a date; Integer/Decimal validate numeric values.

Validation messages are auto-generated (e.g., "This field is required") and can be overridden via the Input's Validation Message property. Validation triggers on blur or Form submit. The sequence the exam tests: user submits → Form validates all Inputs → if any invalid, Form.Valid is false and messages display → the Client Action checks Form.Valid before proceeding.

Data Binding to Screen Variables and Entities

Binding targets fall into two categories:

• Screen Variables / Local Variables: lightweight, screen-scoped state. Bind an Input's Variable to a local variable when collecting non-persistent data (e.g., search filters, a new record before save). Example: NewCustomerName local variable of type Text.
• Entity attributes: bind directly to an entity attribute when editing a fetched record. Example: after fetching GetCustomer.List.Current.Customer, bind the Input's Variable to GetCustomer.List.Current.Customer.Name. Edits write back to the fetched record in memory; the Save action then calls CreateOrUpdate to persist.

Exam trap: binding an Input directly to an Aggregate's List.Current attribute is valid and common, but you must call CreateOrUpdate (or Update) in the Save action to persist changes — editing the Input does not write to the database automatically. The binding only updates the in-memory record.

Feedback Message (Toast)

The Feedback Message is a toast notification at the top of the Screen, triggered by the ShowFeedbackMessage built-in Client Action. Properties:

Typical usage after a Save: ShowFeedbackMessage with Type = success and Message = "Customer saved successfully", then Navigate back to the list. On validation failure: Type = error, Message = "Please fix the highlighted fields". The widget sits on the Screen; ShowFeedbackMessage toggles its Show property and sets Message/Type.

Scaffolding-Generated Edit Screens

When you right-click an entity in Service Studio and choose "Screen for Entity," OutSystems generates a complete edit Screen: a Form bound to the entity, Input widgets for each attribute (with correct types and Mandatory flags), and a Save Button running a Client Action that checks Form.Valid, calls CreateOrUpdate, shows a Feedback Message, and Navigates back. This is the fastest path to a working CRUD screen. Understanding what scaffolding produces — and that Form.Valid gates the Save — is high-yield.

The generated Save Client Action flow is the canonical pattern to memorize:

1. Button (Is Form Default = true) OnClick → Client Action
2. If Form.Valid = false → ShowFeedbackMessage(error) and exit
3. CreateOrUpdate entity action (writes to database)
4. ShowFeedbackMessage(success)
5. Navigate to list Screen

This pattern ties together Form, Input, binding, validation, Feedback Message, and Navigate in one flow — a large share of Screen Widget exam questions.