A guide to organization modeling

If you want to sell to an enterprise, your backend needs to be ready to support complex user and team models. This requires a well-developed organizational model.

Unfortunately, creating an organizational model can become complicated when you add different types of relationships and SSO.

This post will walk you through the following:

• How to think about organizational modeling for your app
• Different approaches to implementing an organizational model
• Practical considerations for implementing SSO in a multi-organizational model

Let’s start with discussing the key concepts of organization modeling.

How organization modeling works conceptually

Organization modeling is like an onion in that it has layers, each representing a different aspect of how users and organizations interact within an application. 

The basic concepts are simple, but edge cases (especially SSO) can make things highly complex as you go deeper.

Let's start with the two basic concepts — users and organizations.

1. A user 

A user maps to someone with a login. Since a person can usually have multiple user accounts, they can have multiple logins or identities. But as far as your app is concerned, a user maps 1:1 with a login.

2. An organization

An organization is a group of one or more users who share access to the same resources or artifacts. If a user maps to someone with a login, you can think of an organization mapping to an IT admin.

An artifact can be anything; it depends on your app. At Digital Ocean, the artifact could be a cloud resource like a VM, managed database, firewall, etc. At Figma, an artifact might be a shared marketing folder or blog assets. 

Note that these artifacts can "belong" to a particular user in an organization and be inaccessible to other users (like a private file).

In some implementations, an organization will have a unique domain, e.g., a multi-tenant SaaS application where each organization gets a subdomain or a custom domain for the entire deployment.

Can a user be a part of multiple organizations? 

The relationship between a user and an organization can be modeled in two major ways:

1. Many-to-one

In a many-to-one relationship, an organization can have many users, but only one can be a member of one organization.

2. Many-to-many

You can also model this relationship as many-to-many, where a user can be part of multiple organizations. The main use case for this kind of relationship is contractors and agencies who have various clients and need access to all of their workspaces from a single user account.

You can think of a third, lower-level concept as a workspace.

3. Workspaces

A workspace is a sublevel of an organization that organizes the users and artifacts inside it.

‍

The easiest way to think about this is multiple teams for one customer. For example, it’s safe to assume that not all 200,000 Microsoft employees would use the same resources for their projects. Instead, distinct workspaces like Marketing, Sales, and Engineering might exist, each with further subdivisions for specific teams.

Slack is a good example of the confluence of all of these ideas. You can have multiple Slack accounts linked to different email addresses, each representing a user within various workspaces. Despite Slack using the term "workspace," it aligns more closely with what we’ve defined as an organization in this context — each workspace manages its members, permissions, and resources.

Workspaces, however, are a lower-level concept than a user or an org because they don't have any authentication implications (purely authorization). 

How you model data in your app will majorly impact how you build your auth schemes, especially once you get into the wacky, wild world of SSO and SAML.

Read more: Org roles & permissions.

How to implement organization modeling

With that conceptual backing in mind, let's focus more on how you'd actually implement this on the backend (and, to a lesser extent, the front end). 

To visualize your model, use a data modeling tool that shows how data moves throughout an organization.

Tables for users and organizations

This approach has a complexity level of 0. You model user data to organizations as many-to-one; each user can only be in one organization.

In that case, you just need two tables in your data model, one for users and one for organizations. Each row in the user's table has a foreign key, or organization_id, to a row in the organization's table.

This model is simple and easy, especially for your analytics team that only needs to do one join.

A membership table for many-to-many

If you do decide to model users to organizations as many-to-many, you'll need a third table to keep track of the "memberships" of different users to different organizations. It should be one row per user per membership, with foreign keys out to both the user and organization tables.

Note that even if a user can belong to multiple organizations, there will usually be a primary organization that "owns" the user account (e.g., whoever owns the domain).

Choosing your organization on login

If you support a user belonging to multiple organizations, you will need to build a way for them to choose which organization they want access to at a given time. The most straightforward way to do this is on login:

1. The user authenticates (in whichever way their owning organization requires)
2. The user chooses which organization they want to access

Building an organization "switching" functionality once a user is already authenticated sounds nice on paper but is challenging.

SSO challenges in multi-organization environments

Organizational modeling use cases follow somewhat of a bimodal distribution between single and multi-organization users. Most users will only belong to one organization. Once they authenticate, you don't need to worry about them anymore. 

However, a small group of users demanding access to more than one organization (this is a reasonable request) will cause you the most trouble.

The multi-organization SSO challenge

Consider the following example:

• Nikita is an employee of Deloitte. Her job is to consult and contract with other organizations.
• Her user account uses her Deloitte email, nikita@deloitte.com. The Deloitte organization owns the deloitte.com domain, which also owns her user account.
• The IT admin for Deloitte requires all users to log in via SSO through their IdP, which is Amazon Cognito.
• Nikita is working on a project for Initech, so she has access to Initech's organization, which is still under her Deloitte email.
• The IT admin for Initech requires all users to log in via SSO through their IdP, which is Okta.

Because the Deloitte organization owns the deloitte.com domain, and thus Nikita's user account, she must log in via their SSO. But if she then wants to access artifacts from Initech, she will need to do more authentication and log in via their SSO. 

Situations like this, which are not entirely uncommon, pose a high degree of complexity in organizational mapping and make it challenging to implement functionality that allows seamless "switching" between organizations.

Handling the "switching" challenge 

In Nikita's situation, the most straightforward way to handle things would be:

• Require her to authenticate for "general purpose" per the Deloitte IT admin's requirements (e.g., their SSO connection). If she wants to work on artifacts within the Deloitte organization, she's all set.
• If she wants to work on artifacts within the Initech organization, she'll need to perform more authentication.

Implementing these authentication steps at the login stage rather than post-login centralizes the logic and keeps the user experience consistent.

Leveraging existing solutions 

Now is as good of a time as any to mention that if you don't want to build all of this yourself, you can always use something open-source like AuthKit from WorkOS.

One of AuthKit's key features is its ability to route users to the appropriate IdP based on their email domain. This is particularly useful in scenarios where users, like the hypothetical Nikita, have to authenticate through different identity providers depending on the organization they are accessing. 

Getting started is easy, thanks to AuthKit’s hosted, customizable sign-in interface that abstracts away the complexities of building multiple SSO flows.

‍Start building with AuthKit today, and start signing enterprise customers tomorrow.