Ever since I started using solution-aware Power Pages, I’ve always had to include an extra post-deployment step to manually update environment-specific Site Settings. However, that changed recently when Microsoft introduced a new feature that allows us to use Environment Variables as the source for Site Settings.

What are Site Settings?

Site Settings are nothing but the meta data key value pair used by Power Pages to define settings for by the WebSite configured in a given environment. These settings control various aspects of the portal’s behavior and are crucial for maintaining different configurations across environments.

The Problem

Before this feature, Site Settings in solution-aware Power Pages presented several challenges:

• Manual Post-Deployment Updates: Each time a solution was deployed to Test, UAT, or Production, we had to manually update Site Settings to match the new environment.
• Unmanaged Layer Issues: If the deployed solution was Managed, modifying Site Settings post-deployment added an unmanaged layer, breaking the integrity of the solution.
• Inconsistent Configurations: Maintaining consistency across environments required manual intervention, increasing the risk of errors.
• Redundant Storage of Common Settings: Some settings, such as API URLs, were needed in multiple Power Platform components (Power Pages, Power Automate, Power Apps, etc.), requiring duplicate maintenance.

The Solution: Site Settings with Environment Variables

Microsoft recently introduced a feature that improves how Site Settings are stored and managed in solution-aware Power Pages.

New “Source” Field in Site Settings

A new field, “Source,” has been added to the Site Setting table, allowing users to specify where the setting value should be stored.

Two options are available:

• Table: Stores the Site Setting value directly in the Site Setting table (traditional approach).
• Environment Variable: Links the Site Setting to an Environment Variable, dynamically retrieving its value based on the environment.

For configuration details, check Microsoft Learn.

Why This is a Game-Changer

In my opinion, this feature is a game-changer for the Site Settings component in Power Pages. By allowing Site Settings to be defined as Environment Variables, we no longer need to manually update settings in different environments. More importantly, these Environment Variables are not limited to Power Pages—they can be used across the entire Power Platform, wherever Environment Variables are accessible.

For example, imagine we have a requirement to store a common API endpoint URL that needs to be used in both Power Pages and Power Automate. Previously, we would have to maintain this URL separately in two places:

• As a Site Setting in Power Pages.
• As an Environment Variable in Power Automate.

This approach created redundancy, requiring manual updates in both locations whenever the URL changed. With the new feature, we can now create a single Environment Variable to store the API endpoint.

• In Power Pages, we can create a Site Setting and set its Source to this Environment Variable, ensuring the portal retrieves the latest value dynamically.
• In Power Automate, we can access the same Environment Variable wherever needed, eliminating duplicate configurations.

This not only simplifies management but also ensures consistency across different components of the Power Platform, reducing errors and improving maintainability.

Since we can now use Environment Variables as the source for Site Settings, all the benefits of Environment Variables extend to Site Settings as well. This includes enhanced security, automation, and environment-specific configuration management.

• Security & Sensitive Data Handling: Instead of storing sensitive information (like API keys or secrets) directly in Site Settings, we can reference Azure Key Vault through Environment Variables. This ensures that sensitive values are securely managed and not exposed in Dataverse tables.
• Application Lifecycle Management (ALM) & Deployment Automation: Environment Variables can be pre-configured with different values for Dev, Test, UAT, and Production environments. When deploying solutions through Power Platform Pipelines or Azure DevOps, the correct values are automatically assigned, eliminating the need for manual updates after deployment.
• Managed Solution Integrity: When Site Settings are updated post-deployment, they create an unmanaged layer, which can break the integrity of Managed Solutions. By using Environment Variables, values are updated dynamically without modifying the solution components, keeping the solution properly managed.
• Cross-Platform Usability: Environment Variables can be used not just in Power Pages but across Power Automate, Power Apps, and Dataverse plugins. This allows for a centralized configuration that can be accessed across multiple Power Platform components, reducing redundancy and ensuring consistency.
• Scalability & Maintainability: Managing configurations through Environment Variables makes it easier to scale solutions across multiple environments and organizations. Updates to settings can be made centrally, reducing maintenance efforts and minimizing configuration drift.

Choosing Between Table-Based vs. Environment Variable-Based Site Settings

Use Environment Variables when:

• The setting is environment-specific (e.g., API URLs, feature toggles, connection strings).
• The value needs to be shared across Power Pages, Power Automate, Power Apps, or other Power Platform components.
• You want to avoid manual post-deployment updates in downstream environments (Test, UAT, Production).

Use Table-Based Site Settings when:

• The setting is specific to the Power Pages portal and doesn’t need to be accessed outside of Power Pages.
• The value is static and unlikely to change per environment.
• You need granular control over records (e.g., role-based access to modify settings).

Summary

The ability to use Environment Variables as the source for Site Settings introduces:
🔹 Better security by enabling Azure Key Vault integration for sensitive data.
🔹 Improved ALM & deployment automation by eliminating manual updates.
🔹 Consistent configuration management across Power Pages, Power Automate, and other Power Platform components.
🔹 Scalability and maintainability through centralized settings.

This feature makes Power Pages deployments more robust, secure, and efficient, significantly reducing manual configuration efforts and deployment risks.