4.3 Fetching Data on Screens with Data Actions, Caching, and RefreshData

Quick Answer: Reactive Web Apps fetch screen data using Data Actions — server-side functions that run when a screen loads and expose the result as a List bound to widgets. Data Action results can be cached to avoid re-fetching on navigation, and you can force a reload with RefreshData, passing the Data Action name. For single-record reads by identifier, the Fetch tool is the lighter-weight alternative to a full Aggregate.

Data Actions on Reactive Screens

A Data Action is a server-side function defined directly on a Reactive Screen. When the screen loads, OutSystems runs all of its Data Actions in parallel and only renders the screen once they complete. The result of each Data Action is exposed as a List on the client, ready to bind to List widgets, Tables, Charts, and Expressions. Under the hood a Data Action usually wraps an Aggregate or a Server Action call, but from the screen's perspective it is a single, declarative data source. Because Data Actions are server-side and asynchronous, the screen displays a built-in loading state until results arrive. You do not write a loading spinner yourself — the platform provides one. This is a contrast with Traditional Web, where the Preparation action ran synchronously before render and blocked the entire page.

Caching Data Action Results

Each Data Action has a Cache in Minutes property. Set it to a positive number and OutSystems stores the result in the server cache keyed by the Data Action's parameters; subsequent calls within the cache window return the cached List instead of re-querying the database. Caching is ideal for reference data that changes rarely — dropdown options, lookup tables, configuration rows — and it dramatically reduces database load on high-traffic screens.

Cache invalidation rules to remember: the cache is per-parameter-set, so two calls with different parameter values produce different cache entries. The cache is per-user-session by default in reactive apps; it is not a global cache shared across users unless you use a server-side cached aggregate pattern. RefreshData bypasses the cache and always fetches fresh. Cache expires after the configured minutes; there is no manual clear-cache API callable from the client. Caching is a property of the Data Action, not of the underlying Aggregate — the same Aggregate used in two Data Actions can have different cache settings.

RefreshData

RefreshData("DataActionName") is a client action that re-executes a Data Action. You call it from a Client Action — typically the OnNotify handler of a Block Event, the click handler of a refresh button, or after a successful Save action — to reload the List without navigating away from the screen. The argument is the name of the Data Action, passed as text (for example RefreshData("GetOrders")).

A common exam trap is calling RefreshData with the Aggregate's name instead of the Data Action's name. In Reactive Web Apps the screen-level data fetch is the Data Action; the Aggregate lives inside it. RefreshData("GetCustomer") is correct if GetCustomer is the Data Action; passing the Aggregate name does nothing because there is no Data Action with that identifier. Another trap is expecting RefreshData to reload data on a different screen — it only refreshes Data Actions on the current screen.

Fetch vs Aggregate on Screens

OutSystems provides a Fetch element for the common case of retrieving a single record by its identifier. Fetch is essentially a specialized Aggregate that does WHERE Id = ParamId and returns one record (or NullIdentifier if not found). For screen-level single-record reads, Fetch is preferred because it is simpler to configure (one entity plus one Id parameter), it returns a single record rather than a List so binding is direct, and it avoids writing a one-row Aggregate manually. Use a full Aggregate when you need filters on non-id attributes, joins, group by, computed attributes, or sorting — anything beyond a primary-key lookup.

Choosing the right tool is about matching the data shape to the mechanism: one record by id is Fetch, a list with filters is a Screen Aggregate, a list needing cache or refresh is a Data Action, and anything beyond Aggregate capabilities is the SQL element.