Multi user access for SaaS agile platform application

Multi user access for SaaS agile platform application

How would outsystems implement the following multi access feature for an SaaS agile platform application
"Multi-User Access feature allows you to give multiple users various levels of access to a single Business account. With Multi-User Access, you can add multiple logins and access levels for your employees, so they can complete necessary tasks without having access to extraneous features. By controlling the access your users have to your account, you can run your business smoothly and not have to worry about allowing total access to your account."
User Business X has an account with the system, business X can have user staff/contractors with roles such as accountant, developers, etc...
User Business Y has an account with the system, business Y can have user staff/contractors with roles such as accountant, developers, etc...
(Optional) A contractors can have many different roles, for each business user; ie can be an admin under business X, and then a developer under business Y or both developer under X and Y.
"System" is a SaaS agile platform application, it has many registered business USER, and under each business can have many staff/contractors USER.

Hi Robert,

Regarding the separate businesses, to achieve your goal, you should really model those businesses as part of your data model, queries and business logic and specify in your application which users belong to which businesses.

Regarding “acess levels”, for the first two stories in your example, the different roles people play really map directly to the standard Agile Platform Roles (see help here) which should be very easy to use. If you want to support the third story, then you’ll need to have multitenancy on the data, which means applying row level security (ensure that a user only sees data he is allowed to for a given condition). As such, I would
  1. Model the Business -> BusinessRole -> User relation in the application and manage it in a custom backoffice
  2. Eventually create a hidden Group for each combination of User – BusinessRole
  3. Create a helper function CheckGroup(RoleId, UserId, GroupId) that allows you to check on every screen if the user has access to that data.
  4. On the queries, you’ll need to enforce that the returned data is relative to that customer
Hope this helps.

All the best,
     Pedro Oliveira 
Hi Robert,
Totally agree with Pedro and probably the major feature to acomplish the multi access SaaS concept is "multitenancy" (combined with extended Business Logic)!
The multi-tenant feature is being used bylarge customers since 2005 I guess and its very stable! Its possible to ensure a excelent isolation level for data! 

As well it's important to evaluate some future customer needs, like SEO usage once the multi-tenant feature will create a "tenant" level for access...wich means you'll have the tenant name on your url:

Good luck!

Rafael Pereira 
I found that in a SaaS scenario, you need to model it yourself like I did in my SaaS Framework, to get the flexibility you need. Last I checked, the multi-tenency has issues with multiple applications per machine. :(

If you're looking to do a SaaS-type situation, feel free to Skype me and I'll gladly give you some pointers on what I did.


Thanks for your contribution guys. In fact you're both right.

When I talked about "multi-tenancy" above I was really talking about the concept and not the "multi-tenant feature". At this point the feature does have a set of limitations, which we will address at some point, which probably make it not be the best option for this specific scenario.

All the best,
Here's what I did to solve this issue...

(cheap plug: I sell the full package for handling this, a kind of "starter kit" for SaaS applications... contact me if you would like more details)

First, I use the Users entity, but I ignore all of the "USER_MASTER" kind of stuff. I just use the built-in functionality for handling users, sessions, logins, etc. But I add a "USER_DETAILS" entity which is extendable and refers to the "User" entity. I also have an "ACCOUNT" entity which represents one of our clients. USER_DETAILS links to ACCOUNT, and ACCOUNT links to a User as the "Account Administrator" (that user also get the "Account Administrator" privilege assigned to it). In certain parts of the application, it looks for the combination of checking to see who the Account Administrator is, and validating the current user having that privilege, to allow upscale access. I use a "CUSTOMERS" entity to represent the customers of the application's clients.

In the Spanner Planner application ( which allows auto repair shops to manage their work, the chain is like so:

ACCOUNTS (Mike's Repair Shop, Jimmy's Muffler Shack, etc.)
Users (Mike's Repair Shop: Mike [Account Administrator], Susan, John; Jimmy's Muffler Shack: Jimmy [Account Administrator], Louis, Barbara)
CUSTOMERS (Mike's Repair Shop: Car Dealer 1, Car Dealer 2, etc.; Jimmy's Muffler Shack: Car Owner 1, Car Owner 2, etc.)

All entities need to have a link to ACCOUNT, so that you can check which ACCOUNT the current user belongs to, and check it against the ACCOUNT of the entity, to validate that they should have access. Otherwise, someone could take an ID in the URL, change it, and potentially access data belonging to another ACCOUNT. For the same reason, you never want to just count on the "Account Administrator" permission, you want to combine it with looking at the Account Administrator attribute of ACCOUNT to ensure that the current user is the admin for the account in question.

I've got a ton of other things built in too, like password resets (both self-service and by the account administrator), allowing account administrators to add users to the account, monthly billing, closing accounts when billing fails, a global admin system, and so on.


Thanks for the response guys.

This might work.....

All data belong to the CompanyUserId, where multi user can login as the the company user id and manage items that belong to companyuserid.
-Once logged in, set session.EffectiveUserId to the logged in UserId.
-After this look up "UserAccess" by EffectiveUserId to see which company the current logged in user can manage.
-Once the user selects a Company, log into using CompanyUserId
 -Now in every webscreen and action verify the session.effectiveUserId has permission to perform the required task.



  • Id
  • CompanyUserId (the company master userId that the log in user wants to manage)
  • UserId (UserId logged In)


  • Id
  • UserAccessId
  • PermissionTypeId



  • Id
  • Name
Robert -

That is definitely an interesting approach that I had never considered! If it meets your needs, then I say go for it. I think the key here, is to realize that you'll need to make sure that on every screen, you carefully check data ownership, regardless of how you approach it at an entity level.