Posts by Simon Doy

I am an avid SharePoint enthusiast who works as an Independent SharePoint Consultant based in Leeds, United Kingdom. I am one of the organisers of the Yorkshire SharePoint User Group in the United Kingdom. I have been designing and building SharePoint solutions since 2006.

Power Platform Dev Ops: Configuring Environment Variables and Settings


Photo by Paul Hanaoka on Unsplash

This post is part of a series of posts discussing my experiences with putting in place Dev Ops processes around the Power Platform.

If you have not read the introduction post, I would suggest starting there.

If you have read it then, that is great and thanks for taking time out of your busy schedule to read this.

This post discusses how to use the build and release pipelines to set up your environment variables within your solutions. If you remember the build and release pipelines can be found in the following GitHub repository.

In solutions, the settings for the application are configured using Environment Variables. For example, we use a set of administration email addresses to send failure messages when a Power Automate flow fails.

When using Dev Ops processes then without this step it can be a bit of a pain to deploy the solutions as each time you deploy then the environment variables are generally not set correctly and therefore the application that you have built does not work.

The question is, how do you configure these environment variables with Dev Ops Processes?

Fortunately, with the Power Apps CLI and the Dev Ops pipelines, we can configure these values easily. So let’s show you how to do it.

Using Dev Ops to set environment variables

