OutSystems Professional Developer common mistakes
OutSystems Professional Developer · Understand the traps and how to avoid them.
Treating the four-layer canvas (Library, Service, End-User, Core) as a naming convention and placing reusable logic in End-User modules, then duplicating it across screens.
Candidates learn the layer names from the architecture material but never internalise the dependency rule that a layer may only reference layers below it, so they optimise for whichever module is open at the time.
What to do instead
For every module you create, state aloud which layer it belongs to and which modules it is allowed to reference. Reusable business rules belong in Core; exposed orchestration belongs in Service; UI composition belongs in End-User. If you catch yourself referencing an End-User module from a Core module, the design is wrong regardless of whether it compiles.
Answering questions about module exposure by choosing 'expose REST' for internal reuse, or by exposing a Server Action publicly when only another module in the same application needs it.
Candidates conflate 'make it reusable' with 'make it an API'. They have seen exposed REST APIs in tutorials and default to that pattern for any cross-module call.
What to do instead
Separate three cases: same application reuse (reference the module directly, no exposure needed), cross-application reuse inside the same environment (expose the element as a public action), and external consumption (expose as REST/SOAP). Reference the weakest mechanism that satisfies the requirement, and remember that public elements become a contract you must maintain.
Building a screen that queries an Entity directly with an aggregate on the screen, then filtering and joining in the screen action, rather than preparing data in a Server Action or a data action with a clear output structure.
The screen-level aggregate is the easiest thing to drag onto a screen and it works in a demo, so candidates never build the habit of separating data preparation from presentation.
What to do instead
Decide per screen whether data is screen-specific (a data action is acceptable) or reusable (prepare it in a Server Action or Service Action and pass a structured output). When an aggregate feeds more than one screen, or contains business filtering, move it out of the screen. On the exam, when a question asks where logic should live for reuse and testability, the screen is almost never the answer.
Using a Local Variable to hold a record fetched by an aggregate, then assuming the screen refreshes automatically after a Server Action modifies the underlying data.
Candidates do not distinguish between the screen's aggregate-backed data and a snapshot copied into a variable, so they cannot predict when the UI shows stale values.
What to do instead
Know three refresh paths: re-running the screen's aggregate (Refresh Data on the aggregate), re-executing the data action, and explicitly re-assigning a variable. If a Server Action changes data, the screen must re-fetch; a Local Variable copy will not update itself. Practise predicting the rendered output after each action in a small two-screen app until this is automatic.
Designing mobile flows that assume an always-on connection: calling a Server Action on screen load with no offline handling, and letting the screen fail or hang when the device is offline.
Candidates develop on an emulator or a fast network and never exercise airplane mode, so the offline model of mobile apps stays theoretical.
What to do instead
For any mobile screen that reads data, decide explicitly: is it online-only (acceptable only when the requirement allows it) or does it need local storage and synchronisation? Use local entities plus an explicit sync action, show a clear offline state, and handle conflicts on sync. In exam scenarios about field workers, warehouses, or inspections, assume intermittent connectivity and choose the offline-capable design.
Confusing the roles of the mobile app's screens, the local storage entities, and the server-side logic, and putting business rules in the client that must be enforced on the server.
The mobile builder looks like the web builder, so candidates port web patterns directly and treat the device as trusted.
What to do instead
Assume the client is untrusted. Validation and authorisation must be re-checked in Server Actions. Local entities are a cache and a queue, not a source of truth. When a question asks where a rule should be enforced for a mobile app, the server side is the defensible answer unless the rule is purely presentational.
Relying on client-side validation (mandatory fields, built-in validators) as the only defence, and answering security questions as if hiding a button or a screen prevents access.
The UI makes validation easy and visible, so candidates equate 'the form will not submit' with 'the data cannot be written'.
What to do instead
Treat every Server Action and exposed API as callable by anyone who can reach it. Re-validate inputs server-side, enforce authorisation checks inside the action (not only in the screen's preparation), and remember that hiding UI elements is usability, not security. On the exam, any option that says 'the button is hidden so the user cannot do X' is a distractor.
Granting broad roles (for example a single 'Admin' or an all-purpose 'User' role) and checking roles only at the screen level, instead of modelling permissions around the actual operations and checking them at the action and entity level.
Role-based access is taught as screen visibility, and candidates do not practise the finer-grained checks that real applications need.
What to do instead
Model roles around job functions, then check authorisation where the operation happens: in Server Actions before writes, and in entity-level rules where row-level restriction is required. Ask for each action 'who may call this, and how is that enforced if the caller bypasses the UI?' If you cannot answer with a specific check, the design is incomplete.
Treating the front-end as a place to put logic: large screen action flows that transform data, compute totals, and branch on business rules, with the aggregate left as a raw table dump.
Screen actions are the most immediate place to react to a button click, and candidates add 'just one more' assignment until the screen owns the business logic.
What to do instead
Keep screen actions thin: validate input, call a Server or Service Action, assign outputs, give user feedback. Move computation and branching into reusable actions. A useful test: if the same calculation is needed on a mobile screen or an exposed API, it must not live in a screen action. Practise refactoring one bloated screen into a data action plus a service action.
Ignoring the lifecycle and deployment implications of references: adding a reference to a module in another application or environment without considering impact, or assuming a changed public action signature will not break consumers.
In a single-environment sandbox everything recompiles together, so candidates never see the breakage that occurs when modules are versioned and deployed independently.
What to do instead
Before changing a public element, list its consumers and decide whether the change is compatible. Prefer additive changes (new optional inputs, new actions) over signature changes. Know that references are resolved per environment and that a deployment order exists; when a question describes a multi-environment promotion, think about which module must be published first and what happens to consumers of a changed contract.