Free Associate-Reactive-Developer Practice Test Questions and Answers (2026)

The statement is correct. In OutSystems, when multiple filter conditions are defined within an Aggregate, they are implicitly combined using the logical AND operator. This means that for a database record to be fetched and included in the final output list, it must simultaneously satisfy every single filter condition that has been defined. If a record fails to meet even one of the filter conditions, it will be excluded from the result set.

The "False" option is incorrect because it would imply that records could be included even if they don't meet all filter conditions. This would be the case if the filters were combined with a logical OR operator, where a record would only need to satisfy at least one condition. However, the default and standard behavior for Aggregates in OutSystems is to combine filters with AND, requiring all conditions to be met.

1. OutSystems Official Documentation, "Filter query results": In the section describing how to add filters to an Aggregate, the documentation explicitly states: "When you add more than one filter to an Aggregate, the platform joins them using the and operator. This means that only the database records that meet all the filter conditions are fetched."

Source: OutSystems Success Center, Documentation, "Developing an Application", "Use Data", "Query Data", "Filter query results".

2. OutSystems Official Documentation, "Aggregates": The documentation on Aggregates details their components, including Filters. It explains that the "Filters" tab is where you define the conditions to narrow down the records returned by the query, and the platform's engine translates these visual filters into a WHERE clause in the executed SQL, with multiple conditions joined by AND.

Source: OutSystems Success Center, Documentation, "Reference", "OutSystems Language", "Data", "Aggregates".

3. OutSystems Guided Path, "Reactive Web Developer", "Filtering Data" Lesson: This official training material demonstrates the process of adding filters. In the exercises and video tutorials, it is shown that adding a second filter further restricts the data from the first filter, visually and functionally reinforcing the AND logic.

Source: OutSystems Training, Guided Paths, "Becoming a Reactive Web Developer", "Reactive Web Development", "Data Queries", "Filtering Data" module.

The statement accurately describes the two primary mechanisms for communication between a parent element (like a Screen or another Block) and a child Block in OutSystems Reactive Web Apps. OnParametersChanged (Parent to Block): This is a predefined event handler within a Block. It is automatically triggered whenever the value of an input parameter, passed down from the parent, is changed. This allows the Block to react to data changes initiated by its parent. The flow of information is from the Parent to the Block. Event Handler (Block to Parent): A developer defines a custom Event within a Block to signal that something has occurred (e.g., a user clicked a button inside the Block). The Block then triggers this Event. The parent element must implement an Event Handler action to "catch" this signal and execute logic in response. This constitutes communication from the Block up to its Parent.

The alternative option, "False," is incorrect because the described directions of communication are fundamental to the architecture of reusable components (Blocks) in OutSystems Reactive applications. Reversing these roles would contradict the established and documented design pattern.

1. OutSystems Official Documentation, "Block Events": This document explicitly details the communication from a Block to its parent. It states, "Trigger events in a Block to pass information to the parent Screen or Block." It further clarifies, "To handle a Block Event, you need to define an Event Handler Action in the parent Screen or Block." This confirms the "Block to Parent" direction for Events and their Handlers.

Source: OutSystems Documentation, "Block Events", Section: "Handle a Block Event".

2. OutSystems Official Documentation, "Lifecycle Events for Blocks": This document describes the OnParametersChanged event. It specifies, "This event handler runs when the value of one or more of the Block's input parameters change." Since input parameters are set by the parent, this change originates from the parent, confirming the "Parent to Block" communication flow that triggers this event.

Source: OutSystems Documentation, "Lifecycle Events for Blocks", Section: "OnParametersChanged".

3. OutSystems Guided Path, "Becoming a Reactive Web Developer", Course: "Reactive UI Development 101", Section: "Blocks and Events": This official training material reinforces the concept. The lesson "Communicating with Events" states: "Events are a way for a Block to notify its parent about something that happened." The lesson "Reacting to Parameter Changes" explains that the OnParametersChanged event is triggered inside the Block when a parent changes the value of an input parameter.

Source: OutSystems Training, Guided Path: "Becoming a Reactive Web Developer".

The statement is incorrect because Server Actions in Outsystems are designed to encapsulate a wide variety of server-side logic, not just database operations that can be translated into SQL. While Server Actions frequently contain Aggregates or SQL Queries to interact with the database (which Outsystems does translate into SQL), they can also include logic for consuming external services (like REST or SOAP APIs), sending emails, handling files, and executing complex business rules with procedural logic (e.g., If statements, loops, assignments). This non-database logic cannot be translated into SQL. Therefore, the claim that all Server Actions can be translated into SQL is false.

