OutSystems Professional Developer key terms

The basic unit of deployment in OutSystems, packaging logic, data entities, UI, and dependencies. Modules come in types such as Reactive Web, Traditional Web, Mobile, Service, and Extension, each controlling what it can expose.

A grouping of modules that together form a deployable product, organized into an application and its child modules. Applications control versioning, tagging, and lifecycle across environments.

A container that bundles one or more applications or modules for deployment as a single unit. Publishing a solution deploys every contained module in dependency order to a target environment.

A declared reference from one module to another's public elements. Dependencies determine compilation order and deployment sequencing, and circular dependencies between modules are not allowed.

An element inside a module exposed for reuse by other modules, such as a public action, entity, structure, or screen. Only public elements can be referenced across module boundaries.

The mechanism that packages a solution and pushes it through environments, running lifecycle stages such as compile, deploy, and validate. It also supports scripts and messages before or after deployment.

An isolated instance of the platform where applications run, typically Development, Quality, and Production. Each environment has its own database and deployment history.

The platform console for managing environments, applications, deployments, users, and IT roles across the infrastructure. It provides visibility into which application versions run in each environment.

Reusable server-side logic defined in a module, composed of a flow of statements such as assignments, queries, and calls. Server actions run on the server and can be exposed as public elements.

Logic that executes in the browser or on the device rather than on the server. Client actions handle local interactions, validation, and screen preparation for reactive and mobile apps.

A declarative query built visually over entities, producing a list or a single record. Aggregates support filters, sorting, grouping, joins, and calculated attributes without hand-written SQL.

A data model element representing a table of records with typed attributes. Entities support indexes, relationships, and automatic CRUD actions generated by the platform.

An entity whose records are defined at design time and deployed as reference data, such as statuses or categories. Records are maintained in the module rather than created at runtime.

The ordered events a screen goes through, such as preparation, rendering, and destruction. Understanding which logic runs on the server versus the client is essential for correct behavior.

The server-side action that loads and shapes the data a screen needs before rendering. It runs before the screen is displayed and can receive input parameters.

A per-user value stored on the server for the duration of a session, often used for the logged-in user or tenant. Session variables are not shared between users.

A configuration value managed per environment and read at runtime, letting the same application behave differently across environments without redeployment of code.

A hand-written SQL statement embedded in a module for cases aggregates cannot express, such as complex joins or database-specific functions. It returns structures or entities and must be used carefully.

The mechanism that stores data locally on a mobile device and syncs changes with the server when connectivity returns. It requires conflict handling and careful data modeling.

On-device persistence used by mobile apps to keep data available without a network connection. It is populated and synchronized through platform mechanisms rather than direct database access.

A module type that generates a native mobile app for iOS and Android, sharing logic with server modules. It supports device capabilities and offline scenarios.

A packaged component that exposes native device capabilities, such as camera or geolocation, to a mobile app. Plugins bridge JavaScript or native code into the platform's action model.

A URL that opens a specific screen inside a mobile app rather than its home screen. Deep links support navigation from emails, notifications, or other apps.

A web app model where the UI updates in the browser without full page reloads, using client-side data binding and server calls. It differs from Traditional Web, which renders pages on the server.

A reusable UI component with its own inputs, local logic, and rendering, embeddable in screens or other blocks. Blocks promote consistency and reduce duplication across the interface.

A block designed for web screens that encapsulates markup and behavior and can expose events and inputs. It can be reused across screens and modules when made public.

A UI page composed of widgets and bound to data and actions. Screens define the user's entry points and drive navigation within the application.

A set of style rules and design tokens applied across an application to control appearance consistently. Themes separate visual design from screen structure.

A named permission grouping assigned to end users, checked in logic to grant or deny access to screens and actions. Roles are the core of the platform's authorization model.

A runtime validation that confirms the current user holds a required role before allowing an action or screen. It enforces authorization beyond simple authentication.

The component that authenticates users and supplies identity and roles to the application. It can be the platform's built-in provider or an external identity system.

Authentication verifies who a user is, while authorization decides what that user may do. Both must be designed deliberately, and confusing them is a common source of security gaps.

Checking and sanitizing values received from users or external systems before use, to prevent injection and malformed data. Validation belongs on the server even when the client also checks.

Structured capture and response to runtime errors using exception handlers and raised exceptions. Good handling prevents unhandled failures and avoids leaking internal details to users.

An action exposed by a Service module for consumption by other systems, often via REST or SOAP. It defines the contract external callers rely on.

A method of publishing module logic as REST endpoints with defined methods, URLs, and payloads. Exposed APIs form integration contracts and must be secured and versioned.