101 OutSystems Interview Questions and Answers

101 OutSystems and ODC Interview questions and answers on Architecture, logic, database, API, BPT, deployment, and the newer ODC and agentic AI territory, answered the way I'd explain it on a whiteboard, with a diagram wherever a picture actually earns its place.

Layers & rules

OutSystems interview questions and answers on Architecture and best practices

How modules are supposed to sit relative to each other, and what breaks when they don't.

Q1 What is 3-layer architecture

OutSystems apps are organized into three layers so that reuse flows one way only, downward. Foundation is the bottom layer and holds generic, reusable pieces that carry no business meaning, things like date utilities or a generic REST connector. Core sits above it and holds the business logic and services specific to your domain, for example the logic that calculates an insurance premium or validates a loan application. End-User is the top layer and holds the screens and UI that people actually interact with. A module in a lower layer is never allowed to reference something in a higher layer, that rule is what keeps the whole application tree from turning into spaghetti as it grows.

End-UserScreens, blocks, mobile UICoreBusiness logic, services, processesFoundationGeneric utilities, integrationsallowednever upward

Q2 What is Architecture validation rule, explain

These are automated checks that Service Studio and the Architecture Dashboard run against your dependency graph. They catch things like a Foundation module referencing a Core module, or a circular reference between two modules, or a module nobody uses anymore. Think of it as a linter for architecture rather than for code syntax. Ignoring these warnings for a while is fine during early development, but letting them pile up in a growing enterprise app is how technical debt quietly builds up until a refactor becomes painful.

Q3 How do you solve the circular dependency

First you find what both modules actually need from each other and pull that shared piece into a lower common module, usually in Foundation or Core, so both sides can reference it downward instead of referencing each other sideways. If the coupling is more about notifying the other side something happened rather than needing data back, an event is often cleaner than a direct call, since events decouple the producer from having to know who is listening. In ODC specifically, cyclic dependency between libraries is not just discouraged, the platform actively blocks it at publish time, so you are forced to break the cycle before you can even deploy.

Q4 How do you solve the upward reference issue

An upward reference happens when a lower layer module points to something in a higher layer, which breaks the whole point of layering. The fix is almost always to move the referenced element down to where it actually belongs, so the lower module never had a reason to look up in the first place. If moving it down is not practical because of how the logic is used elsewhere, you invert the relationship with a callback or an event so the higher layer subscribes to the lower layer instead of the lower layer calling up.

Q5 In what type of modules we should put the API consumption

API consumption belongs in Core layer service or integration modules, wrapped inside a server action with a clear name like GetCustomerFromCRM, not scattered directly inside screen logic. This way if the third party changes their contract, you fix it in one place instead of hunting through every screen that happened to call the raw REST method. It also means the End-User layer only knows about your clean internal action, not the messy details of authentication headers or response parsing.

Q6 Tell 5 Architectural and Development best practices

Five that matter most in practice:

• Keep the layering strict, nothing references upward and nothing loops back on itself

• Give every module a single clear responsibility instead of letting it become a dumping ground

• Follow one naming convention across the whole application

• Separate UI from business logic, screens should call actions, not contain business rules

• Reuse through Core or Foundation modules instead of copy pasting logic across apps

Q7 What are the sub layers of core layer

OutSystems does not officially name sub layers inside Core in its documentation, but in practice most architects split it into Core Services, which holds business logic, entities and processes, and Core Widgets, which holds reusable business specific UI components that are still generic enough to be shared across multiple End-User apps. This is a convention teams adopt for clarity, not a rule enforced by the platform itself.

Q8 What are the sub layers of the foundation layer

Same situation as Core, this is convention rather than an official platform rule. Foundation is commonly split into Foundation Utilities, which are generic helpers with zero business meaning like string formatting or date math, and Foundation Data or Integration, which holds generic connectors to external systems that any app in the company might need, like a generic email sender or a generic file storage wrapper.

Q9 How OutSystems knows that an application is foundation layer application

