Setting Up Routing Rules

Issue Manager relies on defined routing rules, the current state of each issue, and the corresponding state owners to determine the inboxes that issues are to be routed to during their life cycles. This sophisticated routing mechanism replaces what would otherwise be a tedious task for issue dispatchers.

The state of an issue is the current condition of the issue. A number of states are provided in the default workflow of Issue Manager. The state owner is the role in your organization that is responsible for acting on an issue in a given state.

The following are examples of issue states and owners from the default issue workflow:
Unreviewed
Someone needs to determine whether or not this issue is truly a bug or documentation error. Usually, this role is owned by a QA engineer.
Dev-Ready
Code is ready to be addressed. This role is typically owned by a developer.
QA-Ready
Someone needs to verify that the bug has actually been fixed. This role is usually owned by a QA engineer.

Different issues of the same type can enter the workflow in different states, depending on who submits them. The routing is affected accordingly. For example, an issue submitted by a developer enters the workflow in the Dev-Ready state, and is therefore routed to a developer's inbox. An issue submitted by a corporate user enters the workflow in the Unreviewed state, and is therefore routed to a QA engineer's inbox. The so-called initial issue state is assigned through group settings.

An issue moves from one state to the next in the workflow when a user takes action on that issue. For example, when a QA engineer confirms that a reported, unreviewed issue is indeed a bug, the issue moves from the Unreviewed state to the Dev-Ready state. The main goal of using routing logic here is to make sure that once the issue is judged to be a bug by the QA engineer, it moves from his or her inbox to the appropriate developer's inbox-without need for manual intervention.