Multi-tenant systems use layered governance across platform administrators, tenant administrators, and business roles to achieve data isolation, dynamic menu assignment, and unified access control. This approach solves common SaaS back-office problems such as blurred role boundaries, insufficient permission granularity, and poor reuse of foundational data. Keywords: multi-tenancy, permission management, dynamic menus.
Technical Specifications Snapshot
| Parameter | Description |
|---|---|
| Architecture Type | Multi-tenant SaaS admin backend |
| Primary Language | Not explicitly stated in the original article; based on the author’s ecosystem, likely C# / Vue |
| Core Protocols | HTTP, session-based authentication and authorization |
| Permission Model | Menu permissions + functional permissions + tenant isolation |
| Data Isolation Method | Tenant ID linked to business data and foundational data |
| Star Count | Not provided in the original article |
| Core Dependencies | Not provided in the original article; the UI indicates dynamic menus, dictionaries, logs, and attachment capabilities |
Role boundaries must be defined before interface design in a multi-tenant system
A multi-tenant system is not simply a monolithic admin app with an added tenant_id field. You must first define platform-level governance boundaries, then map them into tenant-level operational boundaries. The most important point in the original article is the three-layer role model: platform super administrator, tenant administrator, and tenant-defined business roles.
The platform super administrator does not participate in day-to-day business operations. Instead, this role maintains shared platform capabilities such as tenants, menus, function points, dictionaries, parameters, code generation rules, and announcements. In other words, the platform layer is responsible for defining rules, not operating business data.
Platform super administrator use cases determine the platform admin skeleton
AI Visual Insight: This diagram shows the high-level use-case distribution for the platform super administrator. The core focus is tenant creation, menu maintenance, functional permissions, dictionaries, parameters, and code rules at the platform metadata level. This indicates a governance model of platform-defined, tenant-consumed capabilities rather than isolated modeling by each tenant.
Tenant administrators maintain foundational data within the current tenant, such as users, departments, roles, positions, announcements, as well as tenant-side dictionaries and parameter values. This layer determines both the primary navigation structure of the tenant admin console and which datasets must be stored independently per tenant.
AI Visual Insight: This diagram shows that tenant administrator use cases are closer to the operations layer than the platform side. They include organization management, user management, role authorization, and tenant-level configuration maintenance. This reflects a deliberate separation between platform-controlled definitions and tenant-executed configuration, which is well suited to standard SaaS admin design.
Tenant-defined business roles participate directly in business workflows. They maintain business master data, business documents, and process data. Once you establish this layered model, the interface can naturally map to three distinct menu trees instead of relying on ad hoc button hiding logic.
AI Visual Insight: This diagram shows that ordinary tenant business roles primarily operate at the execution layer. They do not have platform governance capabilities and can only consume authorized menus and function points. This indicates that the permission model includes at least two layers: page visibility and operation executability.
The login entry point must explicitly distinguish platform identity from tenant identity
The first isolation boundary in a multi-tenant system is not the menu. It is the login entry point. The original article notes that when a user selects a tenant during login, the system validates the account as a tenant user; if no tenant is selected, the system validates the account as a platform administrator. At its core, this is an identity domain switch.
AI Visual Insight: This diagram shows that the login UI includes tenant selection or tenant code input. That means the authentication flow validates not only the username and password but also the tenant context so the system can load the correct role menu and data scope after authentication.
class LoginContext:
def __init__(self, username, password, tenant_code=None):
self.username = username
self.password = password
self.tenant_code = tenant_code # Empty tenant code indicates a platform-domain login
def resolve_login_domain(ctx: LoginContext):
if ctx.tenant_code:
return "tenant" # Enter the tenant identity validation flow
return "platform" # Enter the platform administrator validation flowThis code demonstrates that multi-tenant login must first resolve the identity domain, then decide the authentication source and menu-loading strategy.
Platform-level modules should define shared capabilities rather than perform business data entry
Tenant management is the most critical entry point on the platform side. Once a tenant is created, all subsequent users, roles, organizations, and business data are linked through the tenant ID. That makes tenant management the root node of system-wide data isolation.
AI Visual Insight: This diagram shows that the tenant management list page supports standard admin capabilities such as tenant information display, status management, and maintenance actions. This implies that the platform layer must fully maintain tenant metadata and use it as the ownership key for all business data.
System menu definitions and functional permission definitions both belong to platform-side metadata. Menus determine what users can see, while function points determine what users can do. You need both to build a complete RBAC model.
AI Visual Insight: This diagram shows that the menu maintenance screen should support hierarchical structures, system codes, routes, or page identifiers. That indicates the system menu is not hardcoded. Instead, the frontend navigation tree is loaded dynamically from platform configuration.
AI Visual Insight: This diagram shows that the functional permission management page abstracts buttons, operations, or function points into independent permission entities. That means the system controls not only page access but also fine-grained actions such as create, edit, delete, and approve.
AI Visual Insight: This diagram shows that functional permissions support batch generation. This is commonly used to create standard action points such as create, edit, delete, and export for a list page in a single step, reducing the manual cost of initializing the permission model.
def build_permission_bundle(menu_code: str):
actions = ["create", "edit", "delete", "detail", "export"]
return [f"{menu_code}:{action}" for action in actions] # Generate standard function points in batchThis code shows how the platform can batch-create standard operation permissions by using the menu code as the prefix.
Dictionaries and code rules should support both system-level reuse and tenant-level override
Dictionary management is one of the most underestimated modules in a multi-tenant admin system. The original article emphasizes that dictionary types are defined first by the platform, and then maintained either at the system level or the tenant level depending on their scope. This design standardizes enum semantics while preserving room for tenant-specific configuration.
AI Visual Insight: This diagram shows that the dictionary type management page is responsible for modeling top-level dictionary categories. It typically includes fields such as code, name, scope, and status, which become the source of permission boundaries for downstream dictionary items.
AI Visual Insight: This diagram highlights the scope field of a dictionary type. It shows that the system uses metadata directly to decide whether a dictionary can be maintained on the tenant side, which pushes data permission rules into the model layer.
AI Visual Insight: This diagram shows the relational maintenance model between dictionary item lists and dictionary categories. Dictionary items are not isolated forms. They are controlled datasets attached to a dictionary type.
AI Visual Insight: This diagram shows that tenants can maintain only tenant-level dictionary items. System-level dictionary items should be read-only or protected from modification and deletion in the tenant view. This reflects the design principle of platform-defined boundaries with limited tenant extensibility.
Business code rules follow the same strategy: platform presets first, then tenant-level copies that can be adjusted. This works especially well for document numbering and business sequence numbers because it balances standardization with tenant flexibility.
AI Visual Insight: This diagram shows the system-level code rule configuration page. It typically includes fields such as prefix, date segment, sequence length, and reset policy, which are used to centrally define standard numbering strategies.
AI Visual Insight: This diagram shows that a tenant can make local adjustments after inheriting the default platform rule. This initialization-copy-plus-tenant-customization approach avoids the coupling that occurs when every tenant shares the same numbering template.
Attachments and logs should be treated as cross-business shared infrastructure
Attachment management is not a peripheral module. It is cross-business infrastructure. A unified attachment table can centrally maintain file size, format, path, and ownership metadata. It also enables tenant administrators to govern storage resources and audit risks consistently.
AI Visual Insight: This diagram shows that the attachment management page centralizes file metadata, which indicates that the system uses a unified attachment center rather than scattering file information across business tables. This design improves auditing, cleanup, and permission control.
class AttachmentRecord:
def __init__(self, tenant_id, file_name, size, path):
self.tenant_id = tenant_id # Identify the tenant that owns the file
self.file_name = file_name
self.size = size
self.path = pathThis code shows that the key to an attachment center is not the upload operation itself. The key is a unified model for file metadata and tenant ownership.
Multi-tenant interface design is ultimately a visual representation of the permission model
This case study shows that an extensible multi-tenant admin console must first establish role layering, identity domain separation, and menu-plus-function-point modeling before it moves into page design. Otherwise, the richer the interface becomes, the more fragile the permission model gets.
For SaaS platforms, the most reliable path is this: the platform defines shared capabilities, each tenant maintains foundational data within its own domain, and business roles consume only authorized resources. This keeps governance consistent while still allowing tenant autonomy.
FAQ
1. Why can’t a multi-tenant system rely only on a role table for permission control?
Because multi-tenancy is not only about roles. It also includes identity domains, data domains, and resource ownership. A role table alone cannot enforce the boundary between platform users and tenant users, nor can it guarantee data isolation across tenants.
2. Why should menu permissions and functional permissions be designed separately?
Menu permissions control page visibility, while functional permissions control whether buttons or operations can be executed. By separating the two, the system can support fine-grained authorization scenarios such as view-only access without edit permissions.
3. Why should dictionaries and code rules support tenant overrides?
Because the platform needs standardized rules, but tenants often have unique operational requirements. A combination of system-level presets and tenant-level overrides balances consistency, extensibility, and implementation efficiency.
[AI Readability Summary]
This article reconstructs the interface design approach for multi-tenant system architecture. It focuses on the responsibility boundaries among the platform super administrator, tenant administrator, and tenant business roles, and breaks down key modules such as login authentication, tenant management, menu permissions, dictionaries, code rules, and attachment management. It serves as a practical reference for designing multi-tenant SaaS admin architectures.