DevOps on Hat Full of Data

Inherited Value in a Parent Child Pattern

Mon, 23 Sep 2024 08:03:22 +0000

In the previous post in this series we created a Parent Child hierarchy using a Dax Pattern from SQLBI. There are times it is useful to calculate an inherited value from parent item to child. The assigned to person on a User Story to be passed onto the child tasks that are not assigned to anyone, the target date of a feature to be passed down to the child user story and then onto the child tasks. The child items need to be completed before the parent target date.

Power BI and DevOps Series

This post is part of a series:

Get DevOps Data into Power BI
Add Parent Child Hierarchy using DAX Patterns
Inherited Value in a Parent Child pattern
Add conditional formatting icons the easy way

The Logic

We are going to add this as a calculated column into the work items table. If you were doing this by hand you would go through the items in the path column in reverse, looking up each target date until you found a non-blank one. In DAX we do this by creating a table of the WorkItemIDs in the path and looking up their target dates. Then we filter to only rows with target dates and take the first one.

Inherited Value DAX

Lets work through an example.

WorkItem 46 has an ItemPath of 38|39|45|46, which means it has a Path length of 4. So we start by using GENERATESERIES to create a column 1-4

1

GENERATESERIES( 1 , PATHLENGTH( WorkItems[ItemPath] ), 1 )

Value1234

We put that inside a GENERATE function and use PATHITEMREVERSE to get the work item ids from the path and then LOOKUP to use that WorkItemID to get the TargetDate of each item. GENERATE function and nested VARs is one of my favourite combinations.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


VAR tabWorkItems = 
 GENERATE(
 GENERATESERIES( 1 , PATHLENGTH( WorkItems[ItemPath] ), 1 ),
 VAR tableRow = [Value]
 VAR _WorkItemID = VALUE( PATHITEMREVERSE( WorkItems[ItemPath] , tableRow ) )
 VAR _TargetDate = LOOKUPVALUE( WorkItems[TargetDate] , WorkItems[WorkItemId] , _WorkItemID )
 RETURN ROW ( 
 "WorkItemID",_WorkItemID,
 "TargetDate",_TargetDate
 )
 )

ValueWorkItemIDTargetDate1462453392024-09-094382024-11-1

Then we filter the table to rows with a TargetDate and take the first row ordered by Value. This gives us one row of data.

1
2
3
4
5
6


VAR tabFiltered =
 TOPN( 
 1,
 FILTER(tabWorkItems,[TargetDate]>BLANK()),
 [Value],ASC
 )

ValueWorkItemIDTargetDate3392024-09-09

Finally we use MINX to extract the TargetDate of that single row. The final calculated column DAX looks like this.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


Inherited Target Date = 
// Create a table of Value, WorkitemID and TargetDate
VAR tabWorkItems = 
 GENERATE(
 GENERATESERIES( 1 , PATHLENGTH( WorkItems[ItemPath] ), 1 ),
 VAR tableRow = [Value]
 VAR _WorkItemID = VALUE( PATHITEMREVERSE( WorkItems[ItemPath] , tableRow ) )
 VAR _TargetDate = LOOKUPVALUE( WorkItems[TargetDate] , WorkItems[WorkItemId] , _WorkItemID )
 RETURN ROW ( 
 "WorkItemID",_WorkItemID,
 "TargetDate",_TargetDate
 )
 )
// Take the first row of the filtered to non-blank
VAR tabFiltered =
 TOPN( 
 1,
 FILTER(tabWorkItems,[TargetDate]>BLANK()),
 [Value],ASC
 )
// Return the Target Date
VAR Result = MINX( tabFiltered , [TargetDate] )
RETURN Result

Inherited Value Conclusion

The Parent Child pattern is very useful and adding in the inherited values adds extra possibilities. I wanted to be able to identify the child items that were making the parent items late.

References

This post builds on the last post in this series and using the SQLBI Parent Child found at https://www.daxpatterns.com/parent-child-hierarchies/.

Power BI Series

DevOps Parent Child Hierarchy in Power BI

Mon, 02 Sep 2024 08:27:43 +0000

Azure DevOps is built around the pattern than items have child items and so a backlog view will show the items in a hierarchy. When the work items some into Power BI that is not shown. So this gives me the chance to use one of my favourite resources from SQLBI, DAX Patterns and their Parent-Child pattern.

I am using the Agile process so the hierarchy is Epic – Feature – User Story – Task. I have made sure my project includes all the layers correctly. You can work around oddities but for this post we will assume all layers of the items are as we expect.

Power BI and DevOps Series

This post is part of a series:

Get DevOps Data into Power BI
Add Parent Child Hierarchy using DAX Patterns
Inherited Value in a Parent Child pattern
Add conditional formatting icons the easy way

