Evaluate what the SaaS edition adds
The Blazor CRM Multi-Tenant Source Code is the SaaS counterpart of the single-tenant Blazor CRM. It keeps the same .NET 10 single-project structure, Blazor Server and MudBlazor interface, Minimal API endpoints, MediatR handlers, and EF Core model, and it adds the tenant dimension needed for a multi-organization deployment. This evaluation describes the actual contents so you can compare the two editions before choosing one to customize.
Start with Multi-Tenant CRM Architecture for the mechanism, and the single-tenant source-code evaluation for the base application this edition extends.
Recognize the same CRM pipeline
The CRM modules under Features/Pipeline/ are present folder for folder: Campaign, Budget, Expense, Lead, LeadActivity, LeadContact, SalesRepresentative, SalesTeam, and the tabbed PipelinePage. Components, services, endpoints, and Cqrs handlers mirror the single-tenant edition. The visible difference is in the data layer: each CRM entity implements IMultiTenant and adds a TenantId property as its first business column.
Because tenant isolation lives in the shared DbContext, the handlers themselves contain no tenant logic. The same lead create, list, lookup, and delete handlers work for any tenant, and the query filter and save-time stamping keep each organization’s rows separate.
Manage tenants and memberships
A tenant administration area under Features/Multitenant/ provides CRUD screens for tenants and for the users assigned to them. The tenant form records the organization profile and active state, and a per-tenant member table assigns application users to the organization through TenantUser rows. The navigation exposes this area to administrators, while regular users reach the same concepts through registration and the organization selection page.
Tenant and membership endpoints follow the same route and envelope conventions as the CRM modules, such as /api/tenant and /api/tenant-user, and require an authenticated bearer token.
Run the organization selection flow
After login the app routes to the tenant selection screen instead of the home dashboard. The screen lists the organizations the current user belongs to, and confirming one re-issues the token with the tenant identifier as a claim and loads the tenant workspace. The shell provides a “Change Tenant” action to return to the same picker, and switching reloads the application for the new organization. This flow is the practical face of the architecture: one login, many organizations, one active tenant at a time.
Isolate data inside each tenant
All CRM reads run through EF global query filters that restrict every tenant entity to the current TenantId and exclude soft-deleted rows. Writes stamp the tenant on insert and throw on a missing tenant or on a cross-tenant modification. Document numbering is also isolated: the auto-number sequence is keyed per tenant, and unique indexes become composite (TenantId, AutoNumber) indexes, so tenants do not collide on document codes.
The same isolation applies to the supporting master data that the CRM relies on, such as company, currency, tax, and user records inside the tenant.
Configure per-tenant settings
A settings area scoped to the current tenant lets an organization manage its company information, its users, currencies, tax rules, and auto-number sequences. Creating a user inside a tenant automatically creates the matching TenantUser membership row, so the user becomes part of that organization’s data set. These screens are tenant-scoped through the same query filter rather than through separate databases, which keeps the multi-tenant model consistent across the whole application.
Know what is not included
The inspected SaaS edition has no subscription or billing code: there are no plans, quotas, payment gateways, usage metering, or automatic tenant suspension. Tenant provisioning is minimal: public signup creates a fixed default tenant for the new user, and an administrator can create more tenants and assign users. Roles are global application roles rather than per-tenant roles or permission matrices. If your SaaS roadmap requires plan-based limits or per-tenant authorization, those layers are extensions you add on top of the tenant data model, not features you will find in the source package.
Choose the edition for your customization
Choose the single-tenant CRM when you need one organization with the simplest possible data model, and choose the multi-tenant edition when your product must serve several organizations from one deployment with organization selection and data isolation. The database design of the base CRM carries over unchanged, so the schema and relationship articles apply to both. Review the tenant architecture in Multi-Tenant CRM Architecture, then compare the complete package on the Blazor CRM Multi-Tenant product page. See this architecture implemented in a complete Blazor CRM application.