Microsoft Roadmap Flow Deep Dive Part 2

This is the second part where I take a deep dive into the Microsoft Flow that is created in association with Microsoft Roadmap.

The previous post describes the Flow that is created when we link a Project from Project Online to the Roadmap. This post will continue with a close look at the Roadmap Flow that is created when linking with an Azure Board.

High level design

The Azure Boards Roadmap Flow that is created when connecting a Roadmap with Azure Boards.

Just like the Project Online connection this Microsoft Flow is created when linking a row within Roadmap to a back end system. The back end system this time is a Azure Board. Azure Boards are part of Azure DevOps which used to be called VSTS.

The Flow basically does the same thing as the Project Online Flow, where it has a recurring “wait until” action. after which there are parameters set. Then it will check if the items in Roadmap are still in Azure Board. If they aren’t the Flow will terminate, if they are the Flow will continue and try to update the Roadmap items based on the content from the Azure Board.

Taking a closer look

Azure Board, Flow, Roadmap Connection first part.

In this Flow there is a recurrence, but for Azure Boards it’s not every 5 minutes but once an hour. The Flow continues with 3 variables for the PortfolioId (remember, this is the Roadmap Id number), the OrganizationName which locates the CDS databare and the Azure DevOps account. After that there is a test to see if the PortfolioLinkId is still active (is there still a connection with Azure and Roadmap?):

{"and":[{"equals":["@body('Read_PortfolioLink_')?['refreshErrorCode']",4]}]}

If the test succeeds (there isn’t a link) the Flow follows the Yes path and Terminates. If the test is presented with a No the Flow continues (I’m still wrapping my head around the idea’s people can have when saying No means continue… I hope I’m not the only one here).

Azure Board Flow connection with Roadmap part 2 detail

The Flow continues with setting the RefreshStatus to “in Progress” (which is RefreshStatus “1”) . And it tries to retrieve the project from Azure DevOps by setting a variable and using the variable to connect to the Azure environment.

It this fails or times out, the right lane is chosen. If there is a project the left lane is used.

Taking the right lane

Azure Boards Flow connection with Roadmap detail of right lane.

This is an interesting section, because we now know that the rows in Roadmap are sometimes called “Scope rows”. I do mean sometimes because a Roadmap is still called a Portfolio in the Flow environment, so names are different in different tools at the moment.

In this section there is a double check with the test action:

{"and":[{"equals":["@body('Parse_failure_Azure_DevOps_Response')?['typeKey']","ProjectDoesNotExistException"]}]}

If this succeeds we have a ProjectDoesNotExistException in Azure DevOps. Making it clear that the issue isn’t a time out issue (which was still an option when we entered the right lane.

Once this test is completed the Roadmap is refreshed with a Refresh error code, which is either 1000 for a time out or 4 for a project that doesn’t exist anymore.

The RefreshStatus is now 3, meaning that the refresh failed. After this the Flow is terminated. Just like the Project Flow it states that the Flow is terminated successfully because the error wasn’t within Flow but it was within the connection between Roadmap and the Azure Board.

Continuing with the left lane

Azure Board Flow Connection with Microsoft Roadmap left lane.

At this point in the Flow things start to be very similar to the Project Online Flow connection. The Azure DevOps response is parsed and a new variable is set for the ProjectName. After that the list of RoadmapItemLinks is read into Flow and a BatchCount is created.

After that a new Selection is made gathering similar items as in the Project Online Flow: ExternalName, ExternalStartDate, ExternalDueDate, ExternalTaskId, RoadmapItemId and a Link Id.

Then an array is set up for each item that needs to be refreshed, a count variable is set and a RefreshStatus variable is updated.

This section finishes with a test:

{"and":[{"greater":["@variables('ArrayLength')",0]}]}

Very easy to read by now, because we know what to expect right? The test looks for the ArrayLength and as long as this is above 0 the Flow will continue updating RowItems in Roadmap.

Batch processing section of Azure Board Flow connection to Microsoft Roadmap.

Now, if you want me to provide you with another detailed description of what is included in the Process Batch section of the Flow I will disappointing you. But here’s the short version:

Detail of batch process Azure DevOps board with Flow and Roadmap.

The batch section starts with a “Do until” the array hits 0.

After that it gathers information, joins it updates information within the Flow. And only THEN will it perform the test:

{"and":[{"greater":["@length(body('Select_WorkItemIds_from_Azure_DevOps'))",0]}]}

Which basically means, is there still a Azure Board item that should be linked to this item?

Looks a bit strange to do all that work before actually checking if there’s something there right? On the other hand, this Flow is fast, just like the Project Online Flow. So I don’t think this is something that will create a performance issue.

Finishing the Flow

Finishing the Roadmap Flow with Azure Boards.

The Flow finishes with another fork. Where if the “any items” section fails or times out the left lane is taken. Providing another RefreshStatus 3 (which we now know is a Refresh Error). If however all items within the array are processed we now have a RefreshStatus 0 which means that it has been refreshed :).

Final Notes

That’s it for now, two deep dive posts about the new Roadmap feature. For me, I’m very excited because this is a new tool we can now look forward to using when a Program or Portfolio manager wants to have a high level overlook at the work that has been scheduled for his projects.

And better yet, it’s back end system “independent” where a project can be created in both Project Online and Azure Boards. With more systems coming if everything goes as planned.

Are you a Jira user for instance, you might want to know that there is a UserVoice item that you can vote on. And yes I still used roadmaps instead of the name “Roadmap” because at the time I started the item there was a bit confusion on what it would be called from my end.

And here’s another great suggestion by Jeff Spencer: Adding comments to Roadmap items. Would be great if a Portfolio / Program manager can add his own thoughts to “paper” in the Roadmap itself.

That’s it for now. Please keep in mind that there’s a Newsletter and a YouTube channel you can also follow along with me and my road through the PPM world.

Best wishes,

Erik van Hurck

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.