A few month back, I wrote an article on leveraging Visual Studio Team Services (VSTS) in conjunction with SharePoint to manage defects that external users wish to share. The original article focused on leveraging Flow to create a defect in VSTS when a user submits a new defect in a SharePoint list. The flip side of the story is to inform the external user on changes in the status of the bug in VSTS, which is the purpose of this article.
VSTS Trigger
The workflow begins with a trigger from VSTS, which fires when an existing work item is updated
Make sure that the Type is set to Bug to limit the number of times that the workflow runs. The remainder of the workflow is based on the following five actions:
VSTS Authorization String
This action stores the authorization string identified in the previous article under the Create personal access tokens to authenticate access to VSTS and Convert Personal Access Token to Ba... actions. The same authorization string is used to both submit an items to VSTS as well are read an item that has been updated.
HTTP
The built-in VSTS Flow actions are good at retrieving information about a work item, but not all the fields. In my example, one of the fields I need is the bug priority, which is not returned. So, I've elected to use the HTTP action to request the VSTS information from work item.
Parse HTTP GET request
Next, the response from HTTP, which is in JSON format gets parsed using the third action so the various fields can be accessed independently.
Get Items
With the VSTS bug ID in hands, I can query for the specific SharePoint defect that is associated with the VSTS bug. Ideally, this should be a one-to-one relationship. Otherwise, you may be updating an incorrect item.
Update Item
Finally, I update the specific SharePoint list item fields based on the data in the VSTS work item.
Considerations
As mentioned in the How to Manage VSTS Bugs using Flow and SharePoint, Part 1: Creating A Defect article, one of the limitations of this approach is using the Personal Access Token as it expires after no more than a year of its creation.
Also, this article specifically deals with updating a SharePoint item when the VSTS work item changes. You can set up a different flow that is triggered when a SharePoint item changes and updates VSTS. But be cautious when you try to set up both of these update flows as they may start setting off each other and you run into an infinite loop.