Reactive Web Apps: Custom Screen Access  and Action Validation


I'm trying to create a custom user management in which it can set which screen a user can access to and what action are allowed for that user, example user A can access screen A but only can view, while user B can access screen A and allowed to entry new data.

My question is, how do you check in that screen if current logged in user has access to that screen or allowed to see the "Create New" Button before the screen finished loading? 

This just to prevent bad UX like when a user not allowed to create, the add button get rendered at first but after the data get fetched the button then get hidden. 

Another example is when a user not allowed to access this screen but the screen already halfway rendered then validation fetched and redirect user to no permission page.


Hi ,

you should try roles for it.

Like when user created you can provide a role for it like View,read Write etc.

check this on screen logged in used access which role and provide functionality according role.

Hope this will help you.




Hi Wenchester,

That is a good question.

You can save this configurations in the database and fetch it in an aggregate on the screen.

You can enclose the showing of screens with <name of your query>.IsDataFetched to make sure you don't display something the user hasn't right to.

While <name of your query>.IsDataFetched is false, you show a loader effect, otherwise you can show the data according to the data from the query.

Kind Regards,



Hello Wenchester,

I recommend the online training on Reactive Web Development:

More precisely, the role-based lesson:

The thing that is important here is: Do you really NEED to have a definition of access per user/screen?
In OutSystems, the traditional (and built-in) way of doing something is through roles (as it was mentioned). SO, you create roles, then you define the roles that can access a screen (screen Roles section properties), and on the screen, what the users can see/use based on roles (based on IF widgets/Visible/Enable properties), validate the role on actions and so on.

But for this to work, you need to have a "role system" for the users and base your permissions on the roles.

If you REALLY need a finer grain role system, that is always a nightmare (define permissions for a user by feature?), than you have to implement the system yourself, probably using an entity to store the permissions for each user and checking this on every screen.

I highly recommend you to NOT follow this path...
Sticky to the traditional Role System if you can.


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.