ExamFinch.com My Study

Study guide

Block Events and Parent-Screen Communication

Practice this exam

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

Block Events and Parent-Screen Communication

Key Takeaways Explain This Topic AI

A Block Event is the mechanism by which a Block notifies its parent Screen that something happened inside the Block (e.g., a button click, a selection, a save); the Block raises the Event using the Notify action and the parent Screen registers an event handler Client Action.

Block Events carry data through Event parameters (e.g., SelectedItemId, IsSaved); these values are passed to the parent's handler action and are available as read-only inputs inside the handler logic.

The parent-to-Block direction uses input parameters (parent passes values down, Block reacts via OnParametersChanged); the Block-to-parent direction uses Events (Block raises Event, parent handles it) — this asymmetry is the core of the parent-child communication pattern.

OnNotify is the event handler property on the Block instance in the parent Screen where you bind a Client Action; when the Block raises any Event via Notify, the parent's OnNotify Client Action executes and receives the Event parameters.

The full bidirectional cycle is: parent passes input parameters down, Block renders and fetches data, user interacts inside the Block, Block raises an Event with parameters, parent's OnNotify handler runs and reads the Event parameters to react (navigate, refresh data, update state).

Last updated: July 2026

Block Events and Parent-Screen Communication

Quick Answer: A Block Event is the OutSystems mechanism for a Block to notify its parent Screen that something happened inside the Block — a button click, a list selection, a form save. The Block raises the Event using the Notify action, and the parent handles it through a Client Action bound to the Block instance's OnNotify property. Event parameters carry data from the Block to the parent, completing the upward half of the parent-child communication cycle.

The Raise/Notify Pattern

Blocks cannot directly call parent Screen actions — they are encapsulated and do not know which Screen hosts them. Instead, Blocks use an event-driven publish-subscribe pattern:

Define a Block Event in the Block's element tree, specifying Event parameters (the data the Event will carry)

Raise the Event inside the Block's logic using the Notify action, passing current values into the Event parameters

  • Handle the Event on the parent Screen by binding a Client Action to the Block instance's OnNotify property
  • React in the handler Client Action, reading the Event parameters and executing parent-side logic

This decoupling makes Blocks reusable. The same Block on different parents handles the Event differently — OnSaveClicked might trigger a data refresh on a list Screen and a navigation on a wizard Screen.

Event Parameters: Passing Data from Block to Parent

When you define a Block Event, you specify its parameters — the payload carried to the parent. These function like Event outputs:

  • Event Name Parameters Example Values
  • OnItemSelected SelectedItemId (Integer) 42
  • OnSaveClicked CustomerId (Integer), IsNewRecord (Boolean) 107, True
  • OnFilterChanged FilterText (Text), IsActive (Boolean) "VIP", True

Inside the Block, the Notify action passes values into these parameters — typically from local variables or widget bindings. On the parent side, the handler receives them as read-only inputs to call a Server Action, navigate, refresh an Aggregate, update a local variable, or show a Feedback Message.

OnNotify: The Parent-Side Handler

When you drag a Block onto a Screen, the Block instance exposes an OnNotify event property. You bind a Client Action to it — this is the event handler. When the Block raises any Event via Notify, the OnNotify handler runs on the parent.

If a Block defines multiple Events, all funnel through the single OnNotify handler; you distinguish which fired by checking the Event name or using a Switch node on an identifier parameter. The handler signature includes the Event's parameters as inputs, so you can read them, execute parent-side logic, and access Screen-level local variables since the handler is a Client Action in the parent Screen's context.

Parent-to-Block: Input Parameters (Downward)

The downward direction uses input parameters. The parent passes values when it places the Block:

  • Bind the Block's input parameter to a Screen local variable, expression, or Data Action result
  • When the parent's bound value changes, the Block's OnParametersChanged fires automatically

The Block can call RefreshData on its Data Actions inside OnParametersChanged to re-fetch with the new parameter value

This creates a clean separation: input parameters are the downward channel (parent to Block), and Events are the upward channel (Block to parent). Neither channel works in reverse — a parent cannot raise a Block's Event, and a Block cannot set its own input parameter. This asymmetry is a frequent exam topic.

The Full Parent-Child Communication Cycle

The complete bidirectional pattern ties both channels together:

  • Step Direction Mechanism Example
  • 1 Parent to Block Input parameter binding Parent passes CustomerId = 42
  • 2 Block internal OnParametersChanged Block calls RefreshData on its Data Action
  • 3 Block internal Data Action re-fetches Block loads customer 42 from server
  • 4 Block to Parent Event (Notify) User clicks Edit; Block raises OnEditClicked with CustomerId = 42
  • 5 Parent reacts OnNotify handler Parent navigates to EditScreen(CustomerId = 42)

This five-step cycle — configure down, detect internally, fetch, notify up, react — is the canonical Block communication architecture. Scenario questions often describe a subset and ask which mechanism (input parameter, OnParametersChanged, RefreshData, Event, or OnNotify) belongs at each step.

Common Exam Traps

Several traps recur in Block and Event questions:

Trap: "Use a Block output parameter to send data to the parent." Blocks do not have output parameters — they use Events with Event parameters. An output parameter is a Server Action concept, not a Block concept.

Trap: "The parent can read the Block's local variables." Local variables are internal; the parent cannot access them. If the parent needs the data, the Block must raise an Event carrying the value.

Trap: "A Block can call a Server Action defined in the parent Screen." Blocks cannot reference parent Screen actions directly — communication is through Events (upward) and input parameters (downward).

Trap: "OnNotify fires before the Block renders." OnNotify fires when the Block raises an Event during user interaction, not during render. OnParametersChanged is the lifecycle event for input parameter changes.

  • When to Use Events vs Input Parameters
  • Need the parent to configure the Block? Use input parameters (e.g., pass a CustomerId or ReadOnly flag)
  • Need the Block to tell the parent something happened? Use an Event (e.g., OnSaveClicked, OnItemSelected)

Need both? Most real-world Blocks use both: input parameters configure the Block, and Events report user actions back. This bidirectional pattern — input parameters down, Events up — is the standard architecture for reusable Blocks in Reactive Web Apps.