As mentioned in the previous posts, the build pipeline extracts a settings file from the solution using the Power Apps CLI or PAC command. This settings file is a JSON file which looks something like the one below.

  "EnvironmentVariables": [
      "SchemaName": "i365_AdminEmail",
      "Value": ""
      "SchemaName": "i365_TGPSharePointIncidentsList",
      "Value": ""
      "SchemaName": "i365_TGPSharePointSite",
      "Value": ""
  "ConnectionReferences": [
      "LogicalName": "i365_Office365OutlookManagementSystem",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365"
      "LogicalName": "i365_Office365UsersManagementSystem",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365users"
      "LogicalName": "i365_SharePointManagementSystem",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_sharepointonline"

What we need to do to be able to configure our settings, is take a copy of this settings file and add some tokens to it. These tokens will be replaced by the release process and the settings file will be used to configure the environment variables when the solution is deployed.

So, let’s do that.

First of all, I am making a presumption that your build pipeline is working and creating your solution. As part of the build process, a set of artefacts are associated with the build. One of the artefacts is the settings-test.json file.

Accessing the artifacts.

Take a copy of that file from the artefacts as shown above and download it to your machine.

Next, we replace the values with tokens, tokens should be in the form of __[SettingName]__.

For example:

{       "SchemaName": "i365_AdminEmail",       "Value": ""     }


{       "SchemaName": "i365_AdminEmail",       "Value": "__AdminEmail__"     }

We replace each of the values with the tokens as shown above. Once there is an updated settings file, this file then needs to be uploaded into our git repository so that we can use it in the build and release process.

One of the build pipeline tasks will associate it as a build artefact. This is if it has a file name with “**settings*.json” in it. The naming convention that I use is [company]-[applicationname]-solution-settings.json. This file should be added to your GitHub repository within the folder with the rest of your content for your Power App.

Setting up the Build Variables for token substitution

Once we have the settings.json file with the tokens in place we need to define the settings that will be used to replace the tokens.

Getting to the Azure Dev Ops Pipeline Variable Groups

The way that this is done is to use Azure Dev Ops’s variable groups. These are found in the Pipelines section of Azure Dev Ops under Library.

Choose Library, followed by Variable Groups.

In order to configure different settings per environment, there will be a variable group setup per environment.

Each variable group should have a unique name which includes the environment name that it is being used with.

For our variable groups, we use the following naming convention:


e.g. i365-holidayapp-dev

To set up a new variable group, click on the “Variable Group” button as shown below.

Provide the name and description for the variable group.

For each setting that you have defined as a token in your JSON settings file then create a variable with the same name. So for example __AdminEmail__ becomes AdminEmail.

Once you have created variables for each setting you should have something like the screenshot below.

Example Variable Group with Variables defined

Now that our build variables have been created, repeat for each of your environments, such as test, uat, and production. Remember to save the variables after you have created them!

Referencing the Variable Groups in our Release Pipelines

With our variable groups setup, there is one more job that needs to be done. The release pipelines need to be told about them. The way that I do this is using a YML variable template. This looks something like this:

# This is used to add references to a Azure Dev Ops Variable Group Configuration.
# Replace [customer] with the abbrevation used for the customer.
# Replace [app] with the name of the application.
- group: [customer]-[app]-dev

An example is shown below.

# Example Variable Group
- group: leave-app-test

Notice the line variables and the subsequent line, ' - group‘. This is used to reference the variable group that we have just created. The YAML file is created for each environment and I use the naming convention of [company]-[appname]-[environment]-variables.yml.

With these YAML files created and put into your Git repository. There is one last step and that is to reference the YAML file in our release pipeline. This is shown below:

Referencing the variable group via the template.

Please note the fact that the template is using a relative path. There is an issue with Azure Dev Ops when referencing YAML variable template files which are not within a folder that is under the release pipeline file. Of course, the variable template file can be in the same directory but not in a directory above the current folder.

Each of the variable templates should be set up for each of the environments that we are deploying to.

Testing the deployment

So with everything now in place, let’s test the deployment and show how it will work.

We will run a new build so that we have the reference to the new settings file that is part of the assets.

During the release process, the Setup Power Platform Configuration task will run. This task will look through files with file names that end *settings.json and replace the tokens with the build variable values.

Setting the Solution Environment variables

Now, the JSON file has been set with the required values it is next used to with the solution deployment to set the environment variables in our solution.

The task below configures the environment variables.

Once the release has been completed then the environment variables will have been set. One thing to say is that if you do not set the environment variables correctly then the environment variables will be set to blank!

To check the environment variable that has been set, go into the Power Platform, choose the environment that you have deployed to. Finally, open the default environment and then open up the environment variable and you will see the value set as shown below.

Screenshot shows the environment variable being set.


Hopefully, we have shown you how to use the Azure Dev Ops Build and Release pipelines to set up releasing your Power Platform solutions and set the environment variables from Azure Dev Ops.

In the next blog post, I aim to highlight some more tips and tricks that I use when working with Power Platform and using these Dev Ops processes to streamline our releases.

Thanks for reading, just to say I would appreciate any feedback you have, good or bad. I am particularly interested in seeing how people got on implementing the pipelines and what issues you have hit.

Viva Goals Journey: Implementing Viva Goals at IThink 365 – Week 2 – Introducing to the Team

Photo by Vladislav Klapin on Unsplash


In this article, I will discuss how we continued our journey of introducing Viva Goals at iThink 365.

This post is part of a series of blog posts which document our journey to implement Viva Goals within the organization.

If you have not read the introduction blog post, I would recommend starting there.

If you have read the introduction post, then welcome back and I hope that you are finding the series useful.

Introducing OKRs to the Team

This week we finally introduced the concepts of OKRs and Viva Goals to the team. This was via a Microsoft Teams session and a presentation which I will link to here below.

The session went well with a few questions and some concerns about how OKRs would change the type of work the team doing. Also, they asked how it will fit into the rest of their work?

My response was that it will help them understand what is important to the business and aims to ensure that they do the work that is important to the business. Additionally, I set their minds at rest as we talked about how we are working on this together. Finally, if the team were too busy then that is something that we need to address as people need to have time to do the activities that are important to the business.

However, as we showed the demos of Viva Goals the team became much more satisfied. The demos helped give context to what OKRs and Viva Goals meant. They were pleased to see the OKR check-in process was easy and in some cases would be automated!

Presentation link

The presentation Introduction slide

Next steps

This post is a short one this week as it was about bringing the team along so that they understand what OKRs, why we want to implement them and how Viva Goals will be used.

Next week, I want to work with our team leads to define objectives around learning as it is important that we embrace learning in our daily routine. I have a few ideas on how to do this and will explain them in our next post.

Thanks for reading and would love to hear your thoughts and experiences.

Speak to you next week!