The "True" option is incorrect because it presents an oversimplification of a Server Action's capabilities. It wrongly assumes that the sole purpose and entire content of every Server Action is direct data manipulation. This ignores the fundamental role of Server Actions in orchestrating business logic, integrating with external systems, and performing other server-side tasks that are unrelated to SQL.

1. Outsystems Documentation, "Consume REST APIs": This official guide demonstrates how to create Server Actions to wrap the consumption of external REST APIs. The logic within these actions involves setting up the request, calling the external endpoint, and processing the response, none of which is translatable to SQL.

Reference: Outsystems - Success Center, "Consume REST APIs", section "Create a Server Action to wrap the REST API method call".

2. Outsystems Documentation, "Logic tab": The documentation for the Logic tab in Service Studio shows the variety of elements that can be used to build server-side logic. This includes folders for "Integrations" (REST/SOAP), "Emails", and "Roles", which represent functionalities that are distinct from database queries.

Reference: Outsystems - Success Center, "Service Studio overview", section "Logic tab".

3. Outsystems Documentation, "Actions": This document defines Server Actions as reusable pieces of logic that run on the server. It mentions their use for fetching or updating data but also for implementing any "complex logic that requires the server," which is a scope far broader than just SQL operations.

Reference: Outsystems - Success Center, "Actions", section "Server Actions".

4. Outsystems Documentation, "Aggregates": This documentation explains that Aggregates are visual tools for fetching data, which Outsystems optimizes and converts into a single SQL statement. This highlights that the Aggregate is a specific tool within a Server Action that gets translated, not the entire action itself.

Reference: Outsystems - Success Center, "Fetch data using Aggregates", section "How Aggregates work".

The statement is correct. In OutSystems, attributes of a Static Entity possess an "Is Mandatory" property, just like attributes of a regular database Entity. When this property is set to True, a value must be provided for that attribute for every record defined within the Static Entity. This enforcement occurs directly within the Service Studio editor when creating or editing the Static Entity's records, ensuring that all mandatory data is present before the module is published. If the "Is Mandatory" property is set to False, the attribute can be left without a value, and it will assume the default value for its data type.

This is a "True or False" question. The statement is not False because the "Is Mandatory" property is a fundamental feature of attributes for both regular and Static Entities in OutSystems. The platform's data modeling enforces this constraint to maintain data integrity for the static, predefined records.

1. OutSystems - Official Documentation, "Static Entities": This document explains the concept of Static Entities and their records, which are defined at design time. It states, "A Static Entity has attributes, like a database Entity..." This confirms that the attribute structure is analogous to regular entities.

Reference Location: Under the "Static Entities" topic in the Data section of the OutSystems documentation.

2. OutSystems - Official Documentation, "Entity Attribute Properties": This page details the properties available for an entity attribute. It explicitly lists the Is Mandatory property.

Reference Location: In the "Properties" section of the "Entity Attribute" documentation page. The description for "Is Mandatory" states: "If True, the attribute must have a value." This property applies to attributes of both regular and Static Entities.

3. OutSystems - Official Documentation, "Create and Use a Static Entity": This guide provides a step-by-step tutorial on creating a Static Entity, adding attributes, and defining records. The process of adding attributes involves setting their properties, including "Is Mandatory," and subsequently, the process of adding records demonstrates that values must be supplied for those mandatory attributes.

Reference Location: Within the "How-to Guides" or "Tutorials" section of the OutSystems documentation, specifically the steps for "Add Attributes to the Static Entity" and "Add Records to the Static Entity".

In OutSystems, every action must have a single, defined entry point, which is represented by the Start node. Therefore, an action can only have one Start node. However, the logical flow within an action can branch into multiple paths, for example, using an If or Switch statement. Each of these distinct logical paths can terminate independently. To accommodate this and improve readability, OutSystems allows for one or more End nodes, each marking the conclusion of a specific path within the action's flow.

A. ••• one or more Start nodes but only one End node. An action must have a single, unambiguous entry point, so multiple Start nodes are not permitted.
B. ••• only one Start node and one End node. This describes a possible scenario but is not a strict rule. An action can have multiple End nodes.
D. ... multiple Start and End nodes. An action cannot have multiple Start nodes as it would create an ambiguous starting point for the logic execution. ---

1. OutSystems Official Documentation, "Action Flow":

Section: Elements > Start: "The entry point of an action flow. Each action flow has one, and only one, Start node."

Section: Elements > End: "The end point of a path in an action flow. An action flow can have several End nodes."

Source: OutSystems. (n.d.). Action Flow. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/reference/servicestudioreference/logictab/actionflow/

2. OutSystems Official Training, "Reactive Web Developer" Guided Path:

Course: Logic > Lesson: Implementing Logic: This lesson explains the fundamental components of an action. It states, "All actions have one Start Node, which is the entry point of the action. An action can have one or more End Nodes, which define the end of the logic of the action."

