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.
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:
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.
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.
Finally, I update the specific SharePoint list item fields based on the data in the VSTS work item.
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.