Azure DevOps work item from O365 mail

Like many companies, we receive most of our support cases via email in a designated support mailbox. The processing and maintenance of these e-mail requests is an ongoing process. This also runs alongside our daily business. As a result, sometimes it happens that a support case is missed or forgotten about. That’s why we’re showing you today how to generate a work item from O365 mails in Azure DevOps.

Microsoft offers us some tools with its new Office 365 features. We started thinking about how these features could help us in our support process. Together, we agreed on MS Flow and Azure DevOps and decided to automate our support process.

As a result, no support cases are forgotten as mentioned at the beginning. We were able to use the two O365 features to automatically generate our incoming support cases as Azure DevOps work items from a mail.

This helps us in particular because the documentation effort of our employees is significantly reduced. The customer also receives quick feedback that the support case has arrived in our system and will be processed soon.

For this support process to work effectively and to generate an Azure DevOps work item from an O365 mail, you’ll also need to get the customer on board. It is important to explain the usefulness and procedure. The feedback is very positive and the collaboration has improved significantly. With the support of the customer and instructions from us, this process has been running smoothly for several weeks now.

Due to this new approach to generate an Azure DevOps Work Item from an O365 mail, we also have a much more efficient way in solving the support cases. With a proper creation in Azure DevOps, the sprint and development planning of support cases is much more effective. Response times to the customer also improved.

Here you can see what steps are needed to automate the support process in Flow.

For the flow to start, we use the trigger action “When a new email arrives (v3)” waiting for an incoming email in a defined O365 mailbox.

For parsing the information later on, we convert the content of the mail body from HTML to text. To do this, we use the Action Html to text.

In this step, we initialize all variables with the type String, which we will later use for assembling the bug description. We need this to generate the Azure DevOps work item. Which variables you use here depends entirely on your requirements and those of your customers. We have previously analyzed our current support process in detail. We then summarized the imperative information we need to handle the incoming support cases. These should include, among other things, a short description, the URL to the SharePoint web and the affected users. In addition, the subject area is to be restricted. If an error occurs that is known to have the Correlation ID, it can be listed as an option.

We also need variables for the work item ID, the work item title, the mail link, the mail ID and the subject for the reply mail.

This step is optional. You should adapt it to your needs. We set out to process only mails from certain senders automatically.

For our recording process, it is important that incoming mails have a specific predetermined structure that has been communicated with the customer. To do this, we create a query to see if the converted mail body meets these criteria.

The mail body must contain all the necessary information. If they exist, we can extract the data and save it to the previously created variables.

One of the information we need for the flow would be, for example,

[URL]: https://my.sharepoint.com
[Thema]: Support

To get the actual URL, we need to apply some string operations to the converted mail body.

1. Putting the index in front of the URL
   add(indexOf(body(‘Html_to_text’),’ [URL] :’),6)

2. Set a second index to the next specification
   indexOf(body(‘Html_to_text’),’ [Thema] ‘)

3. Extract the substring between : [URL] and [Thema] ”
   trim(substring(body(‘Html_to_text’),outputs(‘Index_1′),sub(outputs(Index_2’),outputs(‘Index_1’))))

4. We get in the variable the value of the specified url “https://my.sharepoint.com”

We then check the correctness of the data.

In this step, we first check whether the mail received is a follow-up mail for an existing work item or an initial mail. The corresponding work item ID is placed in front of the subject in the format < [ID > ]. This allows us to simply check in the subject whether the mail in question has already been processed by our system.

If the ID does not exist, we extract the title for our work item from the subject. Then we create a new work item of type Bug with the Action Create a work item. A reply e-mail is then written and sent with the Action Replay to email (v3) to all involved persons.

Order must be, so in this step we move the received mail from the inbox to the folder “Done”.

In Azure DevOps, it is currently not possible to attach files to a work item via a native action. That’s why we use the O365 possibilities. A link is generated via the message ID of the mail. This shows us the conversation in the Outlook web app. To do this, we assemble the link using the message ID of the moved mail as follows:

https://outlook.office.com/owa/?ItemID= < MessageID > &viewmodel=ReadMessageItem&path=&exvsurl=1

Using the extracted data in our variables, we can now populate the work item in Azure DevOps with the necessary information.

The flow is ready to use and an Azure DevOps work item is generated from an O365 mail! Here’s what the result in Azure DevOps looks like:

Want to learn more about Flow? Then read here how to start a conversation in a teams channel using Flow via a mail uploaded by Outlook.

If you have any further questions, please feel free to contact us!