Source: OutSystems. (n.d.). Logic. OutSystems Training. Retrieved from https://www.outsystems.com/training/paths/18/reactive-web-developer/ (Requires login to access specific lesson content).

The statement is correct. In the Outsystems platform, a Screen is the fundamental element of a user interface (UI) for both Reactive Web and Mobile applications. The content, structure, and layout of a Screen are constructed by arranging and combining various pre-built, reusable UI elements. The official and precise term for these elements in Outsystems is "Widgets". These widgets are dragged from the Service Studio toolbox onto the Screen canvas to build the desired user interface.

The alternative, "False," is incorrect because it misrepresents the core concept of UI development in Outsystems. Screens are not built from other types of components; "Widgets" is the specific and accurate terminology used by the platform for the building blocks of a Screen's interface.

1. Outsystems Documentation - "Widgets overview": This document explicitly defines widgets as the foundational elements of the UI. It states, "Widgets are the visual elements that make up the user interface of your apps. You can find the available widgets in the toolbox in Service Studio." This directly confirms that Screens are composed of Widgets.

2. Outsystems Documentation - "Screen": This page describes a Screen as "an element of the user interface that defines the layout and content of a screen in a mobile or web app." The accompanying diagrams and descriptions show a "Widget Tree," reinforcing that a Screen's structure is a hierarchy of widgets.

3. Outsystems Documentation - "Becoming a Reactive Web Developer" Guided Path, "UI" section: The tutorials within this official training path, such as "Designing Screens," consistently demonstrate the process of dragging widgets (like Containers, Forms, Inputs, and Buttons) from the toolbox onto a Screen to build its interface. This practical application confirms the statement's accuracy.

The statement is correct. In Outsystems, a Placeholder is a designated area within a reusable UI element, such as a Block or a Layout. Its primary function is to allow developers to insert custom content when that reusable element is instantiated on a Screen. Each instance of a Block can have different widgets or content placed into its Placeholders, enabling a single Block definition to be used flexibly across an application with varying content for each use case.

The alternative, "False," is incorrect because it contradicts the fundamental design and purpose of Placeholders in OutSystems. If the content within a Placeholder had to be identical for every instance, the component would be static, and the core benefit of reusable, customizable UI patterns would be lost.

1. OutSystems Official Documentation - "Reuse UI with Blocks": In the section "How to create a Block," the documentation explains, "Placeholders in a Block allow you to define a space where you can later add content. When you use the Block in a Screen, you can drag Widgets into the Placeholder." This directly confirms that content is added at the instance level.

2. OutSystems Official Documentation - "Create and reuse screen and block templates": This document describes the use of Placeholders within Layout Blocks (e.g., Title, MainContent). It states, "Layouts use Placeholders to define where the content of each screen is to be placed." This illustrates that each Screen (an instance of the Layout) provides its own specific content for the Placeholders.

3. OutSystems Official Documentation - "Placeholders": The definition provided states, "A placeholder is a widget that you can use inside a block to mark a place where you can add content later. When you are using the block, you can add any content you want to the placeholder, such as, expressions, images, or even other blocks." This explicitly supports the concept of adding different content to each instance of the block.

In an OutSystems Aggregate, when you apply an aggregation function (such as Count, Sum, Average, etc.) to one or more attributes, the Aggregate automatically enables grouping. Any attribute that is not part of the grouping criteria and does not have an aggregation function applied to it is visually "greyed out" in the editor. This indicates that the attribute is excluded from the SQL query's SELECT list and will not be part of the Aggregate's output structure. The result set will only contain the attributes used for grouping and the attributes with aggregation functions.

The statement "False" is incorrect. If it were false, it would imply that the greyed-out columns are included in the Aggregate's output. This contradicts the fundamental behavior of a GROUP BY query in SQL, which the OutSystems Aggregate visually represents. Including a non-aggregated, non-grouped column in the SELECT list of a grouped query is a logical and syntactical error, and the OutSystems platform prevents this by excluding these columns from the result.

1. OutSystems Official Documentation, "Group data in an Aggregate": This document explicitly describes the behavior. It states, "When you use an aggregate function on an attribute, for example, Count, the other attributes of the Aggregate are automatically used to group the results... The attributes that are not used for grouping or for an aggregate function are not available in the output of the Aggregate." The accompanying images show the non-grouped, non-aggregated columns greyed out.

Source Location: OutSystems Documentation > Documentation > Developing an App > Build Apps > Logic > Fetch and Display Data > Group data in an Aggregate.

2. OutSystems Official Documentation, "Aggregates": This section provides an overview of the visual query builder. It explains that Aggregates are optimized and translate to efficient SQL. The behavior of excluding non-grouped columns is part of this optimization and adherence to standard SQL rules.

