About Multi-Tenancy

The OutSystems Platform allows designing Multi-tenant applications with data isolation among their clients, both for enterprise applications and Software as a Service (SaaS) scenarios.

While a Single-tenant application requires dedicated resources to serve a single client organization, Multi-tenant applications are able to serve multiple client organizations (also known as Tenants ), using the resources of a single software instance, while enforcing data isolation among client organizations.

End-users access a Multi-tenant application through the same URL and the OutSystems Platform automatically infers their tenants. These tenants share screens and business logic of the application, but data, sessions, processes, and end-users are isolated from each other.

The example above depicts how tenants are virtually isolated from one another. When a end-user logs in, the OutSystems Platform binds the end-user to the correct tenant. From then on, the end-user will only be able to read and manipulate data of that tenant.

Why using Multi-Tenancy?

Designing applications using a Multi-tenant architecture has several benefits:

• Decrease infrastructure operation costs, since there is only one application deployed on the server;
• Enforce a strict security policy for data, users, sessions, and processes;
• Simplify the application development and maintenance processes, since there is a single code base to maintain.

Implementing Multi-Tenancy

Designing a Multi-tenant application simply requires configuring which eSpaces of the application have data isolation and, within each eSpace, which tenant-specific elements have data isolation.

Learn more about Implementing Multi-Tenancy .

Tenant-Specific Elements

Setting an Entity , Site Property , or Timer as Multi-tenant constrains their data per tenant. This is provided by OutSystems Platform in a transparent way to the developer.

Therefore, Aggregates and SQL are performed with automatic data isolation: only data belonging to the correct tenant is returned. If you want to select the tenant to use when testing your queries with Aggregates or SQL in the development environment, go to the 'Module' menu, and click 'Configure Tenant to Test Queries' .

Also, every Process instance is tenant specific: only handles data visible for the tenant that started it.

Learn more about Tenant-Specific Elements .

About the Session

When an end-user logs in to the application a Session is created and shared among all eSpaces, storing both the end-user and tenant identifiers. With this information stored in session, the tenant is always constrained to the data owned by its tenant.

When Anonymous end-users access a Multi-tenant application they are bound to a Default Tenant (with the same name of the User Provider application).

End-User Management

Setting the Users application as User Provider ensures that end-users of your application are constrained per tenant.

As the OutSystems Platform uses the username to infer the tenant, the creation of end-users requires some attention to avoid name clashing. It is advisable to use unique usernames, as for example: <username>@<company>.

Learn more about End-User Management .

Using Cache

When using cache to improve the application performance, the cached content of Aggregates , Web Screens , and Actions is placed inside tenant-specific caches. The cache invalidation is optionally performed by Tenant or module.

Learn more about Using Cache in Multi-Tenant Applications .

See Also

Implementing Multi-Tenancy | Tenant-Specific Elements | End-User Management | Using Cache in Multi-Tenant Applications