Role-Based Access Control in OutSystems: Complete Implementation

Open Service Studio. In the right-side panel, click the **Logic tab** (gear icon). Expand the **Roles** folder. Right-click Roles → select **Add Role**. Name the role (e.g., `Manager`). Repeat for each role you need (e.g., `Admin`, `ReadOnly`). After creating roles, click the **1-Click Publish** button (top center) to compile — TrueChange will show no errors for a valid role name.

Navigate to **Interface tab → UI Flows → MainFlow** and double-click the screen you want to protect (e.g., `ManagerDashboard`). Click anywhere on the canvas to deselect all widgets. In the **Properties panel** (right side), locate the **Roles** property. Click the dropdown → uncheck `Anonymous` and `Registered` → check `Manager` (and any other roles that should have access). Save with Ctrl+S. When an unauthorized user navigates to this screen, OutSystems automatically redirects them to the `InvalidPermissions` screen (or the login screen if not logged in).

Even when a screen is protected, always validate roles inside sensitive Server Actions — a user could call an API endpoint directly. Go to **Logic tab → Server Actions** → open the Server Action that performs the sensitive operation (e.g., `DeleteRecord`). At the very start of the action flow, drag an **If** element from the Toolbox. Set the condition to `CheckManagerRole()`. Connect: - **[True]** branch → your existing logic - **[False]** branch → drag a **Raise Exception** element → choose `Security Exception` → set Message to `"Insufficient permissions"`. Action flow: Start → If CheckManagerRole() → [True] existing logic → End / [False] Raise Security Exception

1/* Expression for the If condition */
2CheckManagerRole()
3
4/* In [False] branch: Raise Exception */
5Exception Type: Security Exception
6Message: "Insufficient permissions to perform this action"

To show a button, menu item, or section only to users with a specific role, use the **Visible** property on a widget combined with `CheckManagerRole()`. In the Screen Editor, select the widget (e.g., a `Delete` button). In the Properties panel, find the **Visible** property. Click the expression editor (fx icon) → enter `CheckManagerRole()`. Save and publish. For multiple widgets, wrap them in a **Container** widget, set `Visible = CheckManagerRole()` on the container, and all children inherit the visibility.

1/* Visible property expression for a Button widget */
2CheckManagerRole()
3
4/* For AdminOnly container — visible to Admin OR Manager */
5CheckAdminRole() Or CheckManagerRole()

Use the auto-generated system actions to assign roles at runtime — for example, after admin approval or during user registration. Go to **Logic tab → Server Actions** → open `CreateUser` or `ApproveUser`. In the action flow, after saving the user record, drag an **Assign** node. Use `GrantManagerRole(UserId)` to grant the role, passing the target user's Id. To remove a role: use `RevokeManagerRole(UserId)`. Action flow example: Start → CreateUser → Assign UserId = CreateUser.CreatedId → GrantManagerRole(UserId) → End

1/* Grant role to a user */
2GrantManagerRole(UserId: NewUser.Id)
3
4/* Revoke role from a user */
5RevokeManagerRole(UserId: TargetUser.Id)
6
7/* Check if a specific user has a role (not just current user) */
8CheckManagerRole(UserId: TargetUser.Id)

Before publishing, check the TrueChange tab at the bottom of Service Studio. Any missing role references or invalid Check<Role> calls show as red errors. Warnings (orange) about roles on screens that have no user navigation to them are acceptable. To test: publish the module (1-Click Publish button, top center). Open the app in a browser. Log in as a user without the Manager role — navigate to the protected screen and verify the redirect. Log in as a Manager user — verify access, visible buttons, and action execution. For more thorough testing, go to **Service Center** (your environment URL `/ServiceCenter`) → **Users** → assign and remove roles from test users without changing code.