Source Location: OutSystems Documentation > Documentation > Developing an App > Build Apps > Logic > Fetch and Display Data > Aggregates.

In OutSystems Service Studio, developers can view the SQL query that the platform generates from a visual Aggregate. When an Aggregate is open in the editor, the "Executed SQL" property is available in the properties pane. This feature displays the actual SQL statement that will be executed against the database, which is invaluable for debugging, performance tuning, and understanding how the visual query translates to a database command.

The alternative, "False," is incorrect. The OutSystems platform is designed to provide developers with transparency and control. Hiding the generated SQL would hinder a developer's ability to diagnose performance issues or verify the logic of complex data fetches. The "Executed SQL" property is an explicit and standard feature of the Aggregate editor in Service Studio.

1. OutSystems Official Documentation, "Use Aggregates to Fetch Data": In the section describing the Aggregate editor interface, the documentation explicitly states: "The Executed SQL property of the Aggregate shows the SQL query that is executed on the database. Use this for debugging, for example, to test the query directly on the database."

Source: OutSystems Success Center, Documentation, "Use Aggregates to Fetch Data".

2. OutSystems Official Documentation, "Troubleshoot the performance of an Aggregate": This performance guide instructs developers on how to analyze slow queries. A key step mentioned is: "Check the SQL query that is executed on the database in the Executed SQL property of the Aggregate. Copy the SQL and run it directly on the database using a database management tool."

Source: OutSystems Success Center, Documentation, "Troubleshoot the performance of an Aggregate".

3. OutSystems Training Courseware, "Aggregates 101": Within the "Becoming a Reactive Web Developer" guided path, this course demonstrates the features of the Aggregate editor. The lesson on the editor's interface showcases the "Executed SQL" tab and explains its function as a tool for developers to inspect the underlying query generated by the platform.

Source: OutSystems Training, Guided Path: Becoming a Reactive Web Developer, Course: "Aggregates 101".

The statement is correct. In the OutSystems platform, neither Screens nor Web Blocks possess a dedicated "Output Parameter" property. Screens are the primary user interface containers and are not designed to return values like a function. They receive data through Input Parameters. Web Blocks are reusable UI components. To communicate data back to their parent element (a Screen or another Web Block), they use Events. These Events can be defined with their own parameters, which effectively serve to output data. However, this mechanism is distinct from the formal "Output Parameters" property that exists for logic elements like Server Actions and Client Actions. Therefore, a Web Block itself does not have an "Output Parameter" property in its structure.

The alternative, "False," is incorrect because a direct inspection of the properties of a Screen or a Web Block in the OutSystems Service Studio development environment confirms the absence of an "Output Parameters" folder or property. While a Web Block can output data, it does so via Event Parameters, not through a feature named "Output Parameter." The question is precise about the existence of this specific feature.

1. OutSystems Official Documentation - Screens: The documentation detailing the properties of a Screen lists Input Parameters, Local Variables, and various event handlers (OnInitialize, OnReady, etc.), but makes no mention of Output Parameters.

Source: OutSystems Documentation, "Screens for Reactive Web and Mobile Apps".

Section: "Screen properties and scope". This section details the available properties for a Screen, none of which are Output Parameters.

2. OutSystems Official Documentation - Web Blocks: The documentation on creating and using Blocks details their structure, which includes Placeholders, Input Parameters, and Events. It does not include Output Parameters.

Source: OutSystems Documentation, "Reuse UI with Blocks".

Section: "What is a Block?". The diagram and description of a Block's elements show Input Parameters for passing data in, but not Output Parameters for passing data out.

3. OutSystems Official Documentation - Events in Blocks: This document explicitly describes the correct mechanism for a Block to send data to its parent. It confirms that this is achieved by defining an Event within the Block and adding parameters to that Event.

Source: OutSystems Documentation, "Create and Use an Event in a Block".

Section: "Pass data from a Block". The guide states: "To pass data from a Block to the parent, add input parameters to the Event." This clarifies that the data is passed via event parameters, not a direct output parameter of the Block itself.

The statement is false. In OutSystems, every entity must have a primary key, which is referred to as the Entity Identifier. This identifier is always a single attribute and cannot be a composite key (a key composed of multiple attributes). When a new entity is created, OutSystems automatically generates a unique, single-attribute identifier (typically Id with a Long Integer data type), which serves as its primary key. While you can change the data type of this identifier, you cannot configure it to be a composite key.

The "True" option is incorrect because it contradicts the core data modeling architecture of the OutSystems platform. OutSystems enforces the use of a single-attribute primary key for all entities created within its environment to ensure consistency, simplify relationships, and optimize performance for its internal data handling mechanisms. The platform does not provide a feature to create or define composite primary keys for its entities.