DAX Patterns – Parent Child Hierarchy

DAX patterns comes in multiple formats, a book, a website and videos. They are written by SQLBI and have saved me hours and hours. For this post we are going to adapt the Parent-Child pattern to DevOps data. I am going to use the report built in the previous post in this series. The pattern is fully explained here https://www.daxpatterns.com/parent-child-hierarchies

Adding the Path

The pattern uses a function called path. This function takes an row id and the parent row id and walks up the path until it reaches a row with no parent. Work Items in DevOps have WorkItemID and ParentWorkItemID. So following the instructions we add a column to the WorkItems table.

1

ItemPath = PATH(WorkItems[WorkItemId],WorkItems[ParentWorkItemId])

The ItemPath gives us the list of IDs in the hierarchy above the current row. It does requires the path to be complete so it might not work if you have filtered out some of the items.

Adding DevOps Hierarchy Level Columns

From the above post these are the Level 1 to Level 4 columns, we just need to swap out the right column names. We also know the the names of our levels from DevOps so we can use slightly more meaningful names, Level 1 = Epic, Level 2 = Feature etc. Add the 4 columns using the pattern below, copied straight from the SQLBI post.

1
2
3
4
5
6
7


Epic = 
VAR LevelNumber = 1
VAR LevelKey = PATHITEM ( WorkItems[ItemPath], LevelNumber, INTEGER )
VAR LevelName = LOOKUPVALUE ( WorkItems[Title], WorkItems[WorkItemId], LevelKey )
VAR Result = LevelName
RETURN
 Result

Adding a Matrix

The quickest way to see the hierarchy in action is to add a matrix visual. Into the rows we put the levels of the hierarchy to whatever levels we want. Into the values I put # Work Items. It looks great we can expand the different levels and see the 72 work items split out into features etc.

But we get blank rows at the top of each section. Not to worry of course our friends at SQLBI have a solution.

Fixing the measures

In order for this to work we need to compare the maximum path length with the level being displayed. The path length we add as a column Depth to Work Items and then add a measure MaxRowDepth. Then using ISINSCOPE function we calculate the display depth in a measure called ItemBrowseDepth.

Column Added to WorkItems table

1

Depth = PATHLENGTH( WorkItems[ItemPath] )

2 Measures Added to WorkItems table

1
2
3
4
5
6
7


MaxRowDepth = MAX( WorkItems[Depth] )

ItemBrowseDepth =
 ISINSCOPE ( WorkItems[Epic] ) 
 + ISINSCOPE ( WorkItems[Feature] )
 + ISINSCOPE ( WorkItems[User Story] )
 + ISINSCOPE ( WorkItems[Task] )

Now we can add measures that use these values to decide if to display the row or not. The logic being we only show rows where the browse depth is less than or equal to the max row depth. So I fix the # Work Items using the example from the SQLBI Pattern.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77


# Work Items =
VAR Val = COUNTROWS ( WorkItems )
VAR ShowRow = [ItemBrowseDepth] 

This now fixes the matrix to not show blank rows

![Matrix with no blank rows](image-11.png)

## Conclusion on Parent Child Hierarchy

This makes the DevOps data easy to report on. The measures roll up the data to the different levels so the total hours can be calculated etc. Handling DevOps plans with missing layers is hard work, I’ve done it where some User Stories were children of the Epic. That made the pattern clunky so I’d probably push back now and insist the DevOps plan was kept clean.

## More Power BI Posts

