An HR director at a 500-person UK organisation is reviewing a cloud HR platform built on Dynamics 365. The supplier says it uses shared infrastructure. Her immediate question isn't whether the platform looks polished. It's where employee data sits, how the system separates it from other customers, and what evidence will be available if an auditor asks for proof.
That concern is justified. HR systems hold right-to-work documentation, payroll records, absence information and performance reviews. A sensible multi tenant architecture can reduce duplicated infrastructure and support scalable services, but it also creates a responsibility that many buyers underestimate: proving that each organisation's data remains isolated across applications, integrations, exports, background processes and backups.
Why Multi Tenant Architecture Matters for UK HR Platforms
Multi tenant architecture is a business decision, not just an infrastructure preference. Shared services can offer elasticity and operational efficiency, while dedicated environments may provide a simpler explanation of the boundary around one organisation's data. The right answer depends on the sensitivity of the workload, the organisation's governance requirements and the evidence the supplier can provide.
The UK has long experience of shared-building models. Between 1934 and 1939, at least 56,000 privately built flats appeared across more than 300 blocks in London, according to Historic England's archive material. Earlier, the late Victorian flat market produced over 40,000 London units, at a rate of 5,000 to 10,000 per year, helping establish the flat as an accepted form of multi-occupancy housing. The analogy is useful, but imperfect. A well-designed apartment block gives each household a defined boundary, shared services and controlled access. A poorly managed one creates uncertainty about who can enter which space.
The same principle applies to a shared HR platform. The organisation needs clear answers about tenant identity, access permissions, encryption, retention, deletion and incident response. It also needs to know whether data remains within its own Microsoft 365 tenant, or whether the supplier operates a separate service boundary.
Practical rule: Don't accept “shared platform” as a complete architectural description. Ask which resources are shared, which are dedicated, and where the tenant boundary is enforced.
For buyers comparing SaaS delivery options, the guide to SaaS development models for founders provides useful background on how delivery models affect ownership, scalability and operational responsibility. For a Microsoft-focused HR discussion, see cloud HR software for UK organisations. The commercial attraction of shared tenancy is real, but HR leaders should judge it against the quality of isolation evidence, not against licensing price alone.
Understanding Tenancy Models in Microsoft Dataverse
Start with three simple models. A single-tenant model resembles a detached house. One organisation has its own environment, resources and configuration boundary. A multi-tenant model is closer to an apartment block, where residents share the building's foundations and services but must have controlled access to their own flats. A hybrid model combines the two, using shared services for standard workloads and more isolated resources for sensitive processing.
Single tenant in Dataverse
In a Microsoft environment, the boundary usually starts with the Dataverse environment. An organisation may use an environment for its Dynamics 365 applications, Power Apps, workflows and data. Security groups and Microsoft Entra ID control which users and service principals can enter that environment, while Dataverse security roles govern what they can do once inside.
This model is easier to explain to a risk committee. The organisation can map its application, data and administrative controls to a defined environment. The trade-off is that separate environments create more work for deployment, monitoring, updates, backup planning and integration management. A separate environment can also reduce the opportunity to share operational capacity efficiently.
Multi tenant through shared services
In a multi tenant design, the application serves several organisations while keeping their data and configuration logically separated. The tenant boundary may be represented by separate Dataverse environments, tenant-scoped records within Dataverse, or a combination of Dataverse and Azure services. Entra ID remains central to identity, but the application must also understand which organisation a request belongs to.
That distinction matters for Dynamics 365 applications. A product such as Hubdrive's HR Management for Microsoft Dynamics 365 can run on the Microsoft platform, but the application still needs correct tenant context, role design, integration controls and data lifecycle policies. Shared code doesn't remove the requirement for separate governance.
Hybrid deployment
Hybrid tenancy is often the practical compromise. Standard employee records may use shared platform capacity, while highly sensitive interfaces, processing jobs or storage components receive stronger separation. The UK Government's cloud strategy describes multi-tenanted services as shared resources that are dynamically scalable, agile and easy to move in and out of service, which captures the operational appeal of the model in its cloud strategy.
Before migration, map each data flow and dependency. A sound data migration strategy for Dynamics 365 should identify environment boundaries, ownership, retention rules and integration destinations, rather than treating the HR database as the only relevant location.
Comparing Single Tenant and Multi Tenant Approaches
The choice becomes clearer when assessed against the actual operating model. Single tenancy offers a naturally strong boundary, but the customer carries more of the environment's fixed cost and administration. Multi tenancy shares infrastructure and centralises updates, but the supplier must implement isolation controls correctly and produce evidence that they continue to work.
UK buyers should also insist on GBP pricing. Public-sector UK pricing documents show cloud and platform services commonly presented in pounds sterling, including examples such as £3.78 tiers and £25 per month network infrastructure items in UK commercial documentation. Those examples aren't a quotation for an HR implementation, but they demonstrate why UK procurement teams should request a complete cost model in pounds, including environments, storage, integrations, support and any dedicated components.
| Criteria | Single Tenant | Multi Tenant |
|---|---|---|
| Cost structure | Dedicated resources usually create a higher baseline cost | Shared resources can reduce duplicated capacity and support pay-by-use economics |
| Scalability | Scaling is managed for one organisation and may require environment changes | Shared capacity can absorb changing demand, subject to quotas and noisy-neighbour controls |
| Security boundary | The environment boundary is straightforward to describe | Isolation must be enforced and tested across identity, application, data and infrastructure layers |
| Maintenance | Updates, monitoring and recovery are managed per environment | Centralised operations simplify common updates but increase the importance of tenant-aware release controls |
| Customisation | Deep organisation-specific changes are easier to contain | Configuration can be tenant-scoped, while changes affecting shared code require stronger release governance |
A common mistake is to equate multi tenancy with weak security. That isn't accurate. The relevant question is whether the supplier uses layered controls, including per-tenant encryption, logical network segregation, access governance and tenant-attributed logging. UK sovereign deployment guidance describes a multi-tenant service where infrastructure is shared only between government customers, storage encryption is applied per customer and logical network segregation uses NSX, with options ranging from shared everything to a dedicated platform in its service description.
The more useful conclusion is that multi tenant architecture shifts complexity from hardware ownership to control design and operational proof. A buyer should compare the evidence pack, not just the diagram.
Tenant Isolation Patterns and Design Trade-Offs
Secure isolation starts at onboarding. Give every tenant a stable, unique identifier and make it the authoritative reference throughout the platform. Don't rely on organisation names, labels entered by users or display values that can change. A stable identifier lets routing, authorisation, logging and deletion processes refer to the same tenant consistently, as described in this guidance on multi-tenant database isolation.
The controls that must work together
A tenant identifier alone isn't an isolation strategy. The application must bind tenant context to the authenticated request, and Dataverse queries must enforce the correct scope. Security roles, teams and business units need testing against real access paths, including delegated administration and integration identities.
Caching creates a frequent blind spot. A cache key that omits the tenant identifier can return one organisation's result to another, even if the underlying Dataverse permissions are correct. Isolation testing should therefore cover row-level security policies, cache behaviour, background jobs, reporting queries and service-to-service calls. The practical guidance on multi-tenant SaaS isolation patterns makes the important point that application and data-layer enforcement must work together.
Storage choices
Blob storage introduces a separate decision. Azure guidance allows architects to isolate tenants with separate blob containers or separate storage accounts, giving a choice between lighter logical separation and stronger physical separation in the Azure-related UK pricing document.
Use logical separation where scale, operational simplicity and uniform controls matter most, provided access policies and tests are effective. Consider separate storage accounts when a workload has heightened sensitivity, requires a distinct access boundary or needs clearer evidence for a compliance review. Physical separation doesn't remove the need for correct application logic. It reduces the potential blast radius of a storage-level error.
Dataverse and Entra ID realities
Dataverse security is powerful, but it isn't a substitute for architecture. Entra ID authenticates users and services, while Dataverse determines record-level permissions through roles, teams and ownership structures. The integration layer must carry tenant context consistently, and administrators must review privileged access separately from ordinary HR access.
A good identity management approach should document who can access each environment, which service principals can run jobs and how access is removed when an employee or supplier changes role. Test failure paths deliberately. A platform that works only when every component behaves perfectly isn't ready for regulated HR data.
Proving Isolation for Audits and Data Protection
Architecture diagrams show intention. Auditors, data protection teams and incident responders need evidence of operation. That evidence should demonstrate not only that tenant boundaries were designed, but that they held during exports, integrations, scheduled jobs, restores, support activity and deletion requests.
The operational burden is often underestimated because the primary Dataverse tables are visible and well governed. Secondary paths are less obvious. A payroll export may be written to a file store, a background flow may create an attachment, a reporting process may copy records into another analytical service, and a backup may follow a separate retention process.
Build an evidence trail
A buyer should ask for a control map that connects each data path to an owner, a technical boundary and a test. The evidence pack should include:
- Tenant-attributed logging: Show how user, service and administrative actions are linked to the correct tenant.
- Deletion verification: Demonstrate how tenant-specific deletion requests are executed and checked across primary records, attachments, exports and backups.
- Incident handling: Explain how the supplier identifies affected tenants, limits access and preserves investigation records.
- Access reviews: Record privileged access, support access and service-principal permissions, with a defined review process.
- Restore testing: Prove that a recovery operation can't merge data between tenants or restore records into the wrong environment.
The difficult question isn't “Can you isolate tenants?” It's “Show us the evidence that isolation still works after deployment and change.”
UK buyers increasingly examine sovereignty and privacy alongside functionality. Hybrid and multicloud arrangements can add control planes and audit surfaces, so the organisation needs a single view of where data moves and who controls each stage. A supplier should be able to explain retention, subprocessors, support access and breach handling in operational terms, not only through contractual wording.
The same discipline applies to a Data Protection Agreement. Match each promise to a technical control and an artefact that can be reviewed. If the supplier can't identify the log, test result, policy or operating procedure supporting a claim, treat that claim as unverified.
UK Compliance Requirements for Shared HR Platforms
UK compliance requirements should shape the tenancy decision before procurement, not after implementation. HR data often combines identity documents, employment history, absence details, payroll information and manager assessments. Each category may have different access, retention and deletion requirements, even when it resides in the same HR application.
A GDPR-aligned design needs more than encryption at rest. It should define why data is collected, who can access it, how long it is retained and how the organisation handles correction or deletion requests. The system should support retention schedules that reflect HR policy, while integrations and exported files receive equivalent treatment.
Right-to-work verification deserves its own control discussion. A UK Right to Work module should record the verification outcome, supporting evidence, responsible users and relevant dates, with access limited to people who need it. Buyers should ask whether the module is integrated into the employee lifecycle or operated as a disconnected process, because disconnected evidence is harder to govern.
Map risk to isolation
Public-sector deployment guidance demonstrates that shared tenancy doesn't require one security tier for every workload. The described options include shared infrastructure with per-customer storage encryption and logical network segregation, alongside dedicated compute, dedicated compute and storage, or a dedicated platform in the UK sovereign service model.
That supports a practical tiering approach:
- Standard processing: Shared infrastructure with tenant-scoped access, encryption and logging.
- Sensitive processing: Dedicated compute for workloads requiring a narrower processing boundary.
- High-governance data: Dedicated compute and storage, or a dedicated platform, where the compliance case justifies additional operational cost.
Data residency must be stated precisely. Ask where Dataverse data, attachments, integration copies, backups and diagnostics reside. If data remains in the customer's own Microsoft 365 tenant, confirm which environments and services hold it, how Microsoft Entra ID governs access and how the implementation team handles support access. Compliance improves when the architecture, contract and operating evidence all describe the same boundary.
Evaluating DynamicsHub and Hubdrive for Your Organisation
A sound evaluation starts with the platform boundary. Before comparing CV parsing, payroll integration or workflow features, establish how the solution runs, where employee data is stored and how administrators prove that access remains correctly scoped across tenants.
DynamicsHub implements and supports Hubdrive's HR Management for Microsoft Dynamics 365, a hire-to-retire application built natively on Dataverse. Its stated model keeps business data within the customer's own Microsoft 365 tenant, using Microsoft Dataverse, Dynamics 365 or Power Platform environments. That gives HR and IT teams a specific architecture to verify, rather than a general assurance about cloud security.
Questions for the technical workshop
Ask the implementation team to demonstrate each control and provide evidence suitable for audit review.
- Identity: How do Microsoft Entra ID groups, roles and privileged accounts control access?
- Data location: Which customer-owned environments contain employee records, documents and reporting data?
- Isolation: How are Dataverse records, attachments, flows, integrations and exports kept within the correct tenant boundary?
- Retention: How are GDPR-aligned retention policies configured, reviewed and evidenced?
- Right to Work: How are checks, documents, dates and permissions recorded?
- AI features: How are AI CV parsing, scoring, facial-recognition clocking and AI-assisted expenses governed, and which data stores do they use?
- Delivery: Which changes are configuration, which require custom development, and how are releases tested?
- Support: How is UK-based support access authorised, logged and removed?
The solution should connect with Microsoft 365 services such as Teams, Outlook, SharePoint, Power BI and Power Apps without creating uncontrolled copies of HR information. Require a documented data-flow map covering integrations, exports and reporting. The implementation plan should also identify migration, role mapping, testing, user acceptance and post-launch optimisation activities.
DynamicsHub supports organisations seeking Microsoft-centric HR transformation, alongside wider Dynamics 365 and Power Platform work. The platform targets organisations from 50 to 4,000 employees and is designed to balance enterprise capability with mid-market budget constraints. Assess that fit against evidence, not positioning: clear tenancy boundaries, documented controls, audit records, transparent GBP pricing, and an operating model that HR and IT teams can manage. Pay particular attention to who owns each control after go-live, because tenant isolation depends on daily administration as well as initial design.
Next Steps for Your Tenancy Decision
Use the following sequence to turn an architectural discussion into a procurement decision.
- Classify the data. Separate right-to-work evidence, payroll information, performance records, documents and reporting data by sensitivity and retention requirement.
- Map every data path. Include Dataverse, SharePoint, storage, integrations, exports, background jobs, analytics and backups.
- Define the acceptable boundary. Decide where shared infrastructure is appropriate and where dedicated compute or storage is necessary.
- Request proof. Ask for tenant-attributed logs, deletion records, access reviews, isolation test results and incident procedures.
- Model the full GBP cost. Include licences, environments, storage, integrations, implementation, support and any dedicated components.
- Test the operating model. Run scenarios for leavers, role changes, subject access requests, deletion requests, failed integrations and tenant restoration.
The core decision is not whether multi tenant architecture is safe or unsafe. Properly implemented and continuously evidenced, it can give UK mid-market organisations a strong balance of cost efficiency, scalability and security. The risk appears when a supplier presents shared infrastructure as a complete answer without explaining the controls that protect each organisation's data.
Ask every vendor: What is the tenant identifier? Where is tenant context enforced? Which layers isolate data? How are exports and backups handled? What evidence can you review? Who can access the system during support? How are Right to Work records and retention rules managed? Clear answers should be specific, testable and consistent with the contract.
DynamicsHub helps UK organisations assess and implement Hubdrive's HR Management for Microsoft Dynamics 365 within a Microsoft-centric architecture, with DynamicsHub's message, “Experience HR transformation built around your business.” Speak to DynamicsHub on 01522 508096 today for a tenancy and compliance assessment, or send a message through DynamicsHub to discuss your HR platform requirements.
