Menu
Multi tenant applications use a single instance of data and software, but segregate it into compartments so each tenant only sees their own data. Using the Ruly platform, customers can build applications to model virtually any multi tenant architecture and support hundreds or thousands of their own clients. All without using code.
Note that Ruly is a multi tenant application, although it uses separate databases for each of its customers. Read more about different multi tenant architectures here.
To create separate tenants in Ruly, Security is used to control access to data. There are three methods that can be used to create separate virtual tenants within a single instance. Each of them has its own use cases and benefits.
For example, by creating a Company attribute and adding that to all data tables, we can ensure that only users that belong to Company A see Company A records.
In the User table add a Company attribute as well. This will designate each user as belonging to a particular company.
To restrict users to their company records, create a row security entry for each data table. In the example below, the Opportunities table has company security applied. Note the use of the CurrentUser variable which dynamically uses the company that the currently logged-in user is assigned to.
An even simpler method exists to restrict all data tables with a single row security entry.
The Cascade to Linked Tables option automatically applies security to all tables that are linked back to the User table.
This very simple rule is an example of the power and flexibility of row security.
Most companies are organized into hierarchical reporting structures. Ruly makes it easy to create these structures by simply designating a data table as a Tree table.
Below is a simple organizational structure for a company that has been divided into divisions and departments.
On the employee table, add an Org field that points to the same table above. Then assign each employee to an organization. We will use this same Org field on other data tables as well to identify what organization the records belongs to.
You can see below that Ed Fisher belongs to the IT department which is part of the Technology division.
Now Ed should see all data records in the Technology division. That includes all of the departments in Technology: IT, Quality, and Engineering.
We can do this by creating an IT security role with a Row Security filter, and using the Equal or Below operator. This will filter records to the IT node and any department records that are below it in the tree.
In a Network Security model, users that have a connection to other users are able to see information shared by these other users.
So we will start with a simple User Network table that links any two users together. The table has two fields User 1 and User 2. We will model the case where User 1 shares with User 2 and vice versa. The one-directional sharing case can be easily done as well.
We will apply row security to a single data table in this example. In this case an Opportunities table. The query would be written so that a user could see records that are:
This would be configured in Ruly like this:
Note the Join To operator that links two tables together, and the Is Me operator that designates the currently logged-in user.
I hope this article shows how powerful row security is and its versatility in creating multi tenant architecture applications. Many other security use cases can be easily solved using and adapting these same techniques.
If you have any questions feel free to contact me at stan.marsden@rulyapp.com.