I'm currently working on a project where we're utilizing Power Platform Pipelines for our portal (Power Pages) ALM. The setup for the pipeline is robust and it's exciting to note that it's no longer in preview — meaning it's fully supported by Microsoft.

If you're not familiar with setting up a Pipeline, I’ll be covering that in a future post. For now, you can check out the official documentation on how to set up pipelines in Power Platform.

The project uses an authentication system provided through OpenID, which requires a unique redirect URL for each environment. Initially, I thought of using environment variables to manage this, but soon realized that wouldn’t work well with the site settings. 

Power Platform Pipelines offers some useful guidance on how to extend your pipelines:

After some research, and a discussion and help from my colleague 

 I discovered that the best approach to update the site settings post-deployment is by using Power Automate, triggered at the end of the deployment process.

I started by identifying the specific site setting that needed updating, which I located through the Power Pages management interface.

To capture the ID of this setting for later use, I simply navigated to the site setting in the Power Pages management and copied the GUID from the URL bar:

 for different environments, specifically for testing and production. This is crucial because the initial site and settings are configured in the development environment, and when the pipelines run, they replicate these settings from dev.

Another important detail is knowing which table to target for updates. Initially, I tried writing directly to the virtual table for Site Settings, which didn’t work. I got this error: 

I have not figured out what it means. If someone does, please send me an message on LinkedIn.

I eventually found after talking to Ulrikke again, that the appropriate table to use is the 

table. This table aggregates all the virtual tables and is the one that gets updated during pipeline execution.

I also tried fetching the virtual Site setting table Using 

, but i got nothing. When i tried fetching in the site components i get the settings i need, when filtering on site settings.

I've set up a new Automated Cloud Flow, and it's crucial to note that this must be done within the 

where your pipeline is set up. This ensures access to the necessary pipeline triggers.

I also need the id for the row that we are going to update, this will be the same id in all environments, because the configuration moves downstream with the pipeline.

I went into the Site Components table, and found the Row id uniqe, which i thought maybe was the right one, because the id for the component, was uniqe for the site settings row.

But that did not work, so it was the power pages component id. The one next to the row id, in the column you see above (aka. the first GUID i copied).

For the trigger, use the following parameters:

Add a condition to confirm it's for the Test Environment:

Ensure the last part matches your pipeline stage name.

In this step it is important to choose the right environment. Where you get the site setting from, and also then, in which environment the site setting will be updated.

Get a row by ID from selected environment.

And because we know the GUID of the site setting, we use this.

This step is not neccesary, i do this, so that i know what i need to update the row with, and confirm it is the right row.

3. Step - Action - Update a row in selected environment

Update the site setting in the desired environment.

Repeat the same process for your Production Environment. This ensures consistency across all your deployment stages and aligns the Production settings with those tested in your Development and Test environments.

, and told him what i have done with this. And asked if he knew a better way of doing this. And he told me that he had done this in another way:

"But here’s what I found… this is specific for authentication site settings (OKTA).
The site settings for authentication will “travel” from DEV to downstream environments.
However, if I configure authentication manually on the downstream environment, it doesn’t overwrite, but creates a new set of values.
If I make that particular authentication provider the “default”, it will ignore the one brought over from the DEV environment. So I don’t need to update"

This is specific for authentication site settings (OKTA).

I tried this myself, and it did not work for my customer, because the environments and settings was created long before managed environments and the enhanced data model was introduced. 

Run the pipeline to test and prod (or as many environments you use)

Set up authentication again in both environments, in an unmanaged solution, with different values on the site settings and 

They will then not be overwritten the next time you run your pipelines.

You should always use managed solutions in you test and production environments. But in a special case like this, and until Microsoft solves this, an unmanaged solution in these environments is neccessary.

Extending the Power Platform Pipeline