1. OutSystems Official Documentation - "Entity identifier": This document explicitly states the nature of entity identifiers.

Quote: "Each entity has an identifier that uniquely identifies each record. The identifier is a single attribute and it's the entity's primary key."

Reference: OutSystems. (n.d.). Entity identifier. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/reference/outsystemslanguage/data/databasereference/entityidentifier/

2. OutSystems Official Documentation - "Create an Entity": This guide on creating entities reinforces the automatic creation of a single identifier.

Quote: "When you create an entity, Service Studio automatically adds an attribute to be the entity identifier. By default, the attribute is named Id and its data type is set to Long Integer with the Is AutoNumber property set to Yes."

Reference: OutSystems. (n.d.). Create an Entity. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/developinganapplication/usedata/datamodeling/createanentity/

3. OutSystems Training Courseware - "Modeling Data": The official training materials for developers consistently describe the data model as using single-attribute identifiers.

Concept: In the "Data Model" section of the "Developing OutSystems Web Applications" (and Reactive) courses, entities are always presented with a singular Id attribute as the primary key, with no mention or provision for composite keys.

Reference: OutSystems. (n.d.). Modeling Data [Guided Path]. OutSystems Training. Retrieved from https://www.outsystems.com/training/paths/18/becoming-a-reactive-web-developer/ (Content within the "Data Modeling" section).

The statement is false. While the primary and recommended use of the SQL Query tool in Outsystems is for executing complex SELECT statements to retrieve data, it is not strictly limited to them. The tool can also be used to execute other Data Manipulation Language (DML) statements such as INSERT, UPDATE, DELETE, and to call stored procedures using EXEC or CALL. Outsystems best practices strongly advise against using the SQL Query tool for data modification, recommending the use of platform-provided Entity Actions (e.g., Create, Update) instead. When a non-SELECT statement is used in the SQL tool, the platform's IDE (Service Studio) will typically issue a warning, but it does not prevent the execution of the command.

The statement "True" is incorrect because it presents an absolute restriction that does not exist. The SQL Query tool is capable of executing more than just SELECT statements, even if it is not the recommended practice for other types of operations.

1. Outsystems Official Documentation - SQL Best Practices: In the "Data handling" section, the documentation states, "Avoid using SQL Queries to perform Create, Update, or Delete operations on the database. Use the corresponding Entity Actions instead." This recommendation implicitly confirms that it is technically possible to perform these operations using the SQL Query tool, otherwise, there would be no need to advise against it.

Source: Outsystems - Success - Best Practices - SQL Best Practices.

2. Outsystems Official Documentation - Use SQL Queries: This document details how to use the SQL tool, including a section on executing stored procedures. It provides an example: EXEC spGetOrderByDate @StartDate, @EndDate. Stored procedures can contain any number of DML statements (INSERT, UPDATE, DELETE), proving the SQL tool is not limited to SELECT statements.

Source: Outsystems - Documentation - Develop an App - Logic - Use SQL Queries.

3. Outsystems Platform Behavior (Service Studio): When a developer writes a non-query statement (e.g., UPDATE, DELETE) in the SQL Query editor, Service Studio generates a warning: "SQL query is not a SELECT statement. Consider using 'Execute In: Server' and call it from a Server Action." This warning confirms the platform recognizes and can process the statement, while guiding the developer toward a better practice, rather than prohibiting the action entirely.

Source: Direct observation of the Outsystems Service Studio IDE behavior, which is a primary source for platform-specific functionality.

In Outsystems, when writing custom SQL queries, the platform requires a specific syntax to reference its logical data model elements. An Entity is referenced by enclosing its name in curly braces, such as {Entity}. An Entity Attribute is referenced by first specifying the Entity it belongs to, followed by a dot, and then the Attribute's name enclosed in square brackets, such as {Entity}.[Attribute]. This syntax allows the Outsystems platform to abstract the physical database names, automatically replacing these placeholders with the correct physical table and column names during query execution. This ensures portability and maintainability.

A. Angle brackets are not the correct delimiters for referencing entities or attributes in Outsystems SQL queries.
B. The syntax for referencing an attribute is incomplete. It must include the attribute name enclosed in square brackets, like [Attribute].
D. This option incorrectly uses angle brackets and also omits the required square brackets [] for the attribute name.

1. Outsystems. (n.d.). Use SQL queries. Outsystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/developinganapplication/usedata/querydata/usesqlqueries/. See the section "Syntax for Referencing Entities and Attributes".

2. Outsystems. (n.d.). SQL Element. Outsystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/reference/servicestudioreference/logicreference/serveractionsandscreenactionstools/sql/. The "SQL Statement" property description explicitly states: "To reference an entity or an attribute in the SQL query, use the syntax {Entity} and {Entity}.[Attribute]".

