OutSystems Delivery Specialist key terms

A web application model in OutSystems in which screen data and UI updates are synchronized with the server automatically, reducing manual refresh logic and enabling richer client-side interaction.

An OutSystems application model that renders pages on the server and returns full page responses to the browser, relying on server-side preparation and postback behavior rather than reactive synchronization.

The ordered set of events a screen executes, including preparation, rendering, and after-render actions, plus user-triggered screen actions, which together control when data loads and validation runs.

A screen event that runs before the screen renders, typically used to fetch and shape the data the interface needs, and which can be reused across screens through preparation aggregation.

A server-side action bound to a user interface event on a screen, such as a button click, that executes logic, may update screen state, and can trigger navigation or feedback messages.

Reusable logic that executes on the OutSystems server and can be called from screens, other server actions, or exposed as a service, keeping business rules centralized and testable.

Logic that runs in the browser rather than on the server, used for lightweight interface behavior such as toggling visibility or validating input before a server round trip.

A screen-scoped value stored and manipulated in the browser, allowing interface state to change without a server call, with behavior that differs between reactive and traditional app models.

A visual query definition in OutSystems that combines entities and joins, applies filters and sorting, and produces a structured result set consumed by screens and logic without hand-written SQL.

A persistent data model element in OutSystems that maps to a database table and defines attributes, identifiers, and relationships used throughout an application's logic and queries.

A configuration-style entity whose records are defined at design time and deployed with the application, commonly used for lookup lists, statuses, and reference values that rarely change.

The main unit of composition in OutSystems, containing screens, logic, data, and references, and exposed to other modules through explicit public elements rather than implicit sharing.

A module that exposes public elements so other modules can consume them, establishing a dependency direction that must be designed carefully to avoid tight coupling and circular references.

A module that references public elements from another module and uses them in its own screens and logic, inheriting the producer's contract and any breaking changes to it.

An explicit dependency a module declares on public elements of another module, such as actions, entities, or structures, enabling reuse while keeping module boundaries visible and enforceable.

A server action exposed so it can be consumed by other modules or external systems, often used to publish business capabilities through REST or SOAP integrations.

An integration method in OutSystems where methods are exposed or consumed over HTTP, with request and response structures mapped to OutSystems elements such as structures and entities.

The practice of connecting an OutSystems application to external systems or services, covering consumption of APIs, exposure of services, error handling, and data transformation at the boundary.

A composite data type grouping related attributes without persistence, frequently used to model request and response payloads and to pass grouped values between actions.

The mechanism for catching, logging, and responding to errors in logic, including user-defined exceptions and platform exceptions, so failures are surfaced clearly instead of silently breaking flows.

A configurable value defined at the environment level that logic reads at runtime, allowing behavior such as endpoints or feature flags to differ per deployment without code changes.

The process of publishing an application version to an environment, including validation, compilation, and dependency checks, and possibly requiring confirmation of impact on consumers.

An isolated instance where applications run, such as development, quality, or production, each with its own configuration and data, connected through a managed deployment pipeline.

The OutSystems console capability for moving application versions across environments, tagging them, and controlling who can deploy where, providing governance over the delivery pipeline.

A packaged set of modules and their dependencies prepared for deployment together, ensuring that producers and consumers move consistently and that version compatibility is verified.

The assessment of which consumers, screens, or integrations are affected by a change to a public element, used to decide whether a change is safe or breaking before deployment.

A modification to a public element, such as removing an attribute or changing a parameter, that can invalidate consumer modules and must be coordinated across the deployment pipeline.

A named permission grouping assigned to end users, checked in logic and screen access rules to restrict who can view data or execute actions within an application.

An access rule attached to a screen that limits which roles may open it, enforced by the platform so unauthorized users cannot reach the interface even by direct URL.

A logic element that tests whether the current user holds a given role, used to branch behavior or guard server actions that must not be executed by unauthorized callers.

The process of verifying a user's identity before granting access, which in OutSystems can be handled by built-in user management or delegated to an external identity provider.

An authentication pattern where users authenticate once with an external identity provider and are recognized by the application, typically via federation protocols configured in the platform.

The practice of improving application responsiveness by reducing unnecessary server calls, optimizing queries and aggregates, and avoiding logic that scales poorly with data volume.

The process of inspecting running logic, breakpoints, and variable values to locate defects, including tracing requests across screens, actions, and integrations in a deployed environment.

An automated check of a single action or logic unit in isolation, verifying expected outputs and edge cases so regressions are caught before a version is promoted between environments.

A scheduled background job in OutSystems that runs logic at defined intervals, commonly used for batch processing, cleanup, or synchronization tasks independent of user interaction.

Executing work outside the immediate request so the user is not blocked, often implemented with timers or background logic, requiring care around failure handling and idempotency.