Workflow d'évolution par défaut
La section suivante décrit le workflow d'évolution.
Les actions Modifier, Réassigner, Ajouter un Commentaire et Ajouter un Contournement ont été omises dans ce schéma.
- Les actions Modifier et Réassigner sont prédéfinies pour chaque état et ne peuvent pas être modifiées. Ces actions ne modifient pas l'état d'un incident.
- De même, l'action Ajouter un Commentaire, qui est définie pour tous les états dans ce workflow, ne modifie pas l'état d'un incident.
- L'action Ajouter un Contournement, définie pour tous les états à l'exception de Non Vérifié, n'affecte pas l'état.
Codes motif par défaut pour le workflow d'évolution
Pour afficher tous les codes motif fournis dans le workflow d'évolution par défaut, cliquez sur . Sélectionnez EVOLUTION comme type d'incident et consultez les actions et les codes motif valides qui y sont associés.
Exemple
Supposons qu'une demande d'évolution soit acceptée et envoyée au service Développement (Prêt pour Dév) par l'équipe de contrôleurs initiale (état Non Vérifié) ou par une équipe de gestion (état Appel Management). L'équipe de gestion reçoit la demande d'évolution si l'équipe de contrôleurs initiale choisit l'action Peut-être.
Si l'une ou l'autre de ces équipes rejette la demande d'évolution, l'incident est fermé avec l'état Rejeté. Cette action Rejeter diffère d'une action Rejeter effectuée sur un incident à l'état Prêt pour QA. Dans ce cas, l'action de développement (Implémenté, Ne peut pas être fait, Déjà Fait ou Marquer comme Dupliqué) est contestée.