3. Outsystems Training. (n.d.). Developing Web Apps (O11) Guided Path. Outsystems Learn. In the "Data Queries" module, the lesson on "SQL Queries" details this specific syntax for referencing platform entities and attributes.

The statement is correct. In Outsystems, a Block can communicate with its parent (a Screen or another Block) by triggering Events. When defining an Event within a Block, you can set its Is Mandatory property to 'Yes'. This enforces a contract requiring any consumer of the Block to provide a handler for that event. The handler is a Client Action within the parent's scope. If a handler is not defined for a mandatory event, Outsystems' Service Studio will report a validation error, preventing the application from being published. The platform allows this required Client Action handler to be empty (i.e., containing only a Start and an End node), which satisfies the compiler's requirement without needing to implement any specific logic.

The statement cannot be False because failing to define a handler for a mandatory event is a compile-time error in Service Studio. The platform's compiler explicitly requires that a Client Action be assigned as the handler for any Block event where Is Mandatory is set to 'Yes'.

1. Outsystems Official Documentation, "Create and use events in Blocks": In the section "Define an Event in a Block", the documentation for the Is Mandatory property states: "If you set Is Mandatory to Yes, you must define a handler for the Event in the parent Block or Screen." This directly confirms the requirement for a handler.

Source: https://success.outsystems.com/documentation/11/developinganapplication/designui/reuseui/createanduseeventsinblocks/

2. Outsystems Official Documentation, "Handling Events": The section "Handle an Event" illustrates the process of creating a handler. When a Block with a mandatory event is used, the developer must select "New Client Action" for the event's Handler property. The newly created action, which can be left empty, satisfies the requirement.

Source: https://success.outsystems.com/documentation/11/developinganapplication/designui/reuseui/createanduseeventsinblocks/#handle-an-event

3. Outsystems Training Courseware, "Reactive UI Development 101": The official "Blocks and Events" module, part of the guided path for the Associate Reactive Developer certification, teaches this as a core concept. It explains that mandatory events create a strict contract between a Block and its parent, and the parent is obligated to create a handler action.

Source: https://www.outsystems.com/training/courses/126/reactive-ui-development-101/, Module: "Blocks and Events".

The Combo Box widget in OutSystems Reactive Web Apps is designed to display a list of options to the user. The primary source for these options is set in the List property, which is typically bound to a dynamic data source, such as an Aggregate that fetches records from an Entity. Additionally, the widget includes a Special List property. This property allows a developer to add one or more static, predefined options (e.g., a null option like "- Select an item -" or an "All" option) to the list. The final list of values rendered in the browser is the union of the items from the Special List and the items from the main List property, effectively creating a combined list.

The "False" option is incorrect because the Special List is a specific, documented feature of the Combo Box widget intended to work in conjunction with the main List data source. The widget's functionality explicitly supports combining these two sources to form the final dropdown list.

1. OutSystems Documentation - Combo Box Widget: The official documentation for the Reactive Combo Box widget lists both the List property (for the main data source) and the Special List properties (Special List Value, Special List Option) as available properties, demonstrating they are intended to be used together.

Source: OutSystems. (n.d.). Combo Box Widget. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/developinganapplication/designui/patterns/usingmobileandreactivepatterns/utilities/combobox/

Specific Section: Properties table, rows for List and Special List.

2. OutSystems Guided Path - Becoming a Reactive Web Developer: In the training materials for reactive developers, the concept of using a Special List to add a null or "empty" option to a dropdown populated from an entity is a standard topic.

Source: OutSystems. (n.d.). Dropdowns. Becoming a Reactive Web Developer Guided Path.

Specific Section: The module on UI and Screen Development covers form widgets, including the Dropdown/Combo Box, and explicitly teaches the use of the Special List property to add a "Select..." option to a list fetched from a database.

3. OutSystems How-to Guide - Add an Empty Option to a Dropdown: This official guide provides a step-by-step tutorial that directly addresses this scenario. It instructs the developer to populate the dropdown from a database (Entity) and then use the Special List properties to add the empty/null option.

Source: OutSystems. (n.d.). Add an empty option to a dropdown. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/howtoguides/frontend/addanemptyoptiontoadropdown/

Specific Paragraph: The introduction states, "To add an empty option (or any other special option) to a dropdown list that's populated from a database query, use the Special List properties of the Dropdown or Combo Box widget."

The statement is incorrect. The "Delete" option for the Delete Rule property does ensure referential integrity through a mechanism known as a cascading delete. When a record in the referenced (parent) entity is deleted, the database automatically deletes all corresponding records in the entity that holds the foreign key (child entity). This action prevents any "dangling references," where a foreign key would point to a non-existent record, thus maintaining the integrity of the relationship. While it is true that this rule should be used with caution due to the potential for unintended mass deletion of data, the primary claim that it does not ensure referential integrity is false. The rule that does not ensure referential integrity is the "Ignore" rule.

