Issue Manager gère un incident d'un bout à l'autre de son cycle de vie via un workflow piloté par des actions. La notion de workflow piloté par des actions fait référence au fait que l'incident est amené d'un état (condition) à un autre par les actions de l'utilisateur jusqu'à ce qu'il atteigne un stade terminal ou final.
Dans le workflow par défaut, une nouvelle anomalie signalée par le support technique du client est considérée comme étant à l'état Non Vérifié. Cette condition signifie que personne n'a confirmé que l'incident en question correspondait véritablement à une anomalie. Après évaluation de la situation, un ingénieur QA confirme que l'incident est une anomalie et qu'il est prêt à l'envoyer à un développeur pour correction. Dans cet exemple, considérez que l'état initial est Non Vérifié, que l'action à appliquer est Confirmer et que l'état suivant est Prêt pour Dév.
Si, par ailleurs, un incident identique a déjà été signalé, l'action à appliquer sur cet incident non vérifié est Marquer comme Dupliqué et le nouvel état sera probablement Fermé. Par conséquent, une action différente sur cet incident non vérifié envoie l'incident à un état différent, en l'occurrence, Fermé.
Il arrive parfois que les incidents conservent leur état en cours, même après qu'une action leur ait été appliquée. C'est le cas par exemple pour Ajouter un Commentaire, qui permet d'ajouter un commentaire à la description d'un incident existant.
Ces actions ne changent pas l'état en cours de l'incident, car elles ne le déplacent pas dans le workflow.
Un workflow définit un ensemble valide d'actions pouvant être appliquées à un état. Ces actions sont affichées sur la page Workflows. Les actions disponibles varient selon les paramètres Type d'Incident et État Actuel sélectionnés dans les listes.
Les actions sont disponibles sous forme de boutons à la page Détails de l'incident. Les boutons disponibles (actions) varient selon le type d'incident et l'état en cours.
Les informations d'état sont affichées partout dans Issue Manager. Par exemple, à chacun des comptes utilisateur et de groupe sont assignés trois états initiaux d'incident, un pour chaque type d'incident : anomalie, évolution et documentation.
L'état initial d'un incident dépend du niveau de connaissance que possède l'utilisateur sur le type d'incident qu'il signale. Par exemple, lorsqu'un membre de l'équipe de support technique signale un incident de documentation, cet incident est censé être correctement évalué et prêt à être corrigé. Il lui est donc assigné l'état initial Ouvert Documentation. Toutefois, lorsque la même personne soumet une anomalie logicielle, celle-ci n'est pas nécessairement considérée comme exacte. Son état de départ dans le workflow sera donc Non Vérifié. Différents groupes peuvent avoir des états initiaux différents pour le même type d'incident. Pour plus d'informations sur les états initiaux d'incident, reportez-vous à la rubrique « État initial d'incident ».
Lorsqu'un utilisateur enregistre un incident, Issue Manager assigne automatiquement à cet incident un état initial qui est fonction de l'état d'incident initial assigné à l'utilisateur. Lorsqu'un rédacteur technique consigne au journal un incident de documentation, la valeur du champ État de la page Détails de l'incident est Ouvert Documentation. Le champ État est un champ automatique, autrement dit ce n'est pas l'utilisateur mais Issue Manager qui le remplit en fonction des informations de workflow et autres.