The Multi-tenant Account Management Platform is an identity middle layer for SaaS providers. It collects tenants, users, organisation structure, roles and permissions, dictionaries, files and messages, plus single sign-on for every business system, into one platform — one back office hosting many customers’ accounts and permissions, invisible to one another.
Project background
Once a SaaS provider grows, the account layer is usually the first to give way: every business system keeps its own user table, so the same customer is “Mr Zhang” in system A and “zhang” in system B, and when he leaves only one of them is disabled. Permissions are configured wherever they happen to live and who may see which data depends on memory. When a new customer signs, operations has to hand-build the tenant, departments, roles and accounts — onboarding often takes a week.
The client wanted accounts and permissions pulled out of the business systems into a middle layer of their own: one tenant, one isolated space with its own organisation, roles, menus and data scope; and onboarding turned from “a week of manual configuration” into “pick a plan and it is provisioned”.
Design goals
- Tenant isolation — each tenant’s data is stored and displayed separately; the plan decides which modules are available, how many users and how much storage.
- Unified authentication — business systems join through SSO; users sign in once and reach every system, and no system keeps its own account table.
- Permissions to the last point — menu permissions are ticked down to button level; data permission is controlled in four bands: all / own department / self / specified departments.
- Self-service provisioning — enterprises register and submit their details themselves; once an administrator approves, the tenant is created automatically, with no dependency on an operations schedule.
System architecture
The platform is organised into eight areas — tenant management, user management, organisation, permission management, dictionary management, business systems, file management and message centre — joining the chain “create tenant → configure organisation → assign roles → connect systems → send messages” end to end.
Core modules
Below, module by module. Each corresponds to a specific nuisance when an account layer is put into practice.
Tenants and plans
The tenant list holds every customer space with contact, plan, activation and expiry dates and status; a plan defines the user cap, storage, price and available features, applied directly when a tenant is created.
Enterprise registration review
Self-registered companies land in a pending list; an administrator checks the unified social credit code and approves or rejects. Approval generates the tenant automatically, saving manual record-keeping.
Users and bulk import
Users can be created one by one or imported from Excel: download the template, fill it in and upload, and the system parses it and reports how many succeeded and failed. Migrating an existing customer can load thousands of accounts at once.
Organisation and positions
The department tree expands over several levels with add, edit, delete and reorder; positions are maintained separately as an identity beyond roles, and a user belongs to both a department and a position.
Roles and menu permissions
A role is a set of permissions, ticked in a tree down to button level; one person can hold several roles and permissions are unioned, so a new feature means editing the role, not the people.
Data permissions
Visible scope is controlled in four bands — all data, own department, own records, specified departments — so different roles see different rows in the same list.
Business systems and SSO
Register the connected system’s name, code, icon, callback address and login redirect; SSO takes effect as soon as the parameters are set, and a user jumps to any business system from a single login.
Messages and files
SMS channels, templates and send logs are traceable across the chain, and in-app messages are template-driven; files are stored isolated per tenant, with configurable size limits and accepted formats.
Interface examples
The screenshots below are from the live platform; test data has been anonymised.
Outcome
- Tenant onboarding went from item-by-item manual configuration to “approved means provisioned”; the plan sets the boundary and onboarding no longer waits on an operations schedule.
- Accounts, organisation, roles, menus and data permissions are maintained in one place; one change takes effect everywhere instead of being aligned system by system.
- Business systems join through SSO; users sign in once for many systems and no system maintains its own account table.
- Permission control reaches buttons and data rows, so over-reach moves from “a matter of discipline” to “the system will not allow it”.
Need a similar management system?
We have delivered in retail, property, education, healthcare and finance. Tell us your own scenario and we will start from there.