There is no checkbox anywhere that says this module is Foundation. The Architecture Dashboard figures it out by analyzing the dependency graph, if a module has no dependency on anything business specific and is consumed by a wide spread of other modules, it gets treated as sitting at the foundation of the tree. It is an inferred position based on how the module behaves, not a declared property.

Q10 What are the naming conventions best practices

A few conventions worth holding the line on:

• Use PascalCase consistently for modules, entities and actions

• Name actions like a sentence describing what they do, GetCustomerById, not just GetCustomer

• Avoid abbreviations that only make sense to the person who wrote them

• Prefix or group modules by domain so the module list reads like a map

• Stay consistent across the whole team, the exact convention matters less than everyone following it

Actions & flow

OutSystems interview questions and answers on Logic

The building blocks that actually run your business rules, client side and server side.

Q11 What type of Actions are available in OutSystems

OutSystems gives you several types of actions, each scoped to a different context:

• Screen actions, triggered by a UI event on a specific screen

• Client actions, run in the browser, can call server actions

• Server actions, run on the server, can touch the database

• Web block actions, scoped to a reusable block

• Timers, scheduled or background logic with no user present

• Data actions, wrap complex or Advanced SQL based queries

• Service actions, an ODC concept, public actions exposed by one app and consumed by another

Q12 Why we should not call two server actions in one client action

Every server action call is a full network round trip from the browser to the server and back. Calling two of them one after another inside a client action means the user waits for two round trips instead of one, and if the first one succeeds but the second fails, you can end up in a half completed state that is annoying to recover from. Merging the logic into a single server action means one round trip, one transaction, and a cleaner failure story.

Q13 What is the difference between calling two server actions A and B in a client action and merging A and B in C and calling C in the client action

Calling A then B separately gives you two network trips with the client doing something in between, which is sometimes necessary if the client genuinely needs to react to A's result before deciding what to send in B. But if there is no real reason for the client to see the intermediate result, merging A and B into a single server action C and calling that once is faster, more atomic since it runs inside one transaction, and simpler to reason about when something goes wrong.

Q14 Why we can not have output parameter in screen client action

A client action fired directly from a UI event, like a button click, has no caller waiting to receive a returned value, the browser event just triggers it and moves on. Since there is nobody positioned to consume an output, the platform does not let you define one on that type of action. Client actions that are called from other actions, rather than directly from a UI event, can have outputs.

Q15 What is server action

It is logic that runs on the OutSystems server rather than in the browser. It can read and write entities, call other server actions, run business rules, and be exposed to be called from client actions, other server actions, or through a REST API. Anything involving the database has to go through a server action, the client side simply cannot touch the database directly.

Q16 What is action as a function / What is the function property of an action

When you set an action's Is Function property to yes, it can be used inline inside an expression the same way you would use a built in function, instead of being called as a separate node in the flow. It has to behave like a pure calculation, given the same inputs it returns the same single output, without side effects on the screen.

Q17 Can an action as a function have multiple Output parameters

No. It can only ever have one.

Q18 If an action as a function can not have multiple Output Parameters, why

Because it is meant to slot into an expression the same way a formula does, and an expression can only evaluate to one value at a time. If you need multiple pieces of data back, you call it as a regular action in the flow instead of as a function, and read each output parameter separately from the flow node.

Q19 What is the difference between server action and service action

A server action lives and runs inside your own module. A service action, which is an ODC concept, is a public action exposed by a different app and consumed almost like a lightweight REST call. It creates what OutSystems calls a weak dependency between the two apps rather than a hard compile time dependency, which matters a lot for how independently the two apps can evolve.

Q20 If I add a new attribute in service action, will I require to refresh the consumers

No, and this is actually one of the nicer things about the weak dependency model. Because the consumer talks to the service action almost like a REST call rather than compiling directly against it, a change on the producer side takes effect immediately for every consumer without them needing to be republished.

Reading data

OutSystems interview questions and answers on Aggregate and Data Action

When the visual query builder is enough, and when it isn't.

