Participate in Requirements Authoring Using Email Monitor
The Email Monitor feature provides access to creating Work Items in your Azure DevOps project through a medium that that is not native to Azure DevOps. That is, it allows you to communicate with your project via email. Teams often encounter situations where they are emailing about requirements, change request or bugs that should be created, and often they are able to use emails to drive towards a conclusive requirement that should be added into their project.
With the Email Monitor feature your team can now turn this external communication into a Work Item directly.
For use cases and the configuration process of Email Monitor, please watch the video.
You can access the configuration page of Email Monitor by going to the Collection/Admin settings – Modern Requirement4DevOps Extension – Services – Email Monitor.
By enabling the Email Monitor feature in the Modern Requirements4DevOps extension panel, you can specify a Monitor Email address that can intercept and create any work item that are emailed to it. Since the system will try to capture every email sent to the Monitor Email, it is a good idea to use your Monitor Email solely for the purpose the Email Monitor.
You are also required to provide an Admin Email address just in case when the system could not recognize the emails and a notification email will be sent to the Admin Email.
You can specify what WorkItem Types you want to create in your project from those captured emails.
Titles of the emails sent to the Monitor Email will always be mapped into the titles of Work Items to be created.
Team Project (Default) allows you to choose a default project where you want to add the Work Items to.
Add on Creation and Add on Update help you configure when you want to add the requirement to the project.
For the Description Field:
If the Add on Creation is checked, it means the system will use the initial email to create a new work item and the email body will become the description of the created Work Item.
If Add on Update is checked, it means the existing description of the created Work Item will be overridden by future replies regarding the same Work Item.
For the History Field：
If the Add on Creation is checked, it means the body of the initial email will be mapped to the Discussion section of the created work item.
If Add on Update is checked, then all back and forth replies regarding the same Work Item will be added to the Discussion section.
Sender Name, Sender Email, and Email Body allow you to set what content you want to add in associated Description or the Discussion section.
Use Case for Email Monitor Service
The most common use case for the Email Monitor feature is as follows:
I have a large organization and I would like all members of my organization to add any bugs they find in my software to my Azure DevOps project.
With Email Monitor fully configured with the bugs@myorganization.com, any relevant stakeholders can simply send an email to bugs@myorganization.com and I could specify that a Bug Work Item should be created in my project.
At the same time, the email that triggered the bug’s creation is also sent to the relevant people of that project. The relevant members can now participate in the discussion of that Work Item via email, and all email communications will be added to the Discussion properties of that Work Item within your project.
This unique feature allows people to contribute to your project’s success without needing to fully access your Azure DevOps project. External parties can now become part of the discussion about a Work Item, and does not require you to provide that person access to your project.
Some other scenarios you might be interested in
Adding Work Items to projects other than the default project
If sender does not specify a particular project name in the email body, the mapped email will be added to the default project. If senders want to add the requirement to another project under the same collection, they will need to include [ProjectName=GCD] in the email body (GCD is a sample project name).
Multiple Work Item Types
We understand that your project stakeholders might want to add more than one types of Work Items by using Email Monitor. This can be achieved too! You can simply select multiple WorkItem Types. For instance, now I select User Story in addition to Bug. When your team send emails to the monitor email box, they can use [WIT=bug] or [WIT=user story] in the email body to specify which Work Item type the created requirement should be. Without specifying the Work Item type in the email body, the system will try to map the email to the Work Item type which falls into the Work Item category you have selected in the WI Category section.
Adding extra content to an existing Work Item
After the initial email was captured by the system, by default, all future replies can be added as discussions of same Work Item. In addition to that, senders can add [wiid=1997] (1997 is a sample Work Item ID) in the email body to add new content to the targeted existing Work Item.
Of course, you can use more than one of those special commands in an email based on your needs.
