OutSystems Associate Developer cheat sheet

A web app is composed of modules; a module holds the screens, logic, data entities, and UI flows for one functional area.

Screen lifecycle events run in order: Initialize, Prepare, Render; Ready fires on the client after the screen is displayed.

Aggregate fetches data from the database and exposes it as a Record List; its Output must be assigned to a screen variable to persist.

A Server Action runs on the server and can query the database; a Client Action runs in the browser and cannot directly access the database.

Input Parameters pass data into a Screen or Action; Output Parameters return data from an Action to its caller.

A Session Variable persists for the user's session and is shared across screens; a Screen Variable is scoped to one screen instance.

A Site Property is a runtime-configurable value editable in Service Center without redeploying the module.

Roles and their permissions are defined per module; screen access is granted by adding the Role to the screen's Roles property.

The Web Blocks are reusable UI components; a Block has its own scope and communicates via Input and Event parameters.

A mobile app module produces a native shell that renders screens locally; offline behavior depends on local storage entities.

Mobile screens use the same lifecycle order (Initialize, Prepare, Render, Ready) but Prepare runs on the device, not the server.

Offline Data Sync synchronizes local entities with the server; entities are marked with the appropriate sync behavior in the data model.

Client Variables persist on the device across app restarts; Screen Variables live only while the screen instance exists.

Navigation in mobile apps uses the destination Screen plus optional Input Parameters; back-stack behavior is platform-managed.

Mobile apps cannot use server-side Screen Aggregates in offline mode; use local entities and client-side logic instead.

The Mobile UI patterns (List, Detail, Edit) map to standard screen templates that pre-wire navigation and data binding.

Plugins expose device capabilities (camera, GPS, notifications); each requires a plugin reference and a build that includes it.

A mobile module must be generated and installed on a device or emulator; the preview in the browser does not reflect native behavior.

OutSystems Developer Cloud (ODC) organizes work into Apps, each containing one or more Modules of type Web, Mobile, or Library.

ODC uses a stage-based deployment pipeline: Development, Test, and Production stages are separate environments.

A Library module exposes reusable Actions and Entities but has no screens; it is referenced by other modules.

Public Elements (Actions, Entities, Structures) must be exposed in the Producer module before a Consumer module can reference them.

ODC uses OIDC-based authentication; end users are managed in the identity provider configured for the organization.

Deployments in ODC are triggered per app and promote the whole app's modules together through the pipeline stages.

The ODC Portal manages users, roles, apps, and environments; the ODC Studio is the IDE used to build modules.

Entity attributes have data types; the Identifier attribute is auto-generated and uniquely identifies each record.

Server Actions in ODC run in the app's runtime; long-running logic should avoid holding database transactions open.

Start a new app from a template (e.g., Reactive Web or Mobile) to pre-generate screens, theme, and navigation.

Create Entities first, then Aggregates to read them, then Screens that bind Aggregate outputs to widgets.

Use a Form with an Entity input to create or update records; the Save action persists the record and returns the identifier.

A List widget bound to a Record List renders one row per record; use List Item for the row template.

Validation: set Mandatory and data-type constraints on inputs; server-side validation runs in the Save action.

For delete flows, pass the record Identifier as an Input Parameter and call the Delete Entity action.

Use If widgets for conditional rendering and the built-in feedback messages for success and error states.

Reuse UI via Blocks; pass data with Input Parameters and raise Events to notify the parent screen.

Test by publishing the module, then use the generated screens in the browser or device; check the debugger for runtime errors.