How to design multi-organization application?

Question

my team and I are developing a saas-like platform, mainly focused on organizations where a user can log in, choose an organization which he wants to manage (user can be assigned to multiple "organizations"), and then do whatever he likes (adding/inviting users, adding resources, etc.). But after some research, I realized that something like "multi-tenant" applications exists and now I wonder if we are doing it correctly.

Now we treat the whole application as one tenant (well, actually no tenants) and recognize the organization by ID in URL (not every resource has the "organizationId" field and half of the resources are not prefixed by /organization/:id in the path). Then in the backend, we are checking if the user has access to the organization (and optionally role in the organization).

The question is, should we rewrite the structure and assume that tenant = organization? It would simplify authentication part and we would move the role checking part to controller level because we will store TenantID in jwt with global query filter on every resource existing.

Answer 1

I would suggest that you add more context in the post based on the domain for which you have built the application.

Aspect-1 If you have built this application for your internal use like Google having organizations like Google USA, Google Europe. These organizations can have child orgs like Google - CA, Google - WA under Google USA and the like. In this case, the current implementation would suffice.

Aspect-2 However, in-case of planning to build a multi-tenant platform to onboard tenants like Meta, Microsoft which can leverage your application, to use for their own orgs like Microsoft-USA, Microsoft-Asia etc, then the option of rewriting your application to include multi-tenancy makes more sense. This comes with a cost of building more generic organizations, hierarchy, roles and these all to be fitted within the hood of a tenant.