Skip to main content





How to leverage OutSystems roles with hierarchy levels

  • Edit
    Collaborate with us
    Edit this page on GitHub
  • OutSystems Roles are very useful and easy to use. You can create authorization mechanisms in a matter of minutes with the out-of-the-box roles.

    When developing an application you must secure it, allowing or restricting end-user access to specific screens of your application. Roles are often used for:

    • Authorization mechanisms at screen level: who accesses what screens

    • Controlling displayed information: who sees what inside a screen

    • Controlling available actions: who can update/insert/delete what

    It's not uncommon for development teams to face business requirements to implement more sophisticated access control and complex authorization mechanisms. Frequently, those requirements translate into an authorization model organized as a hierarchy.

    Consider a factory and its different roles: they're organized hierarchically:

    factory roles example

    The scenario above requires you, a developer, to implement a hierarchy of roles. OutSystems Roles, as you know them, don’t allow the creation of a similar structure with built-in capabilities. However, you can implement this hierarchical structure by extending the OutSystems Roles. In this set of articles, you are going to learn how to do so.

    Disclaimer: To implement Hierarchical Roles, you need a custom implementation that depends on the use case; there is no ‘one size fits all’ solution. Depending on the use case, you can implement different solutions. In this set of articles, you are going to find a possible solution for a concrete use case.

    To understand the advantages of creating hierarchical roles, go to Hierarchical and static roles comparison.