Application Data Models of B2B Apps

Part 2 of the series titled "Deconstructing Data Models"

👋 Hey there

🤝 If you’re new: Thank you for subscribing to the databeats newsletter where I publish guides for growth practitioners to use data to drive growth (data-powered growth).

🙌 If you’re not new, well, thank you for sticking around!

---

As I’d mentioned in Part 1 of this series, this one’s ambitious and is therefore taking longer than I anticipated to produce.

Part 3 will land in the next 2-3 weeks.

Anyhow, if you work in B2B SaaS, this one’s for you! 🫵

Permanent link to this post to bookmark and read later →

Let’s consider the User and Workspace entities to understand application data models of B2B apps.

A user is any person who has signed up for an app (created an account), verified their email, and can start using the app – this is true for both B2C and B2B apps. 

But unlike B2C apps that you’d typically use by yourself (in single-player mode), B2B apps enable you to collaborate with other users by inviting them to your account or workspace. In fact, when you sign up for a B2B app that is collaborative in nature (such as Notion or Slack), besides your user account, a workspace is also created automatically.

The user account and the workspace are distinct entities with distinct IDs, with a parent-child relationship between the workspace and the user. When an account is upgraded from free to paid, it is the workspace (parent) that’s upgraded. Even with multiple users in the workspace, the customer count goes up by exactly one. A user is not a customer unless we’re talking about single-player apps where the concept of a workspace is redundant (or optional). 

One-to-Many

When designing the database schema for a B2B app, software engineers need to declare a parent-child relationship between the Workspace model and the User model where one workspace can have multiple users – a one-to-many workspace-user relationship.

One-to-many workspace-user relationship

The figure above depicts this relationship where users X and Y belong to the workspace A. As a result, each user’s identity is strictly tied to the workspace, as depicted by their respective user_id, AX and AY. 

It’s useful to keep in mind that a one-to-many workspace-user relationship is the same as a many-to-one user-workspace relationship. While a workspace can have multiple users, each user in the workspace can only belong to that specific workspace. 

If either X or Y is invited to join another workspace in the same app, they will have to create another user account that will have a different user_id. This application data model is typical of enterprise apps like Slack. 

The figure below shows that the user Y has a separate user_id (AY and BY) for each of the two workspaces, A and B. 

One-to-many workspace-user relationship where the same person has two separate accounts

User and Workspace Models of Enterprise (only) Apps  

Ever joined a Slack workspace using an email that you’ve used before, only to be treated as a new user? Slack asks you to enter your name and verify your email each time you join a new Slack workspace. You’re also able to use different names and different profile photos across multiple Slack workspaces that you’ve joined using the same email address.

Ever wondered why?  

You see, the early engineers at Slack didn’t anticipate that it would be used to run communities, where a user joins multiple workspaces using the same email address; Slack was built to be used inside companies where one email address is only used to join one workspace. Therefore, Slack treats you as a distinct user in each workspace you join (or create) using the same email (even though Slack is able to identify you as one person).

This also explains why you can set up a unique password for each workspace you join using the same email or use existing credentials (email and password combination) to join a new workspace without being prompted that an account already exists using this email address.

Unlike those of prosumer apps we'll discuss below, the application data models of enterprise-only apps like Slack don’t need to account for a single-player experience.

The relationship between the Workspace and User models of a B2B app with a one-to-many workspace-user relationship

The figure above is part of a conceptual schema for an enterprise app depicting the Workspace and User models with a one-to-many workspace-user relationship. As you can see, the workspace_id is the foreign key of the User model since a user can only belong to one workspace. 

Many-to-Many

B2B apps like that allow a user to join or create multiple workspaces (without creating a new account using a different email), the workspace-user relationship is many-to-many.