Skip to main content

Developing an Application



User Roles

Roles are used to restrict or allow end-users to access specific screens and operations of your application.

Roles are set at design time. You can use them when designing the logic of your application and you can associate them with the following elements:

  • Screen;
  • Human Activity;
  • Send Message (SMS Flows);
  • Wait for Message (SMS Flows).

System Roles and Custom Roles

When you create a new module in Service Studio, OutSystems provides you with a default set of System Roles but you are allowed to define your own custom Roles.

OutSystems provides the following System Roles:

  • Anonymous: Allows any end-user to access the element, including users that are not logged in (non-authenticated users). Anonymous is the most general Role and when you associate this Role, for example with a screen, all of the existing Roles are automatically associated with it.
  • Registered: Allows any end-user who has logged into an Application running in the same platform server (authenticated users) to access the element. This is possible due to the Single Sign-On mechanism of OutSystems, which allows sharing end-user sessions among applications/modules. When you associate this Role with an element all of the existing Roles are automatically associated with it, except the Anonymous role.

Besides the System Roles already provided, you can define your own custom Roles to manage the access of end-users to the screens and operation of your application.

The following Role is provided by default when you create the first module of your application:

  • <Module Name>User

Persistency in Roles

Permissions can be persistent across multiple sessions, or only be granted for a single session.

  • Persistent: The association between the end-user and the Roles is stored in the database. Every time the end-user logs in, the association between the end-user and the Roles is established. Set the Is Persistent property of the Role to Yes.
  • Not persistent: The Role is only associated with the user for a single session, and not persistent in the database. When the end-user logs in for the second time, the Role is not associated with the end-user. Set the Is Persistent property of the Role to No.

When end-user authentication and authorization is performed using an external system, non-persistent Roles should be used. This makes it easier to map permissions defined in an external system, such as Active Directory, to OutSystems Roles. Using non-persistent Roles ensures that changes to end-user permissions made in the external system are reflected in OutSystems.


Articles in this Section

  • Was this article helpful?