Issue Manager manages an issue through its entire life cycle through an action-driven workflow. Action-driven workflow means that an issue is driven from one state (condition) to another by user actions until the issue reaches a terminal, or ending state.
In the default workflow, a new bug reported by customer support is considered to be in an Unreviewed state, a condition that means that no one has confirmed that the "issue" is truly a bug. Assessing the situation, a QA engineer confirms that the issue is a bug and is ready to send it on to a developer to be fixed. In this example, think of the initial state as Unreviewed, the action to be taken as Confirm, and the next state as Dev-Ready.
If, on the other hand, an identical issue has already been entered, then the action to be taken upon this unreviewed issue is Mark as Duplicate and the next state will probably be Closed. Therefore a different action upon this unreviewed issue sends the issue to a different state, in this case, Closed.
Occasionally, issues retain their current state even after an action has been taken on them. This is true, for example, for Add Comment, which allows a user to add a comment to the description of an existing issue.
These actions do not change an issue's current state, because they do not move the issue through the workflow.
A workflow defines a valid set of actions that can be performed on a state. These actions can be viewed on the Workflows page. The available actions vary based on the Issue Type and Current State selected from the lists.
Actions are available on the Issue Details page in the form of buttons. The available buttons (actions) vary based on an issue's type and current state.
State information appears throughout Issue Manager. For example, each group and user account is assigned three initial issue states, one for each issue type: bug, enhancement, and documentation issue.
The initial state of an issue depends on how knowledgeable the user reporting the issue is with respect to this type of the issue. For example, when a member of the Technical Support group reports a documentation issue, it is assumed to be correctly assessed and ready for fixing, and is assigned an initial state of Open-Doc. However, when the same person submits a software bug, it is not necessarily assumed to be accurate, so its first state in the workflow is Unreviewed. Different groups can have different initial states for the same type of issue. For more information on initial issue states, see "Initial Issue State".
When a user saves an issue, Issue Manager automatically assigns the issue an initial state based on the initial issue state assigned to the user. When a technical writer logs a documentation issue the value of the State field on the Issue Details page is Open-Doc. The State field is an automatic field, meaning that Issue Manager, not the user, fills it in based on the workflow and other information.