Multi-tenancy in Power Pages - Rishan Solutions

Multi-tenancy refers to an architecture where a single instance of a software application serves multiple customers (tenants). In the context of Microsoft Power Pages, implementing a multi-tenant solution allows organizations to serve different groups (e.g., customers, vendors, partners, departments) through shared infrastructure, while ensuring data isolation, security, and custom experiences.

What is Multi-Tenancy in Power Pages?

In Power Pages, multi-tenancy can be achieved in a logical or physical sense:

Logical Multi-Tenancy: One Power Pages site serves multiple tenant organizations/users. Each tenant’s data and access are isolated using security roles, web roles, table permissions, and filters.
Physical Multi-Tenancy: Each tenant gets a separate instance of Power Pages or environment. This is more costly but offers full isolation and customization per tenant.

Scenarios Where Multi-Tenancy is Needed

A SaaS platform allowing multiple companies to manage their users.
A government portal for different cities/districts with isolated data access.
A vendor or partner management system.
An educational platform with different schools/universities using the same base site.

Multi-Tenancy Models in Power Pages

Model Type	Description
Single-Site, Multi-Tenant	One portal with logic to separate data and UI per tenant. Cost-efficient.
Multi-Site, Multi-Tenant	Different Power Pages sites for different tenants. More flexibility.
Environment-Based	Separate Dataverse environments for tenants. Full isolation.

Key Components to Implement Multi-Tenancy

1. Tenant Identification

Every user/session must be linked to a “Tenant ID”. This can be:

A field on the user’s Dataverse Contact record.
Pulled from Azure AD Groups or authentication claims.
Captured during login or registration.

2. Web Roles and Table Permissions

Create tenant-specific roles:

Tenant A Admin, Tenant B User, etc.
Assign these roles to Contacts based on their tenant.
Apply record-based Table Permissions to restrict access to only tenant-specific data.

3. Data Filtering

Use Dataverse Views or FetchXML filters:

Filter forms, lists, and data-bound components based on the current user’s tenant.
Use {{ user.id }} in Liquid to get current contact’s metadata.

4. UI Customization per Tenant

Dynamically load content:

Customize headers, logos, styles using Web Templates and Liquid.
Serve different themes or languages based on the tenant.
Use Content Snippets with tenant-aware logic.

5. Authentication per Tenant

Azure AD B2C or Entra ID supports multiple identity providers.
Use claims mapping to assign web roles dynamically on sign-in.
Allow different login paths per tenant using JavaScript redirection or portal logic.

Security Considerations

Never trust the front end for tenant separation. Use server-side Dataverse filters and table permissions.
Assign the minimum required privileges per role.
Mask or restrict unauthorized data in Liquid and JavaScript using conditional logic.
Encrypt or hash tenant identifiers in URL if passed.

Example Scenario

A multi-tenant Vendor Portal serves three companies:

Feature	Description
Tenant Separation	Each vendor sees only their data and user accounts.
Roles	`VendorAdmin`, `VendorUser`, `InternalReviewer`
Login	Vendors sign in via their Azure AD tenant.
Theme	Custom branding per vendor using Liquid templating.
Data Protection	All forms and lists filtered with tenant ID

Power Automate Integration

You can trigger flows with tenant-aware logic:

Use tenant ID in flow filters.
Route approvals or messages to tenant-specific contacts.
Automate tasks per tenant using environment variables or configuration tables.

Tenant Management Patterns

Maintain a Tenant master table in Dataverse.
Track tenant metadata like name, theme, timezone, IDP configuration.
Assign users to tenants during registration or via backend processes.

Portal Deployment for Multi-Tenancy

Deployment Strategy	When to Use
Single Portal, Multiple Tenants	Best for light customization and moderate data isolation needs.
Multiple Sites (Same Environment)	When branding/UI or workflows differ heavily per tenant.
Multiple Environments	When each tenant needs total isolation and custom flows/apps.