Study guide

Role-based Security: Roles, Accessible By, CheckRole, GrantRole, Anonymous

OutSystems Certified Associate Developer Reactive Web Apps

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Exam Overview, Logistics, and Study Strategy

2 Chapter 2 — OutSystems Platform and Reactive App Fundamentals

OutSystems Platform Architecture, Service Studio, and Development Tools Client Variables and State Management Screen Lifecycle Events: OnInitialize, OnReady, OnParametersChanged Debugging and Monitoring with the Service Studio Debugger and Service Center

3 Data Modeling

Entities, Attributes, Data Types, and Identifiers Static Entities and Structures Data Relationships, Foreign Keys, and Referential Integrity

4 Chapter 4: Fetching Data

4.1 Aggregates: Filters, Sorting, and Max Records 4.2 Aggregates: Joins, Group By, and Computed Attributes 4.3 Fetching Data on Screens with Data Actions, Caching, and RefreshData 4.4 SQL Queries and External Integrations: REST and SOAP Consumption

5 Logic Flows and Actions

Client Actions, Server Actions, and Action Parameters Logic Flow Control: If, Switch, For Each, and Assign Form Validations: Mandatory, Email Type, and Form.Valid

6 Chapter 6: Error Handling and Advanced Logic

Exception Handling: Exception Handlers, Raise Exception, System vs User Exceptions, AbortTransaction Timers, BPT Processes, Human Activities, and Built-in Functions

7 UI Design: Screen Widgets

Core Screen Widgets: Screen, Container, Expression, If, Link, and Button Forms, Input Widgets, Data Binding, and Feedback Messages List Widget, Pagination, and Screen Navigation Themes, CSS Styling, OutSystems UI, and UI Patterns (Popup/Modal)

8 UI Design: Blocks and Events

Blocks: Creating Reusable UI Components with Input Parameters and Local Variables Block Events and Parent-Screen Communication

9 Architecture, Security, and Lifecycle

Modular Dependencies, Public/Private Elements, and Layered Architecture Role-based Security: Roles, Accessible By, CheckRole, GrantRole, Anonymous Application Lifecycle: 1-Click Publish, LifeTime, Environments, and Versioning

Role-based Security: Roles, Accessible By, CheckRole, GrantRole, Anonymous

Key Takeaways Explain This Topic AI

The Registered role is automatically assigned to every authenticated user; anonymous users have no roles.

The Accessible By property on Screens controls access: All (including anonymous), Registered (logged-in), or specific Roles.

CheckRole(RoleName) is a built-in function returning True if the current user has the specified role, used in If widgets and Server Actions for granular control.

GrantRole and RevokeRole are Server Actions that assign or remove roles at runtime; they cannot be called directly from Client Actions.

GetUserId() returns NullIdentifier() (0) for anonymous users, providing a way to check login status inside logic flows.

Last updated: July 2026

Quick Answer: OutSystems security is role-based. Roles are defined per module and assigned to users through the Users app or programmatically via GrantRole. Every Screen and Block has an Accessible By property controlling who can see it: All (including anonymous), Registered (logged-in), or specific Roles. The CheckRole built-in function tests roles inside logic flows, and the special Registered role is auto-assigned to every authenticated user.

Roles and the Registered Role

A Role in OutSystems represents a user privilege or persona (e.g., Admin, Manager, Customer). Roles are created in Service Studio at the module level, but once published they become available app-wide and are assigned to individual users through the Users application or programmatically. Every authenticated user automatically has the built-in Registered role — this is how you distinguish logged-in users from anonymous visitors without defining a custom role for it.

  • Role Type Who Has It How Assigned
  • Registered Every logged-in user Automatic on authentication
  • Custom (e.g., Admin) Specific users Users app, GrantRole action, or SSO role mapping
  • (none) Anonymous / not logged in N/A — no roles assigned

Roles are boolean per user : a user either has a role or does not. There is no hierarchy or inheritance — if Manager should include everything Employee can do, the user must be granted both roles, or the Screen's Accessible By must list both. This flat model keeps security explicit and auditable.

Accessible By Property

The Accessible By property on Screens (and Blocks) is the primary UI-level security gate. It controls who can navigate to the Screen or render the Block.

  • Accessible By Value Who Can Access Use Case
  • All Anyone, including anonymous Login screen, public landing pages
  • Registered Any logged-in user User dashboard, account settings
  • Specific Role(s) Only users with that role Admin panel, manager-only reports

When Accessible By is set to a specific role and a user without that role tries to navigate to the Screen, OutSystems redirects them to the login page (if anonymous) or shows a not-authorized message (if logged in but lacking the role). In Reactive Web Apps, this check happens at runtime on both the client and the server — the server enforces it for Data Actions and Aggregates, so a malicious client cannot bypass it by manipulating the URL or client state.