The "True" option is incorrect because it misrepresents the database behavior defined by the "Delete" rule. Official Outsystems documentation explicitly states that both the "Protect" and "Delete" rules are mechanisms to ensure referential integrity. "Protect" ensures it by preventing the deletion of a parent record with dependencies, while "Delete" ensures it by removing those dependencies simultaneously with the parent record.

1. Outsystems Official Documentation - "Define entity relationships": In the section detailing the Delete Rule property, the documentation states for the Delete option: "When you try to delete a record from the entity with the primary key, the database also deletes all the corresponding records in the entity that has the foreign key. This also ensures referential integrity." In contrast, for the Ignore option, it states: "This means that referential integrity is not ensured."

Source: Outsystems Success Center, "Define entity relationships", under the "Delete Rule property" section.

2. Outsystems Training Courseware - "Modeling Data": The guided path on data modeling explains the fundamental concepts of database relationships and integrity. In the tutorials covering entity relationships, it is clarified that the Protect (default) and Delete rules are the two options provided by the platform to enforce referential integrity automatically at the database level.

Source: Outsystems Training, Guided Path: "Becoming a Reactive Web Developer", Course: "Modeling Data", Section on Entity Relationships.

The statement is incorrect. In OutSystems, when defining an Input Parameter for an Action, Screen, or Block, developers can configure its Is Mandatory property. This property is a boolean that determines whether a value must be supplied for the parameter. If Is Mandatory is set to False, the parameter becomes optional, and if no value is passed during the call, it will use its specified Default Value. Therefore, input parameters are not always mandatory.

The option "True" is incorrect because the OutSystems platform provides a specific property, Is Mandatory, to explicitly control whether an input parameter is required or optional. The existence and use of this property directly contradict the absolute statement that parameters are always mandatory.

1. OutSystems Official Documentation, "Input Parameter properties": This document explicitly details the properties of an input parameter. It states: "Is Mandatory: Defines if the input parameter is mandatory or optional. If True, the parameter is mandatory. If False, the parameter is optional." This directly confirms that parameters can be optional.

Source: OutSystems Documentation, https://success.outsystems.com/documentation/11/reference/servicestudioreference/logicreference/elementsreference/inputparameterproperties/

2. OutSystems Official Documentation, "Actions in Reactive Web and Mobile Apps": This guide explains the creation and usage of actions. When describing how to add an input parameter, the properties pane is shown, which includes the Is Mandatory setting, reinforcing that this is a configurable attribute for every input parameter.

Source: OutSystems Documentation, https://success.outsystems.com/documentation/11/developinganapplication/implementapplicationlogic/actionsinreactivewebandmobileapps/

3. OutSystems Guided Path, "Becoming a Reactive Web Developer > Client and Server Actions": This official training courseware demonstrates the creation of both client and server actions. In the exercises, it guides developers on how to add input parameters and configure their properties, including setting them as mandatory or optional, which is a fundamental concept for new developers.

Source: OutSystems Training, https://www.outsystems.com/training/paths/18/becoming-a-reactive-web-developer/ (See the "Logic" section and associated tutorials on Actions).

The statement is correct. A core feature of the OutSystems platform, designed to accelerate development, is the ability to automatically generate screens with pre-built logic and data structures for common application patterns. This process is often referred to as "scaffolding". When a developer drags a data Entity (which defines the data structure) onto a UI Flow in Service Studio, OutSystems automatically creates a List screen to display records and a Detail screen to create or edit a single record. These generated screens include the necessary Aggregates to fetch data, UI widgets bound to the data, and server-side logic to handle create, update, and delete operations. Why the "False" Option is Wrong: The "False" option is incorrect because it contradicts a fundamental, time-saving feature of the OutSystems platform. The platform is explicitly designed with accelerators like screen scaffolding to minimize repetitive coding tasks and speed up the delivery of functional applications. Denying the existence of pre-built screens with logic and data would be a misunderstanding of OutSystems' core value proposition.

1. OutSystems Documentation - "Scaffold a Listing and Detail Screen": This official guide explicitly details the process. It states, "To speed up development, you can scaffold screens from database Entities. When you scaffold, Service Studio creates the Listing and the Detail screens for the Entity you select. The screens have the logic to list, add, update, and delete records."

Source: OutSystems Inc. (2024). Scaffold a Listing and Detail Screen. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/developinganapplication/designui/screens/scaffoldalistinganddetailscreen/

