OutSystems Delivery Specialist common mistakes
OutSystems Delivery Specialist · Understand the traps and how to avoid them.
Treating OutSystems as a generic MVC framework and hand-writing SQL joins, session handling, and REST wrappers instead of using built-in aggregates, the Users/Roles model, and exposed REST/SOAP integrations.
Candidates with .NET or Java backgrounds default to patterns they already know, and the exam's scenario questions describe business requirements rather than naming the OutSystems entity, so the built-in feature is easy to overlook.
What to do instead
For every requirement in a practice scenario, ask first which native OutSystems element covers it (Aggregate, Entity, Exposed API, Server Action, Site Property) and write down that mapping before considering custom code; review the platform's built-in capability list until it is automatic.
Designing the data model with denormalized tables and manual foreign-key columns copied from relational design, rather than using Entity References, static entities, and proper identifier attributes.
Candidates translate an ER diagram literally and forget that OutSystems entities already carry an implicit Id and that references replace stored FK columns, so they add redundant attributes and break aggregate joins.
What to do instead
Practice modelling the same domain twice: once as a raw relational schema and once as OutSystems entities with references and static entities; note which attributes disappear. In the exam, prefer references and static entities whenever a question mentions lookup values or parent-child relationships.
Placing business logic in Screen Actions or Preparation instead of in Server Actions or Service Actions, and then reusing screens as if they were services.
Screen-level logic works in a demo, so candidates never feel the pain of duplication; exam items about reuse, layering, and exposing logic to other modules are answered from demo habits rather than architecture rules.
What to do instead
Adopt a rule: any logic used twice, or callable from another module, lives in a Server Action in a logic module, and anything consumed externally lives in a Service Action. Rework a sample app so screens only orchestrate calls, then answer layering questions from that structure.
Ignoring the module and dependency model: putting everything in a single module, creating circular references, or exposing entities publicly when only actions are needed.
Small exercises fit in one module, so candidates never internalize strong/weak references, public vs. exposed elements, or the difference between a module reference and a producer-consumer relationship.
What to do instead
Memorize the reference types and what each exposes (entities, actions, both), then sketch a two-module solution for a simple requirement and verify which elements must be public. On exam items about dependency direction, redraw the reference arrows before choosing an answer.
Confusing aggregate behaviour: assuming filters apply after grouping, that an aggregate returns all rows by default, or that a SQL query is needed for a simple join across references.
Candidates read aggregates as SQL SELECTs and misapply WHERE vs. HAVING semantics, or forget that aggregates are lazy and only materialize when iterated, counted, or converted to a list.
What to do instead
Build a small test module with two related entities and run aggregates with filters, grouping, and calculated attributes; observe the generated SQL and the row counts. Learn the rule that filters on grouped attributes belong in the grouping filter, not the main filter.
Misjudging transaction and exception behaviour: assuming an unhandled exception rolls back everything, or that a commit inside a loop is harmless, or that exceptions can be swallowed by an empty handler.
Candidates come from environments with different transaction scoping and never test partial-failure scenarios, so questions about commit boundaries, error handling, and retry logic are answered by intuition.
What to do instead
Create a screen action that writes two records, raises an exception between them, and observe what persists with and without an explicit CommitTransaction. Repeat with a loop. Answer transaction questions from observed behaviour, not assumption.
Treating security as a checkbox: forgetting that screen access must be restricted by role, that server actions are callable unless checked, and that exposed APIs need their own authentication.
The development environment runs as a privileged user, so missing role checks never surface during testing; candidates therefore under-specify authorization in scenario answers.
What to do instead
For each screen and each exposed API in a practice app, write the intended role and then verify the check exists in the element's properties. Learn where role enforcement happens automatically versus where an explicit check is required, and apply that split to exam scenarios.
Overlooking performance design: retrieving full entity records when only a few attributes are needed, looping over records to call a server action one by one, or leaving N+1 aggregate patterns in list screens.
Correctness-first development passes tests on small data, and the exam's performance items describe symptoms at scale rather than naming the anti-pattern, so the cause is not recognized.
What to do instead
Practice rewriting a list screen to fetch only needed attributes, batch work outside loops, and use aggregate-level joins instead of per-row lookups. Learn to read a slow-screen scenario and name the specific pattern before selecting an answer.
Answering deployment and lifecycle items from a developer's local view: ignoring that publishing to a new environment requires the solution or module to be tagged and deployed through the platform, and that timers, site properties, and configurations differ per environment.
Candidates who only work in a single development environment have never promoted an application, so they assume publishing equals deploying and forget environment-specific configuration.
What to do instead
Walk through the deployment lifecycle conceptually: development, tagging, deployment to target environments, and environment-specific settings. For each configuration item, decide whether it belongs in a site property or a constant, and note which values must change per environment.
Neglecting operational concerns in scenario answers: no strategy for timers and background jobs, no handling of email or integration failures, and no plan for logging and monitoring production errors.
These topics are rarely exercised in tutorials, and exam scenarios phrase them as business needs (nightly processing, failed notifications) rather than as named platform features.
What to do instead
For each scenario, list the asynchronous work and decide whether a timer, a wake-up, or a queued action fits, then specify retry and failure notification. Learn where platform logs and error records live so monitoring questions can be answered concretely.