Author / Simon Doy

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.
by Simon Doy

Viva Goals Journey: Implementing Viva Goals at IThink 365 – Rolling out the Teams first OKR!


Photo by freestocks on Unsplash

Introduction

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.

Rolling out the OKRs to the Team

So, this week we rolled out an OKR to our development teams! This represents a big milestone as now we have a business wide objective which is mapped down as child objectives and key results to two individual teams!

In this post I will discuss what we did, why and then how we setup Viva Goals to roll up these objectives to the top-level organisation objective.

Firstly, I have been talking to the teams on our stand ups about Viva Goals a lot. So, the setting up of the OKRs should not be unexpected.

So, what is the objective?

It is to establish a learning culture within the organisation, to incentivise curiosity and learning to improve the knowledge in the organisation. The reason being is that, the more we know the better our deliveries for our customers!

The challenge that we have is that whilst we provide people with half a day per week (Friday afternoon) dedicated to learning. Some of the team feel that they do not have the time or permission to do the training. By setting up one of their objectives on learning, I am hoping this will help them feel that they can stop working on a project and spend some time learning. This will help them improve the way they work and what they deliver.

The measurement that we are going to use is Microsoft Learn XP. Each person is assigned a Key Result which they check in with their latest XP result. Whilst this might not be an ideal measurement, we can try it out and see how it goes. What will be interesting is to see whether Microsoft Learn XP is the right metric, It will work for now but we might need to change as we go along.

For each team, an objective is setup which for each team of two is asking them to Increase their Microsoft Learn XP by thirty thousand, or fifteen thousand each per quarter.

Finally, these teams are rolled up together and that forms the overall business objective to establish a learning culture at iThink 365.

So, now we have covered the why and what we are looking to achieve. Let us delve into how we setup Viva Goals to achieve this.

Setting up Viva Goals

The following section discuss how this objective and key result was setup in Viva Goals.

Firstly, at this point we had no users added to Viva Goals and so teams were setup in the following way. In our organisation we have a Delivery Team which is broken down into .NET Development Team and Power Platform Development Team.

So, within Viva Goals (https;//goals.microsoft.com), a delivery team was created.

A team called “Delivery Team” as created and then two teams called .NET Development Team and Power Platform Development Team.

The Delivery Team was created as a department team type.

The .NET Development Team and Power Platform Development Teams were configured with the Delivery Team as their parent team. The two sub teams were created as Team team types.

In order that I had control of the teams, I edited the team settings and made it that only the Team Admins and Team Owner could configure OKRs or Projects for this team. This was achieved by:

  • Clicking on the Team
  • Choosing Team Settings from the tabs at the top
  • Under “Who can create OKRs or Projects for this team?”
    • Choose “Only team admins and team owners”
  • Click Save

Before I invited anyone in, I spoke to the Team via Microsoft Teams and said that I would be inviting them into Viva Goals and setting them up. I reiterated that there was nothing to worry about and this was part of the work that I had been talking about regarding OKRs and Viva Goals.

I then added the users to the Viva Goals and added them to the appropriate team.

Adding a user is achieved by:

  • From Viva Goals
  • Clicking on Users
  • Click on Add members
  • Find the user and then associate them to the team.

With the teams in places, it was now time to setup the Objectives and Key Results.

Firstly, the objective was setup for the Organisation:

  • Select iThink 365 OKRs
  • Click on the + at the top right-hand corner
  • Provide the Title
  • Choose the type as Organisation
  • Expand More Options and set the Permission to Anyone can view, only selected people can align
  • Added a description and set the Outcome to 100% complete
  • Expand Progress
    • Automatic via rollup from key results
  • Alignment was kept blank as Organisational Objective
  • Click Create

With the top-level organisation objective, an OKR was created at the Delivery Team level. This was achieved by:

  • Clicking on Teams and choosing Delivery Team.
  • Click on the + at the top right
  • Fill in the title: “Increase Microsoft Learn XP by 75000”
  • Set the Type as Team
  • Expand More Options and Set that Anyone can view, only selected people can align
  • Provide a description.
  • Expand Alignment and Add Alignment.
  • Search for the Objective “Establish a learning organisation…” be mindful of the period if you are running this over multiple time periods. Choose the appropriate objective and click Save.
  • Click Save to save the new Objective.

Finally, with the Delivery Team Objective setup, we can setup the same objective for each of the teams. So using the same process but at the .NET Development Team and Power Platform Development Team an objective was created called “Increase Microsoft Learn XP by 30000”.

These were each aligned to the Increase Microsoft Learn XP by 75000 Delivery Team Objective.

The key eyed in you will see that we have a problem at that is that 2 x 30000 does not equal 75000 XP. Well, that is because I also have a key result too as I want to lead by example, but I am not part of the development teams. More on that later.

Key Results

The next step now that we have the objectives setup, is to setup the Key Results for each person to a complete.

I performed the creation and setup of the key result in each person’s one to one. That way I could explain again why we were looking to do this and how it was giving them the permission to spend time training. Also, by doing it in there one to one they could ask any questions that they had.

The setup of the key result was achieved by:

  • Expanding on the Increase Microsoft Learn by 30000 objective for each team
  • Click on Add Key Result
  • Fill in the details of the Key Result
  • Title: Microsoft Learn XP ([Name of person])
  • Add Metric: XP
  • Target: Increase from [XP] to [XP]
  • Progress: updated manually
  • Expand details: Change the owner to the person who the key result is for. Make sure you do both owner and check in owner.
  • Change the permissions so that anybody can view, but only selected people can align.
  • Finally, set the alignment and associate it to the “Increase Microsoft Learn XP by 30000”. Remember to choose the one Objective for the right time period.
  • Click Save.

In their 121 we went through the process of getting their Microsoft Learn XP and showing them how to check-in their OKR. I explained how they would receive an email each Monday morning and if they could then follow the process that we had been through to update the Check in.

The setup for the Key Result was as shown below, with the rollup going to the organisation.

Example Key Result and its alignment rolling up from individual to team, department and then organisation.

The process for setting up the Key Results was repeated for both members of the .NET Development Team and the Power Platform Development Team.

Success

As I write this, Monday afternoon, the entire team have updated their OKRs this morning!

However, there were a couple of things that needed to be done at the Objective level to ensure that the Key Result updates were being picked up by the objective.

To check the settings, find the objective that is not being updated and then open it up.

  • Choose … and select Manage Contributions.
  • Check the Contribution is configured correctly, in my example it is set to 0% and need to be changed to 100%
Updating the contributions.

Once this was set, the Objectives all started to work nicely.

Hiding OKRs

One thing that organisations might want to do before they add the users is high some objectives that we might not want to share.

To do that do the following:

  • Edit the Objective
  • Expand the details tab
  • Change the permissions to “Only selected people can view and align”
  • Click Done

These objectives will now not be visible to everyone.

One last thing

I mentioned that the maths did not add up, 2 x 30000 does not equal 75000. I wanted to also spend some time learning and to achieve that I added another Key Result for myself under the Delivery Team. Now the objective is achievable!

Next steps

Now that we have an OKR setup, I am going to monitor the progress and I will report back.

It will be interesting to see how the teams find the tool and we will have to start expanding our objectives so that the teams know what is important to move the business forward.

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

Speak to you soon.

by Simon Doy

Power Platform Dev Ops: Configuring Environment Variables and Settings


Introduction

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": ""     }

becomes

{       "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:

[company]-[appname]-[environmentname]

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.
variables:
- group: [customer]-[app]-dev

An example is shown below.

# Example Variable Group
variables:
- 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.

Conclusion

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.