2. OutSystems Documentation - "Create a New Screen": This document describes the use of Screen Templates, which are pre-built screen layouts. It mentions, "Service Studio provides a set of screen templates that you can use to create your screens. These templates already have a screen structure and Widgets, and some of them even have the logic implemented." This confirms the availability of pre-built screens with logic.

Source: OutSystems Inc. (2024). Create a New Screen. OutSystems Documentation. Retrieved from https://success.outsystems.com/documentation/11/developinganapplication/designui/screens/createanewscreen/

3. OutSystems Guided Path - "Reactive Web App Development": In the "Modeling Data" and "Building Screens" sections of this official training path, the scaffolding feature is a key lesson. The tutorial demonstrates dragging an Entity to the Main Flow to automatically generate the List and Detail screens, showcasing how the platform creates the screens, data Aggregates, and associated logic.

Source: OutSystems Inc. (2024). Building Screens. Reactive Web App Guided Path. Retrieved from https://www.outsystems.com/training/paths/18/reactive-web-app-development/ (Specific lesson on screen creation).

In an Outsystems Reactive Web App, a Screen is a user interface element designed to display information and handle user interaction. To fulfill this role, it can define two types of variables:
1. Input Parameters: Used to pass data into the Screen from another Screen or a Block, allowing for dynamic, context-specific content (e.g., passing a UserId to display a specific user's profile).
2. Local Variables: Used to store temporary data and manage the Screen's internal state. Their scope is limited to the Screen itself (e.g., storing user input from a form field before saving). Screens do not have Output Parameters, as their primary function is rendering a UI, not returning values to a calling element like a Server or Client Action.

A. Local Variables only. This is incorrect because Screens often require Input Parameters to receive data from other parts of the application to display relevant information.
B. Input Parameters only. This is incorrect because Screens need Local Variables to manage their internal state, handle form data, and control UI element visibility.
C. Input Parameters, Output Parameters, and Local Variables. This is incorrect because Screens do not have Output Parameters. This type of parameter is used by logic elements like Client Actions and Server Actions to return data. ---

1. Outsystems - Official Documentation, "Types of variables": This document outlines the different variable types. It specifies that Input Parameters pass data to an element (like a Screen), Local Variables hold data within an element's scope, and Output Parameters are used to pass data from an Action. This implicitly confirms Screens do not have outputs.

Reference: Outsystems Documentation, Develop an App > The Fundamentals > Variables > Types of variables.

2. Outsystems - Official Documentation, "Pass data between Screens": This guide explicitly demonstrates the use of Input Parameters to send data to a destination Screen. It shows how to add an Input Parameter to a Screen to receive a value.

Reference: Outsystems Documentation, Develop an App > UI > Screens > Pass data between Screens, Section: "Pass data to a Destination Screen".

3. Outsystems - Official Documentation, "Create your first Reactive Web App" Tutorial: In this foundational tutorial, step-by-step instructions for building screens involve creating both Input Parameters (for detail screens) and Local Variables (for managing form state), but never Output Parameters for a Screen.

Reference: Outsystems Guided Paths, "Reactive Web Developer", Course: "Becoming a Reactive Web Developer", Module: "Reactive UI Development 101", Section: "Variables in Reactive Web Apps".

An Outsystems Aggregate is a visual tool for querying data from database entities. It always returns a variable of the List data type. If the query's filters and conditions do not match any records in the database, the Aggregate's output is a list that contains zero records. This is referred to as an empty list. You can verify this by checking the .Empty runtime property of the Aggregate's output list, which will evaluate to True in this scenario.

A. Null List: In the Outsystems platform, a List variable is never null. Upon creation, it is initialized as an empty list.
C. List has an empty record: The list will contain zero records, not a single "empty" or null record.
D. List has a record with default data: The Aggregate returns only the records that match the query criteria; it does not fabricate a default record if no matches are found. ---

1. Outsystems Official Documentation, "Aggregates": This document describes the function of Aggregates, stating, "An Aggregate returns a List of records with the data you need in your application." It does not mention returning null or default records. (See section: "What is an Aggregate?")

2. Outsystems Official Documentation, "Data Types - List": This source clarifies the behavior of the List data type. It states, "A List variable is never Null. When you create a List variable, it is initialized with an empty list." (See section: "List")

3. Outsystems Official Documentation, "If Widget": The documentation for control flow widgets frequently provides examples of checking an Aggregate's result. A common pattern shown is GetMyEntity.List.Empty as the condition, which confirms that an empty list is the expected output when no records are found. (See section: "Common Usage Scenarios")

4. Outsystems Learn, "Reactive Web Developer Guided Path - Fetch and Display Data": In the exercises for fetching data, the platform's training material explicitly teaches developers to handle the case where a query returns no data by checking if the Aggregate's list is empty. (See module: "Modeling Data > Fetching and Displaying Data")