Custom ID

Customize New/Existing DevOps WorkItem IDs

Simply configure Custom ID on required collection and apply it to existing WorkItems. It will assign customized id as per the configuration to all existing WorkItems.

Auto Identification and Apply for New Projects

Custom ID could be configured on Collection with a feature of auto sync, which periodically checks for the new team project creation on configured collection. As soon as it identifies new Team Project is created it will apply Custom ID as per the configuration on it.

Follow Your Organization’s Standards in DevOps

Custom ID allows user to format their ids as per their required standards of organization. Customized id is allotted to all WorkItems of DevOps and is auto generated once configured.

Multiple Configuration of Custom ID

User can configure distinct ids for different projects and teams, so that each team has their own customized id for their items. Similarly different format for different WorkItem types are also allowed to configure as per the user need.

Dirty Flag

Clear Status After Review

User once review a dirty marked WorkItem(s) could clear its flag so that its indication flag could be removed. On clearing a flag from WorkItem, its associated tag is also removed automatically. User can also remove all flags instead of removing one by one.

Identify Modifications on UI

Dirty Flag adds a tag to the target WorkItem so that user can have an extra mile/step of visibility. User can search of all tagged WorkItems to identify all modified WorkItems and for further information can get their details in Suspect tab of WorkItem(s) or details in history field of it.

Get Comparison of WorkItem States

At any point of time, user can view all the changes made to source and target Work Item(s) from their state when defined condition is met and its current (latest) state in Azure DevOps.

Keep track of Modifications

Stakeholders can keep track for certain WorkItems for modifications made on their associated items so that impacts could be handled.

MR Mail

Register Email Addresses

User can create WorkItem of any type for a discussion started on Email, it could be initial requirements or description of module etc. Alternatively, MR Mail allows you to start a new conversation on Azure DevOpsthrough your email and similarly a discussion could be started on existing WorkItem ID.

Email-chain Management

Usually a discussion or requirement details when sent, a review on it or feedback is expected and thus a email chain is started for it. MR Mail maintains this discussion on Azure DevOps in history field of a WorkItem so that replies on any discussion are also available onAzure DevOps Server server for review and record.


Anyone could simply initiate a discussion or add new requirements by sending it to a registered email address along with other recipients. Reply from any group member on same email would be managed by MR Mail in same WorkItem in Azure DevOps.

Admin Notifications

MR Mail processes each incoming email according to the defined configuration. If it is not matched or it encountered any issue, it will not process and send failure notification to admin and recipient. So that sender is also notified about failure and would have chances to correct the mistake and resend it, similarly admin (admin means admin account configure for such cases) is also notified about it.

Try Now