Modern Requirements4DevOps (aka MR4TFS) Agent

javascript:;MR Agent is a module of Modern Requirements4DevOps (aka MR4TFS) (MR4DevOps (aka MR4TFS)) containing three components. It works as a framework that handles its components’ information centrally; it also handles the registration processes required on the server for the components. You can think of MR Agent as a background service that acts as an intermediary, managing all queries and transactions of these components betweenAzure DevOps Server server and MR4TS.


Custom ID


Customize new or existingAzure DevOps Server work item IDs

Simply configure Custom ID on the required collection and apply it to existing work items. The system will assign a customized ID in accordance with the configuration to all existing work items.

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 inAzure DevOps Server

Custom ID enables users to format their IDs according to the required standards of their organization. Customized ID is allotted to allAzure DevOps Server work items and is auto generated once configured.

Multiple configuration of Custom ID

Users can configure distinct IDs for different projects and teams so that each team can have its own customized ID. Similarly, a different format for different work item types is also enabled for configuration according to user need.

Dirty Flag


Identify modifications on UI

Dirty Flag adds a tag to the target work item so that users can have an extra step of visibility. Users can search all tagged work items to identify all modified work items. Rules can be applied to identify certain conditions including: Work item type, state, key properties, etc., and only work items fulfilling those rules will be tagged as ‘dirty’. Users can get more information through details in the Suspect tab of a work item or its details in the history field.

Clear status after review

Users who review a dirty flagged work item can clear its flag so that its indication flag could be removed. On clearing a flag from the work item, its associated tag is also removed automatically. Users can remove all flags at once instead of removing them one by one.


Keep track of modifications

Stakeholders can keep track of certain work items for modifications made on their associated items. Doing so helps ensure better handling of impacts.

Identify impacted requirements early and reduce development rework

Users are able to easily identify associated requirements that will be impacted by a change early in the definition process and schedule the work proactively. This eliminates surprises and costly rework downstream.

MR Mail


Register email addresses

Users can create a work item of any type for a discussion started on email. This can include initial requirements or a module description, etc. Alternatively, MR Mail enables users to start a new conversation onAzure DevOps Server through email; similarly, a discussion could be started on an existing work item ID.

Email-chain management

When sent, discussion or requirement details usually require a review or feedback, causing an email chain to start. MR Mail maintains this discussion inAzure DevOps Server in the history field of a work item so that replies on any discussion are also available on theAzure DevOps Server server for review and record.



Anyone can simply initiate a discussion or add new requirements by sending them to a registered email address along with the email addresses of other recipients. A reply from any group member on the same email would be managed by MR Mail in the same work item inAzure DevOps Server.

Admin notifications

MR Mail processes each incoming email according to the defined configuration. If it’s not matched or it encounters a problem, it won’t process it. Instead, it will send a failure notification to the admin and recipient. This ensures that the sender is also notified about the failure. It also gives the sender an opportunity to correct the mistake and resend it; similarly, admins (admins include all admin account configurations for such cases) are also notified about it.

Try Now