A SaaS workspace data model should separate a person's identity from the organizations they belong to. A user answers who someone is. A workspace identifies a customer-owned area of the product. A membership connects the two and records what the person can do there.
This distinction becomes valuable as soon as an agency manages several clients, an employee joins a second team or a founder leaves the company. If these concepts are combined into one user record, everyday business changes become awkward database exceptions.
Begin with the business relationships
Imagine a hypothetical translation agency using a project coordination SaaS. The agency has its own internal workspace, and a freelancer also participates in a client's workspace. The same person needs two memberships with different permissions.
A simple starting model contains these relationships:
| Entity | Represents | Important relationship |
|---|---|---|
| User | A person with an application identity | Has a separate membership for each workspace they join |
| Workspace | A customer or team boundary | Owns projects, files, and other tenant-scoped resources |
| Membership | A user’s participation in one workspace | Links a user to a workspace and records role and membership status |
| Role or permission grant | Allowed actions within a defined scope | Belongs to a membership or an explicit resource relationship |
| Resource | A business record such as a translation project | References its owning workspace; access follows that workspace’s policy |