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
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
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?):
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).
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
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:
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
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:
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.
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:
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:
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
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 :).
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.
Erik van Hurck