Forms, Input Widgets, Data Binding, and Feedback Messages

OutSystems Certified Associate Developer Reactive Web Apps

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Exam Overview, Logistics, and Study Strategy

2 Chapter 2 — OutSystems Platform and Reactive App Fundamentals

OutSystems Platform Architecture, Service Studio, and Development Tools Client Variables and State Management Screen Lifecycle Events: OnInitialize, OnReady, OnParametersChanged Debugging and Monitoring with the Service Studio Debugger and Service Center

3 Data Modeling

Entities, Attributes, Data Types, and Identifiers Static Entities and Structures Data Relationships, Foreign Keys, and Referential Integrity

4 Chapter 4: Fetching Data

4.1 Aggregates: Filters, Sorting, and Max Records 4.2 Aggregates: Joins, Group By, and Computed Attributes 4.3 Fetching Data on Screens with Data Actions, Caching, and RefreshData 4.4 SQL Queries and External Integrations: REST and SOAP Consumption

5 Logic Flows and Actions

Client Actions, Server Actions, and Action Parameters Logic Flow Control: If, Switch, For Each, and Assign Form Validations: Mandatory, Email Type, and Form.Valid

6 Chapter 6: Error Handling and Advanced Logic

Exception Handling: Exception Handlers, Raise Exception, System vs User Exceptions, AbortTransaction Timers, BPT Processes, Human Activities, and Built-in Functions

7 UI Design: Screen Widgets

Core Screen Widgets: Screen, Container, Expression, If, Link, and Button Forms, Input Widgets, Data Binding, and Feedback Messages List Widget, Pagination, and Screen Navigation Themes, CSS Styling, OutSystems UI, and UI Patterns (Popup/Modal)

8 UI Design: Blocks and Events

Blocks: Creating Reusable UI Components with Input Parameters and Local Variables Block Events and Parent-Screen Communication

9 Architecture, Security, and Lifecycle

Modular Dependencies, Public/Private Elements, and Layered Architecture Role-based Security: Roles, Accessible By, CheckRole, GrantRole, Anonymous Application Lifecycle: 1-Click Publish, LifeTime, Environments, and Versioning

Forms, Input Widgets, Data Binding, and Feedback Messages

Key Takeaways Explain This Topic AI

The Form widget groups Input widgets and exposes a Valid property and validation messages; Form.Valid is the standard gate before running submit logic in a Client Action.

Input widgets support two-way binding via the Variable property (Screen Variable or entity attribute) — user edits write back to the bound variable automatically, and variable changes update the displayed value.

Mandatory property marks a field required and drives the built-in validation that sets Form.Valid to false when empty; the Email data type adds built-in email format validation automatically.

Feedback Message is a toast-style notification widget triggered by the ShowFeedbackMessage Client Action, with Type (info, success, warning, error) and a Message property — used to confirm saves or report validation errors.

Scaffolding a Screen from an entity auto-generates a Form with bound Input widgets, a Save Client Action, and validation wired to Form.Valid — the fastest way to produce a working CRUD edit screen.

Last updated: July 2026

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.

• Property / Concept Purpose
• Valid Boolean — true only when all child Inputs pass validation
• Validation Messages Auto-displayed under invalid Inputs
• Submit on Enter Set a Button's Is Form Default to true
• Data binding Bound to a Screen Variable or entity attribute

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.

• Property Purpose
• Variable The bound variable or attribute — two-way binding target
• Input Type Text, Integer, Decimal, Date, Boolean, Email, Password
• Mandatory If true, field must be non-empty for Form.Valid
• Enabled Boolean controlling editability
• Style Classes CSS classes
• Label Text label above/beside the Input

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:

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.

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:

• Property Purpose
• Type info , success , warning , or error — controls icon and color
• Message The text displayed in the toast (an expression)
• Show Boolean — whether to display the toast now
• Timeout Auto-dismiss duration in milliseconds (optional)

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:

• Button (Is Form Default = true) OnClick → Client Action
• If Form.Valid = false → ShowFeedbackMessage(error) and exit
• CreateOrUpdate entity action (writes to database)
• ShowFeedbackMessage(success)
• 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.