- [Conditional Formatting Update](https://hatfullofdata.blog/power-bi-conditional-formatting-update/)

- [Data Refresh Date](https://hatfullofdata.blog/power-bi-data-refresh-date/)

- [Using Inactive Relationships in a Measure](https://hatfullofdata.blog/power-bi-inactive-relationships-in-a-measure/)

- [DAX CrossFilter Function](https://hatfullofdata.blog/power-bi-dax-crossfilter-function/)

- [COALESCE Function to Remove Blanks](https://hatfullofdata.blog/power-bi-coalesce-function-to-remove-blanks/)

- [Personalize Visuals](https://hatfullofdata.blog/power-bi-personalize-visuals/)

- [Gradient Legends](https://hatfullofdata.blog/power-bi-gradient-legends/)

- [Endorse a Dataset as Promoted or Certified](https://hatfullofdata.blog/power-bi-endorse-a-dataset/)

- [Q&A Synonyms Update](https://hatfullofdata.blog/power-bi-qa-synonyms-update/)

- [Import Text Using Examples](https://hatfullofdata.blog/power-bi-import-text-using-examples/)

- [Paginated Report Resources](https://hatfullofdata.blog/paginated-report-resources/)

- [Refreshing Datasets Automatically with Power BI Dataflows](https://hatfullofdata.blog/refreshing-datasets-automatically-with-dataflow/)

- [Charticulator](https://hatfullofdata.blog/charticulator-simple-custom-chart/)

- [Dataverse Connector – July 2022 Update](https://hatfullofdata.blog/power-bi-dataverse-connector-july-2022-update/)

- [Dataverse Choice Columns](https://hatfullofdata.blog/power-bi-dataverse-choices-and-choice-column/)

- [Switch Dataverse Tenancy](https://hatfullofdata.blog/power-bi-switch-dataverse-tenancy/)

- [Connecting to Google Analytics](https://hatfullofdata.blog/power-bi-connecting-to-google-analytics/)

- [Take Over a Dataset](https://hatfullofdata.blog/power-bi-take-over-a-dataset/)

- [Export Data from Power BI Visuals](https://hatfullofdata.blog/export-data-from-power-bi-visuals/)

- [Embed a Paginated Report](https://hatfullofdata.blog/power-bi-embed-a-paginated-report/)

- [Using SQL on Dataverse for Power BI](https://hatfullofdata.blog/using-sql-on-dataverse-for-power-bi/)

- [Power Platform Solution and Power BI Series](https://hatfullofdata.blog/power-platform-solution-and-power-bi-part-1/)

- [Creating a Custom Smart Narrative](https://hatfullofdata.blog/power-bi-creating-a-custom-smart-narrative/)

- [Power Automate Button in a Power BI Report](https://hatfullofdata.blog/power-automate-button-in-a-power-bi-report/)

## Power BI Series

- [SVG in Power BI series](https://hatfullofdata.blog/svg-in-power-bi-part-1-svg-basics/)

- [Power BI and Project Online series](https://hatfullofdata.blog/power-bi-connecting-to-project-online/)

- [Slicers series](https://hatfullofdata.blog/power-bi-slicers-introduction/)

- [Dataflow series](https://hatfullofdata.blog/power-bi-create-a-dataflow/)

- [Power BI SVG series](https://hatfullofdata.blog/svg-in-power-bi-part-1-svg-basics/)

- [Power Automate and Power BI Rest API series](https://hatfullofdata.blog/power-automate-and-power-bi-rest-api/)

- [Power BI and DevOps series](https://hatfullofdata.blog/devops-data-into-power-bi/)

Get DevOps Data into Power BI

Tue, 27 Aug 2024 09:09:57 +0000

Azure DevOps is full of data that management want to to report on. Adding a Power BI report is an obvious way to do this. There are plenty of sample reports and Microsoft posts giving you guidance how to get DevOps data into Power BI. This post is my take on how I would build the reports. My focus is making them easy to extend and easy to point at a different organisation and project.

Power BI and DevOps Series

This post is part of a series:

Get DevOps Data into Power BI
Add Parent Child Hierarchy using DAX Patterns
Inherited Value in a Parent Child pattern
Add conditional formatting icons the easy way

YouTube Version

Microsoft References for DevOps Data into Power BI

https://learn.microsoft.com/en-us/azure/devops/report/powerbi/odataquery-connectGreat post showing you to use Visual Studio Code to write the query, test it and then use it in Power BI
https://learn.microsoft.com/en-us/azure/devops/report/powerbi/sample-odata-overviewLots of sample reports

OData Queries

We get DevOps Data into Power BI using an OData query. From the first Microsoft link above it shows the query is made up of different parts. The first part is a path and then extras that select columns, filter the data and sort the data.

The simplest form though is just the URL, that will bring through all the columns and all the rows of data. We will start with that.

Simplest Query for Work Items

1

https://analytics.dev.azure.com/{Organisation}/{Project}/_odata/v3.0-preview/WorkItems?

The path includes the organisation and the project names. So we start in Power Query, by clicking on Transform data on the Home ribbon in Power BI. Then click on Manage Parameters to open a dialog. You need to add 2 parameters, Organisation and Project. Click on New to start a new parameter, enter in a name and description (yes add that description, future you will thank you), select type text and enter in the current value for the Organisation and the Project.

We could now use Get Data and select OData and build the string… But that is hard work and not easy to read! So I’ve written a template to walk you through. Click on New Source and select blank query. Click on Advanced Editor and paste in the code below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


let
 // Path using 2 parameters
 Path = "https://analytics.dev.azure.com/" & Organisation & "/" & Project & "/_odata/v3.0-preview/WorkItems?",
 
 // URL made up of parts
 URL = Path,
 
 // Do the OData query
 Source = OData.Feed(URL, null, [Implementation="2.0",OmitValues = ODataOmitValues.Nulls,ODataVersion = 4])
in
 Source

The Path line uses the 2 parameters and points to the WorkItems. The URL line looks redundant now but will make more sense when the query has more parts. The Source line uses the URL and includes the flags recommended by the link at the top of this post to prevent throttling.

When you click OK and set up the connection if required you should get a table of data with lots of columns.

Selecting the columns

The above query gives us more columns than we want. Rather than removing the columns in Power Query we can add a select line to the query which will make the OData query faster. So we need to pick the columns we want while we can see them all. I selected and put them into a comma separated string to make up a $select string to add to the Power Query

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


let
 // Path using 2 parameters and select columns
 Path = "https://analytics.dev.azure.com/" & Organisation & "/" & Project & "/_odata/v3.0-preview/WorkItems?",
 Select = "$select=WorkItemID,Title,WorkItemType,State,TargetDate,ParentWorkItemID,OriginalEstimate,AssignedToUserSK",

 // URL made up of parts
 URL = Path & Select,
 
 // Do the OData query
 Source = OData.Feed(URL, null, [Implementation="2.0",OmitValues = ODataOmitValues.Nulls,ODataVersion = 4])
in
 Source

When you finish editing the query you will get a table of the work items from DevOps.

You could add more parts to the query for filtering and sorting if required.

User and Calendar Table

DevOps has other tables including a user list and a calendar. These can be pulled through to Power BI using the same pattern.

Users

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


let
 // Path using 2 parameters and select columns
 Path = "https://analytics.dev.azure.com/" & Organisation & "/" & Project & "/_odata/v3.0-preview/Users?",
 Select = "$select=UserSK,UserName,UserEmail",

 // URL made up of parts 
 URL = Path & Select,

 // Do the OData query
 Source = OData.Feed(URL, null, [Implementation="2.0",OmitValues = ODataOmitValues.Nulls,ODataVersion = 4])
in
 Source

Calendar

This includes a filter for the Year to be greater than or equal to, ge, 2023.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


let
 // Path using 2 parameters and select columns
 Path = "https://analytics.dev.azure.com/" & Organisation & "/" & Project & "/_odata/v3.0-preview/Dates?",
 Select = "$select=Date,MonthName,MonthOfYear,Year",
 Filter = "&$filter=Year ge 2023",

 // URL made up of parts 
 URL = Path & Select & Filter,

 // Do the OData query
 Source = OData.Feed(URL, null, [Implementation="2.0",OmitValues = ODataOmitValues.Nulls,ODataVersion = 4])
in
 Source

Some Modelling

Once the queries are written and loaded into Power BI desktop we are ready to do some modelling. I’m keeping it very light as I have another post coming that will implement the Parent Child hierarchy needed.

Relationships

The relationship model is only three tables, fact table WorkItems and the 2 dimension tables Users and Calendar. The relationships are

TableColumnRelationshipTableColumnUsersUserSK1 to ManyWorkItemsAssignedToUserSKCalendarDate1 to ManyWorkItemsTargetDate

Measures

I only created two measures. The first was for the total hours in the original estimate column. If we had included completed and remaining hours I would have created measures for them as well. The second one was for the count of items

1
2
3


Total Hours = SUM(WorkItems[OriginalEstimate])

# Work Items = COUNTROWS(WorkItems)

Create Visuals

I kept it simple. Not all the tasks had Target dates so we could not do much via dates. So I had total hours and number of tasks and Users and Item States. I created a table and a tree map visual.

Conclusion on DevOps Data into Power BI

The above model is limited, I can’t see the structure of the project, I can’t rollup the tasks into user stories etc. It does have the data in it to get there though. The next post on adding the Parent-Child hierarchy will help.

Power BI Series

Editing Azure DevOps items in Excel

Tue, 20 Aug 2024 08:30:38 +0000

One of the easiest ways to edit a project in Azure DevOps is to connect Excel to the project. This post walks you through connecting to a project and updating the DevOps items in Excel. Its mostly for selfish reasons as I need to remember how to do this.

Microsoft also has a post about this at https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/office/bulk-add-modify-work-items-excel

Add Excel Extension

This needs an Excel extension added from the Visual Studio site. You need to download Azure DevOps Office Integration 2019 from here and execute

Download Visual Studio Tools – Install Free for Windows, Mac, Linux (microsoft.com)

Once you have done this, in Excel you will have a Team ribbon.

Create a Tree Query

If you want to edit many items including child and parent hierarchy, then the easiest way is to write a tree query in DevOps that loads the right tasks and then use that to pull the right tasks into Excel. In DevOps under Boards select Queries. Then select New Query. Change query type to Tree of work items and type of tree to Parent/Child. Select the right filters to pull the items you want and then save your query. Save and run the query to make sure you get a hierarchy of tasks. In my example I wanted all the items in the project.

Connect to a DevOps Project

On the Team ribbon, click on New List. If this is the first time you’ve connected you need to add a server first.

Adding a Server

Click on the Servers button. Then in the next dialog, click on Add. Into the next dialog enter in the url to the organisation, for example https://dev.azure.com/HatFullOfData/. Click OK to finish adding the server, you will be prompted to login. Click Close to return to the original dialog.

Connecting to a project

You start from the connect to Azure DevOps dialog, which will open from adding a server or opened by clicking on New List on the Team ribbon on a new sheet. Select the server and select the right project and click connect. Select your tree query from the drop down and click OK The tasks from the project should load as a table into Excel.

The table format needs some explaining. Title 1 is the name of the highest level tasks and Title 2 etc are children of the Title 1 task above it. You can add another level of hierarchy by clicking on Add Tree Level from the Team ribbon. You can also add other DevOps columns by clicking Choose Columns and using the middle buttons to add or remove columns in the Choose columns dialog.

Adding and Publishing DevOps items in Excel

Items can be added to the table just typing in new rows. The ID column leave blank, the Title 1 – 4 fill in making sure you understand the hierarchy. Some fields such as Target Date are read only for some Work Item Types. When you want to see the results in DevOps click on Publish. Then open DevOps to see the work items.

Conclusion

I needed to create a project plan in DevOps from a list of tasks I had in a text file ready for a demo. There were 80 tasks and I knew I could it them quicker in Excel than I could in DevOps because I am more familiar with Excel. I also wanted to note down how I then loaded those tasks into DevOps from Excel.

Other related series include:

DevOps with Power Automate posts

DevOps updates on behalf of another with Power Automate

Mon, 19 Aug 2024 09:34:27 +0000

I had a need to use automation to do DevOps updates on behalf of another person so when the DevOps adoption metrics were done we the stats were slightly more accurate. This can only be done using REST API and will need permissions. This post is part of the DevOps and Power Automate series.

DevOps with Power Automate posts

YouTube Version

It’s on the backlog!

Permission required to makes updates on behalf of another

The trick to being able update on behalf of another is to update the ChangedBy field to another persons email address. This is not normally allowed, it breaks the rules. So the permission we need is to bypass the rules and make illegal updates.

Permissions are managed in Project Settings, you then click on permissions. Click on Users at the top and then click on the user being used in the flow to show their permissions. Under Boards check the permission for Bypass rules on work item updates. This needs to be set to Allow.

Make Updates on behalf of another

Now we have permission is ignore the rules we can test out a flow. In the REST API documentation for updating an item https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/update you will see there is a boolean parameter bypassRules. This can be added to the relative URI using & to separate the parameters.

In the body section I have added an update to the ChangedBy field. This update updates the State to active and performs it on behalf of Dan. In the task history we can see the update and see I did it on behalf of Dan.

Word of caution

By passing the rules, it also means that the updates behind the scenes that happen are turned off. If we change the state to closed using the same technique the we get an error when we open the work item.

So make sure you have checked the updates you are doing and include all the fields you need to update, even the hidden ones.

Second word of warning is no checks are done on the updates. So you can assign a task to an email address that doesn’t have access, or update to a state that is not valid. So treat this one with caution.

Conclusion

Updates on behalf of another is a very powerful trick. But should be treated with extra caution and it has made me double check permissions on a ew projects so access to by passing the rules is limited.

Update DevOps without Notifications with Power Automate

Fri, 16 Aug 2024 07:52:49 +0000

When a work item is assigned to you, by default you are sent a notification. Notifications can also be sent regarding updates to your items. Now imagine creating over 10 thousand tasks automatically and assigning them to people. I recently did this on a projects and potentially each person was going to get 100s of emails. So I needed Power Automate to assign the tasks without notifications. This post is part of the Power Automate and DevOps series.

DevOps with Power Automate posts

YouTube Version

They are on the backlog!

Permissions for updates without notifications

Updating DevOps without notifications is not something that everyone should be able to do. Or at least the admins will want to be able to control who can do it.

In the Project settings, click on Permissions. Then click on Users to list your users. When you click on a person you get to see all their permissions. They can be Allow, Deny or Not Set for all the different actions. (inherited) means it is set by being a member of a group. If you hover your cursor over the (i) you will get a description telling you which membership the permission as inherited from. A Deny overrides an allow, so you might need to manually override the inherited permission.

The permission we are interested in is Suppress notifications for work item updates.

Updating without Notifications

Now we have the permission we can test it out in an update. This can only be done on updates done by a REST API call. If you look on https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/update there is a URI parameter suppressNotifications which is a boolean.

URI parameters get added after the ? and are separated by &. So the code to update item 36 without notifications would be

1

{project}/_apis/wit/workitems/36?suppressNotifications=true&api-version=7.0

Item History

Suppressing the notifications does prevent automated updates filling inboxes with emails that will just get deleted. It does not however supress the history of the item being updated. So who did the update and when is still recorded.

Running a Wiql DevOps query in Power Automate

Wed, 14 Aug 2024 11:55:17 +0000

Wiql stands for Work Item Query Language and is the language used to define the queries in Azure DevOps. Its has a very similar syntax to SQL. Power Automate can use a REST API send a query to DevOps to execute the query. This post post is part of the Power Automate and DevOps series.

DevOps with Power Automate posts

The full reference can be found at https://learn.microsoft.com/en-us/azure/devops/boards/queries/wiql-syntax?view=azure-devops

Writing the Query

You can write it by hand, and I’m sure some people do. I use the query tools in DevOps to build the query and then view the Wiql code. For this post the example we are going to is to assign all the items in a hierarchy to one person. For example all the items in the Design Shiny feature.

Wiql Editor

Before we can work with WIQL we need to install the extension Wiql Playground in the organisation. You will need to be an organisation admin to do this. Head to the marketplace for Visual Studio, found here

Extensions for Visual Studio family of products | Visual Studio Marketplace

Search for wiql and click on the Wiql Editor. When the extension information page opens click on Get it free. Then on the next page, select the right organisation and click Download. It will now appear under boards in your project.

Construct Query

Now in Queries construct the query. I am not here to teach you building queries in DevOps, there is a great post to get you started here https://learn.microsoft.com/en-us/azure/devops/boards/queries/using-queries. My query is a tree of work items, matching the top item first and only has 2 criteria of the top item is ID 17 and the child item is not closed or completed.

Once you have your query working and you have saved it you can view the Wiql. Click on the three dots in the top right. Then from the menu select Edit query wiql. This will open a pane containing the code that you can copy to your clipboard.

Note you have to save after any changes for the changes to be in the Wiql code.

Running the Wiql in Power Automate

Now we have the Wiql code we can write the flow. The flow will have the parameters of the Parent Work Item ID and the email address to assign all the tasks to. We will then use a compose action to the Parent Work Item ID and Project name into the Wiql.

The next step is to run the query. The documentation for the REST API call can be found here https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/wiql/query-by-wiql The method is Post and the URI will be the same for all Wiql

1

_apis/wit/wiql?api-version=7.1-preview.2

The body is JSON with only one field query with the output from the compose action.

When we run the flow and enter in the Parent ID 17 and the email Dan@lgb123.onmicrosoft.com it executes and returns us the data.

Handling the Output of the HTTP call

In the successful action we can click on Show raw output in the Outputs section to open a pane and explore the Json output. Scroll past the headers and then in the body section, past columns to find workItemRelations. This will list all the work items returned by the query, not their details, just the id and url in the target section.

To make this easy to work with we need to use a Parse JSON so copy all the output JSON and return to editing the flow. Add a Parse JSON step and add the Body returned by the HTTP to the Content. Next we need to add a schema, this can be generated. Click on Generate from sample. Then paste in the JSON you copied and click Done. And a schema will be added.

The output schema is now known to the flow. So we can use the output to loop through all the items and update the work items.

Looping through workItemRelations

We can loop through the workItemRelations using an Apply to each action. The piece of information I want from each item is the target – id. So I add a compose and add the following expression

1

item()?['target']?['id']

I would then test to make sure you get the number of items you expect and that the compose does return the ids you expect

Finally we can add a step to assign each task to the email given in the parameter. I use a Send HTTP method rather than the Update a Work Item so I can as explained in a future post turn off notifications.

We can then run the flow and check the results in DevOps and see the tasks have been assigned.

Conclusion

this was one example of using Wiql inside Power Automate. I have used it to duplicate hierarchies and delete a hierarchy. The skill comes in being able to write the Wiql to achieve what you need.

Using DevOps REST API in Power Automate

Tue, 13 Aug 2024 16:37:38 +0000

DevOps REST API is a well documented API that we can easily use in Power Automate to perform a huge range of actions. The connector includes an action to make it easy. The API documentation can be found at

https://learn.microsoft.com/en-us/rest/api/azure/devops

In this post we will take some simple examples to get you started. This is the third post in the DevOps and Power Automate series.

DevOps with Power Automate posts

YouTube Version

Its coming honest!

Get Task Details using DevOps REST API

Power Automate includes an action to get the details of a Work Item. When we look we can see it has 4 required fields. Organization name, Project Name and Work Item Id are easy. We will have them. I had problems with Work Item Type, I didn’t always have that. So I looked to DevOps REST API for an alternative.

If we look in the documentation and then search for Get Work Item, you will find the syntax for fetching the details of one work item. The URL needs three pieces of information, shown in the {} brackets, organization, project and id. So no Work item type is required.

https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/get-work-item

We start with an instant flow. Then we add the a parameter to the trigger of the work item id. Then we add the action Send an HTTP request to Azure DevOps. The Organisation we can use our environment variable (or from the drop down). The method is GET. The Relative URI is everything after the organisation in the url we got from the documentation.

1

{project}/_apis/wit/workitems/{id}?api-version=7.2-preview.3

When we run the flow, we get prompted to enter the number of a work item id. When it completes, we get returned the JSON of that work item details. If you need to extract information from that JSON, you will probably need a Parse JSON action. (Another post!)

Update a Work Item using DevOps REST API

We can update an item using the REST API. For this example the flow will update a given task to have the state Active and be assigned to the given email. So, we add Work Item ID and Email as two parameters to the trigger.

Then we add a Send an HTTP request to Azure DevOps action. The Organisation is the same as before, the method is now Patch as we are updating data. The Relative URI is exactly the same as before. In the headers we need to add Content-Type and application/json-patch+json

In the Body we need to add a JSON object that includes the fields we want to update. For this we need to know the field names, see the previous post in the series for ways to find them. It is just text so we can insert dynamic content, e.g. the email address. The above example picture and code below shows changing the State to Active and assigning it to the Email address

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


[
 {
 "op": "add",
 "path": "/fields/System.State",
 "value": "Active"
 },
{
 "op": "add",
 "path": "/fields/System.AssignedTo",
 "value": "@{triggerBody()['text_1']}"
 }
]

Conclusion

Rest API is a very powerful way to work with Azure DevOps and the action in Power Automate does make it very easy to use. It is worth having a test project to try out some of the options. Other posts will look at using Rest API to make changes without notifications and on behalf of another person. Also a bulk delete process, which needs a post of its own due to a few oddities.

Power Automate Update Fields in Azure DevOps

Mon, 29 Jul 2024 08:09:46 +0000

In a previous post we created items in DevOps. Although the Power Automate create item action had lots of fields, it did not have all the fields. This post shows you how to find the names for those fields and update fields in Azure DevOps using Power Automate.

DevOps with Power Automate posts

YouTube Version

Its coming 🙂

The Problem

If you compare the fields available in a standard Epic item in DevOps with the fields available in Power Automate create work item action you will notice some fields are missing. The obvious missing ones being Start Date and Target Date and other fields like Business Value etc and any custom fields you’ve added will not be there so we need to update fields in Azure DevOps.

The observant ones amongst you will have noticed the Other Fields option in the Power Automate action. It wants a key for your field which is the name of the field. And guess what that name is not going to be StartDate. So our first job is finding that name.

Finding Field Names v1

This is the first method and I think the simplest method. Start by creating an item in DevOps that has values in the fields you would like the names of. I’ve populated Effort, Business Value, Time Criticality, Start Date and Target Date.

Then in a Power Automate instant flow I add an action to get the work item details of that item, notice it is number 21. In the Get work item details I populate Org1, Project, Type=”Epic” and Id=21. Then I run that flow and look at the outputs from that step.

If you scroll through the fields you will eventually find Business Value etc with their full field names. You need to replace the _ with . as I assume JSON objects to dots in field names. Note down the ones you need.

Create Work Item and Update Fields in Azure DevOps

Now we have the field names we can create a work item and populate those fields. Note the date formats are YYYY-MM-DDThh:mm:ssZ.

When this flow is run, it creates an item and will successfully update fields in Azure DevOps.

The Update a work item action has exactly the same Other fields option so you can use the same technique.

Find Field Names v2

Azure DevOps can be accessed via a Rest API2 and this includes the list of fields available in a project. There is quite good documentation for this which can be found at https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/fields/list . From the first code block on that post remove the GET and populate your org and project names. Then in a browser navigate to that url and it will return lots of JSON showing the definition of all the fields.

1

https://dev.azure.com/{organization}/{project}/_apis/wit/fields

Then search for the fields you want and look for the referenceName and use that. As my project got complex I saved this data and then used Power Query to make a simple list of fields (perhaps a resource I should make public).

Conclusion on Update Fields in Azure DevOps

The Other Fields section in Create and Update work item actions gives us the option to update items however we want to. Some fields of course are read only and updating some fields will update other fields, for example if you change the state to Closed it will then populate the Closed date field.

Connecting Power Automate to DevOps

Thu, 25 Jul 2024 10:54:26 +0000

I know Azure DevOps from being on projects. Mostly for tracking tasks, sprints etc. I recently had to automate some item creation and editing across 1000s of tasks in DevOps. So I had to explore connecting Power Automate to DevOps for item creation and item editing. This is the first post I have in a long list of posts regarding DevOps with Power Automate and Power BI, welcome to my way of remembering how I did something.

DevOps with Power Automate posts

YouTube Version

DevOps Connector

While editing a flow if you add action and search for DevOps you will find the Azure DevOps connector. If you look at the actions in the classic format1 you will notice its a premium connector, i.e. you need a premium license. If you have not used this connector before it will prompt you to login. It assumes your DevOps login matches your Power Automate login.

Create an item

Let’s start with a simple action to create a work item in a project. We start by adding the action Create a work item.

The Organisation Name and the Project Name drop downs will contain the organisations and projects your login can see. (See further down about making this solution friendly). The Work Item Type drop down will contain all the types that the project allows from its process. The title is plain text and the Description is rich text, i.e. html.

When you test the flow you should get a work item created that matches the above.

Troubleshoot Connecting Power Automate to DevOps

If the flow fails with an error regarding authorisation, you need to first check you are allowed to add an item in that project in DevOps. Then you need to check the organisation settings in DevOps. Look in Policies and make sure Third-party application access via OAuth is turned on.

Advanced Options in Create an Item

The Create a work item action includes advanced options, really they are just optional options. Two of the options are Link URL and Link Type. In this example I used the URL from the previously created item and the Type of Hierarchy-reverse to make this item a child of the previous item.

Another option is the Assigned To field. I added my email so that when I look in the created item I see that it has been assigned to me.

The first option is Return all fields, which the default is blank. This means the action returns all the item details when it successfully creates the item.

Making it Solution Aware

If this flow is part of a solution that is going to move from a development environment to test and production, you will need to point the DevOps actions to the different Organisation and Project values. Thankfully the text values of the Organisation Name, e.g. HatFullOfData can be used.

So I create 2 environment variables DevOps Organisation and DevOps Project. Then in the create a work item action, in Organisation Name and Project Name drop downs I select Custom Value and then the right value from Dynamic content.

And yes of course after making these changes I test the flow again.

Conclusion on Connecting Power Automate to DevOps

For when you need to automate the creation of items, this is great. It does not replace importing an Excel file to create a whole plan but it does give an extra set of options to consider.

DevOps on Hat Full of Data

Inherited Value in a Parent Child Pattern

Power BI and DevOps Series

The Logic

Inherited Value DAX

Inherited Value Conclusion

References

More Power BI Posts

Power BI Series

DevOps Parent Child Hierarchy in Power BI

Power BI and DevOps Series

DAX Patterns – Parent Child Hierarchy

Adding the Path

Adding DevOps Hierarchy Level Columns

Adding a Matrix

Fixing the measures

Column Added to WorkItems table

2 Measures Added to WorkItems table

Get DevOps Data into Power BI

Power BI and DevOps Series

YouTube Version

Microsoft References for DevOps Data into Power BI

OData Queries

Simplest Query for Work Items

Selecting the columns

User and Calendar Table

Users

Calendar

Some Modelling

Relationships

Measures

Create Visuals

Conclusion on DevOps Data into Power BI

More Power BI Posts

Power BI Series

Editing Azure DevOps items in Excel

Add Excel Extension

Create a Tree Query

Connect to a DevOps Project

Adding a Server

Connecting to a project

Adding and Publishing DevOps items in Excel

Conclusion

DevOps with Power Automate posts

DevOps updates on behalf of another with Power Automate

DevOps with Power Automate posts

YouTube Version

Permission required to makes updates on behalf of another

Make Updates on behalf of another

Word of caution

Conclusion

More Power Automate Posts

Update DevOps without Notifications with Power Automate

DevOps with Power Automate posts

YouTube Version

Permissions for updates without notifications

Updating without Notifications

Item History

More Power Automate Posts

Running a Wiql DevOps query in Power Automate

DevOps with Power Automate posts

Writing the Query

Wiql Editor

Construct Query

Running the Wiql in Power Automate

Handling the Output of the HTTP call

Looping through workItemRelations

Conclusion

More Power Automate Posts

Using DevOps REST API in Power Automate

DevOps with Power Automate posts

YouTube Version

Get Task Details using DevOps REST API

Update a Work Item using DevOps REST API

Conclusion

More Power Automate Posts

Power Automate Update Fields in Azure DevOps

DevOps with Power Automate posts

YouTube Version

The Problem