Multitenancy best practices

This guide will walk you through best practices for implementing multitenancy, as well as some considerations around the unique IDs in

As a monday apps developer, this article will help you understand how implements multitenancy and its impact on your app’s design.

Who should read this article?

You should read this guide if:

  • Your app stores any user data
  • Your app needs to validate stored user data with actual user data in
  • Your app stores API keys in order to make actions on behalf of users

Why are these best practices important?

As a developer for the monday apps marketplace, it’s important to understand, implement, and uphold the security practices that safeguard user data.

While storing user data in your database can be useful for decreasing query time (and consequently load time for users), you must follow best practices so as not to expose this user data, consequently violating data security.

For example, if you store user data using non-unique keys (such as board IDs), your app may expose data to the wrong audience. Make sure to always store data using keys that are unique across all of accounts, such as account and user IDs.

Introduction to Multitenancy

What is multitenancy?

Multitenancy, also known as shared hosting, is a type of software architecture in which a single platform (in this case serves multiple, independent instances or tenants.

Multitenancy is important because it breaks up’s users into distinct groups. These distinct groups may then be required to align with different data protection standards.

If you’re storing data from multiple accounts in a single database, your app is using multitenancy.

When to use a database?

Using a database for your apps can reduce not only load time, but also give a more seamless experience for your users.

Some instances in which you would want to utilize a database include: storing your users’ authorization tokens, storing settings for a particular account’s instance of your app, as well as storing your users’ account data.

Essentially, databases allow you to save and sort through data with rapidity and ease. Whether it be a board view, item view, or an integration recipe, databases can help you find, access, and present data quickly and efficiently.

What does multitenancy mean for you?

As a developer for the monday apps framework, it’s important to keep in mind how you’re storing data, and the uniqueness of keys and IDs.

This is even more important should you want to save multiple users’ and accounts’ information in the same database. Otherwise, you run the risk of violating data security should you choose to use a key that is not unique (i.e. any IDs other than account and user IDs).

For instance, if the only keys you store are item IDs, there is a chance that multiple boards within the account will have the same item IDs. This means you could be sharing item data across boards, and risking data security!



Only user IDs and account IDs are unique across the entire platform! As such, any primary keys used should only include user IDs and account IDs.

Other than user IDs and account IDs, other IDs are unique only in certain contexts.

Best Practices

As you begin to implement multitenancy in your own apps, here are a few suggestions to help you implement data security and user privacy.

Rule #1: Use account ID and user ID for identifying all account and user level information.

Make sure any keys you save are related to both an account ID as well as a user ID. For example, if you’re saving an automation ID or board ID in your database, make sure it is associated with an account and/or user ID as well.

This way, in case there are multiple automations or boards in your database with the same ID, you can utilize the relevant account and user IDs to distinguish between them.

Rule #2: Consider the uniqueness of the IDs and keys your application uses

When deciding which keys to store in your database, make sure you understand what scopes in which they are unique. For example, a column ID is unique on the board-level, but can appear on another board in the same account as well.

Are you using board IDs as your main keys? If so, you run the risk of there being multiple boards with the same board ID across different accounts. If this is the case, you could be sharing board data between accounts.

Make sure you always store account IDs and user IDs as your primary keys!

Rule #3: Don’t assume Board IDs and Item IDs will be unique

Every item on a board has an ID that is unique to the account. However, these IDs are not necessarily unique across other accounts (ie, two different accounts could have boards with the same IDs).

Even if you’re looking up some data based on an item ID, you should always check the user ID and account ID associated with that record to ensure you’re accessing the correct information.

Rule #4: Add multitenancy protection when accessing your database

Any and all access to your database should also, by default, have multitenancy protection. This way, your app ensures access to the right user data in the right context. In most languages, there are packages that can implement this database protection for you.

For example, the Sequelize ORM for Node.js is great for this. You can learn more about implementing Sequelize scopes here.

If you’re looking for more information on implementing multitenancy in your apps, here are some resources that can help:

Table of IDs and Uniqueness

The following is a table of IDs you can find in an account, and their corresponding contexts of uniqueness. Please note that the keys are not exhaustive and are subject to change.

IDDescriptionWhere is this unique?
Account IDThe ID of an account.Unique across all accounts.
Action UUIDThe UUID of a block's execution.Unique to each action in each automation.
App IDThe ID of a specific app.Unique across the account. App IDs can be repeated in different accounts.
Automation IDThe ID of an automation.Unique across the account. Automation IDs can be repeated in different accounts.
Board IDThe ID of a board in an account.Unique across the account. Board IDs can be repeated in different accounts.
Board view IDThe ID of the board view.Unique across the account. Board view IDs can be repeated in different accounts.
Column IDThe ID of a column on a board.Unique to a board. Column IDs can be repeated on multiple boards within the same account.
Group IDThe ID of a group on a board.Unique to a board. Group IDs can be repeated on multiple boards within the same account.
Integration IDThe ID of an integration.Unique across the account. Integration IDs can be repeated in different accounts.
Item IDThe ID of an item on a board.Unique across the account. Item IDs can be repeated in different accounts.
Trigger UUIDThe UUID of an automation's execution.Unique to each automation run. If one action is used multiple times in a recipe, they will all have the same trigger UUID.
User IDThe ID of a specific user.Unique across all accounts. If someone has multiple accounts, their user ID will be different for each.


Join our developer community!

We've created a community specifically for our devs where you can search through previous topics to find solutions, ask new questions, hear about new features and updates, and learn tips and tricks from other devs. Come join in on the fun! 😎