OutSystems Delivery Specialist cheat sheet

OutSystems applications are composed of modules; a module is the unit of deployment, versioning, and reuse, and is either a Reactive Web App, Traditional Web App, Mobile App, Service, or Library.

Libraries contain only server-side logic and cannot hold screens or client-side UI; shared UI must live in a module exposed as a Producer with public elements.

A Producer module exposes elements as Public; a Consumer references them. Changing a public element's signature breaks consumers, so prefer additive changes and new actions over edits.

Module references are one-directional and circular references between modules are not allowed; break cycles by extracting shared logic into a lower-level library.

Strong dependency rule: keep UI in app modules, business rules in libraries, and integrations in Service modules so each layer is independently testable and deployable.

A Server Action runs on the server only; a Client Action runs in the browser or device; Client Actions cannot call server entities directly and must use exposed Server Actions or Aggregates.

Screens, Blocks, and Layouts are UI elements; Blocks are reusable screen fragments, Layouts wrap screens in a common chrome (header, menu, footer) and are set per screen or by theme default.

Entities defined in a module are private by default; set the entity to Public to share it, and expose only the attributes consumers need via a read-only or public entity design.

Entity attributes map to physical columns; the Id attribute is a system-generated auto-number (or configurable) primary key, and every entity has Created/Updated audit attributes if auditing is enabled.

Static Entities store a fixed enumerated set of records (records are defined at design time, identified by a Record Id string) and cannot be created at runtime.

Aggregates produce a structured result set with Filters, Sorts, and Group By; use Aggregate functions (Count, Sum, Average, Min, Max) rather than looping in logic.

Aggregate Join types: Only With (inner join), With or Without (left join), and With or Without and Only Without (full outer join); pick the join kind that matches required row inclusion.

Use SQL queries when an Aggregate cannot express the requirement (complex subqueries, unions, window functions); SQL queries are read-only in OutSystems and must return a defined structure.

Expose a Server Action returning a List or a Structure to feed Client Aggregates; Client Aggregates run in the browser/device and query only data exposed by server actions.

1-to-Many and 1-to-1 relationships are created by adding a reference attribute (Entity Identifier); Many-to-Many requires an explicit join entity with two reference attributes.

Use Delete Rules deliberately: Protect (default, blocks delete when referenced), Delete (cascades), and Ignore (orphans references); choose based on referential integrity needs.

Screen lifecycle events run in order: Prepare (server, before render), Render (server, builds the view), Ready (client, after render), and OnParametersChanged; place data loading in Prepare, not Render.

Screen and Block input parameters are passed by value; use Session Variables for cross-screen state and Client Variables for client-only state that must survive navigation.

Validations run on the client when possible and are re-checked on the server; use the built-in Validator or a Server Action with explicit validation logic for security-sensitive rules.

Exception handling: wrap risky logic in a Try/Catch (or the Exception Handler flow) and use the built-in Exception types (DatabaseException, CommunicationException, SecurityException) to branch behavior.

REST integration: consume a REST API by defining it in a Service module (Consume REST API), which generates methods and structures; map responses into local structures before persisting.

SOAP integration uses Consume SOAP Web Service; both REST and SOAP calls should set timeouts and handle non-2xx responses explicitly.

Timers run server-side logic on a schedule; they are useful for batch processing and must be idempotent because they can retry.

Roles and permissions: define Roles in the module, assign via the Users application or a custom admin screen, and check with the built-in Check functions or screen-level permission settings.

Environments form a pipeline (Development, Quality/Test, Pre-Production, Production); deployment promotes a tagged application version between environments, not the raw module.

A Solution groups applications and modules for deployment as a unit; deploy the solution version, and confirm dependencies are included or already present in the target.

Publish vs Deploy: Publish compiles and applies changes in the current environment; Deploy pushes a version to another environment and runs the deployment plan.

Deployment plans list the modules and their order; review them for unintended changes (e.g., entity model changes that require data migration) before executing.

Entity model changes that drop or rename attributes can cause data loss; use the platform's data migration guidance and test in a non-production environment first.

Application lifecycle states include Development, Under Development, and Production; set the application to Production only after testing so it is protected from accidental edits.

Service Center and LifeTime are the operational consoles: LifeTime manages environments, deployments, and application versions across the infrastructure.

Monitor performance with built-in logs and Service Center metrics: slow queries, screen render times, and integration call durations are the primary triage signals.