Q21 What is difference between Aggregate and data action

An Aggregate is the visual, declarative way to query data, you drag entities in, set filters, sorting and joins through the UI and OutSystems generates the SQL behind the scenes. A Data Action is what you reach for when the query is too complex for that visual model, it can wrap Advanced SQL, call stored procedures, or combine multiple queries and in memory logic that an Aggregate alone cannot express.

Q22 When you would use aggregate and when Data action

Aggregate covers the vast majority of day to day screens, simple lists, filters, basic joins between related entities. You move to a Data Action when you genuinely need something the Aggregate cannot do, complex multi table joins with database specific functions, heavy performance tuning, or logic that has to combine several queries with conditional branching in between.

Q23 How you would apply an In condition in an Aggregate

You build the filter expression comparing the attribute against a list of allowed values, commonly using something like ListIndexOf against a Record List, or chaining OR conditions if the list is small and known. There is no literal IN keyword box in the Aggregate editor, so you express it through the filter expression logic instead.

Q24 What is only with, with or without, and With Join conditions in Aggregate

With is an inner join, it only returns records where the related entity actually has a match. With or Without is a left outer join, it keeps the base record even if there is no related match, filling the related columns with nulls. Only With filters the base entity down to records that do have a related match, but without pulling in the related entity's own columns, it behaves like a semi join used purely as a filter.

Withinner joinWith or Withoutleft outer joinOnly Withfilter, no columns

Q25 What is On after fetch property of Aggregate and Data action

It is a hook that runs right after the query executes but before the data is handed back to whatever called it. You use it to apply extra in memory filtering, transformation, or enrichment on the fetched records, things that would be awkward or impossible to express purely in the database query itself.

Screens & blocks

UI Design

Composing reusable UI without fighting the framework's own CSS cascade.

Q26 Can we change the Grid column count from 12 to 14, if yes how

No, not in a supported way. OutSystems UI is built on a Bootstrap style 12 column responsive grid and that number is baked into the framework's CSS. You can technically override it with custom CSS to force more columns, but you would be fighting the responsive framework and it tends to break on mobile breakpoints, so it is not something I would ship.

Q27 What are the CSS best practices

Keep it disciplined:

• Lean on the existing Style Guide and built in classes and CSS variables before writing anything custom

• Scope custom CSS at the block or screen level, not a global stylesheet

• Avoid inline styles and avoid reaching for important as a quick fix

• Keep colors and spacing consistent with the app's design system

Q28 If there is a Screen and a block inside screen, screen is having a CSS designed, block is also having its own CSS defined, which css will load first and which CSS take the highest precedence

The screen's CSS loads first because it is the outer container being rendered. The block's CSS loads after it since the block renders inside the screen. Given equal specificity, whatever loads later in the cascade wins, so the block's CSS generally takes precedence over the screen's CSS for the elements inside that block.

Q29 Can we call a web-block inside another web-block

Yes, nesting web blocks inside other web blocks is fully supported and is actually a common pattern for building composable UI, a card block might contain a smaller tag block inside it, for example.

Q30 There a web-blok which fetched data based on category selection from the screen, we want to update the web-block data when user change the category, what is the way

Pass the selected category into the block as an Input Parameter. When the category changes on the screen, you set that input parameter and refresh the block so it re-fetches its data using the new value. In practice this means wiring the screen's category change event to update the block's input and trigger its refresh, rather than trying to reach into the block's internal aggregate from the screen directly.

Q31 Can a web block trigger multiple event

Yes, a single web block can define and expose more than one distinct event to whatever is consuming it.

Q32 Can a web block trigger multiple events one after another

Yes, within its own internal logic flow a block can fire one event, continue processing, and then fire another, they do not have to be mutually exclusive.

Q33 Give me a scenario where you will use web blocks

A product card that shows the image, price and an add to cart button, reused across a search results page, a category page and a recommendations widget. Each block manages its own internal state and logic, but the screens using it just drop it in and pass a product identifier.

Load 77 More Questions

About the author: