> Amélioration continue des processus > Gestion des incidents > Jira Service Management > Modèle de données

Votre template de données pour la Gestion des incidents

Jira Service Management

Attributs de la Gestion des incidents (23) Activités de la Gestion des incidents (15) Guides d'extraction (4)

Votre template de données pour la Gestion des incidents

Ce modèle propose une méthode structurée pour recueillir les données essentielles à l’analyse de votre processus de gestion des incidents. Il précise les attributs importants à collecter et les activités clés à suivre, tout en fournissant des indications pratiques pour extraire ces informations de votre système source. Vous disposez ainsi de tous les éléments nécessaires pour commencer à optimiser vos flux de travail de résolution des incidents.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour Jira Service Management

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la Gestion des incidents

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser complètement votre processus de Gestion des incidents.

5 Obligatoire 6 Recommandé 12 Facultatif

	Nom	Description
	Activité ActivityName	Le nom de l’événement précis ou du changement de statut qui s’est produit pour l’incident.
Description L’activité représente une étape ou un événement distinct du cycle de vie de la gestion des incidents, comme « Incident créé », « Incident affecté » ou « Résolution proposée ». Ces éléments sont généralement déduits des transitions d’état ou d’événements de mise à jour précis enregistrés dans l’historique ou le journal des modifications de l’incident Jira. L’analyse de la séquence et de la durée de ces activités constitue l’objectif principal du Process Mining. Elle révèle le flux réel du processus, les goulots d’étranglement et les écarts. Pourquoi c’est important Les activités constituent la structure de base de la carte du processus et permettent de visualiser et d’analyser le cycle de vie des incidents. Où les obtenir Dérivée de l’historique et des données du journal des modifications du ticket Jira, cette activité enregistre les changements de statut et les mises à jour des champs essentiels. Exemples Incident affectéInvestigation commencéeIncident résolu
	Heure de début EventTimestamp	La date et l’heure exactes auxquelles l’activité s’est produite.
Description Cet attribut enregistre l’horodatage de chaque activité du cycle de vie de l’incident. Il est essentiel pour calculer les durées, les temps de cycle et les temps d’attente entre les différentes étapes du processus. Des horodatages précis permettent d’effectuer des analyses détaillées des performances, de suivre les SLA et d’identifier les goulots d’étranglement. Toutes les métriques de performance, comme le délai de résolution et la durée du diagnostic, sont calculées à partir de ces horodatages. Pourquoi c’est important Les horodatages sont essentiels pour calculer toutes les métriques fondées sur le temps, comprendre la durée des processus et détecter les goulots d’étranglement. Où les obtenir Il s’agit de la date « created » associée à chaque entrée du journal des modifications ou de l’historique de la demande Jira. Exemples 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Identifiant de l’incident IncidentId	L’identifiant unique de chaque ticket d’incident dans Jira Service Management.
Description L’identifiant de l’incident, souvent appelé Issue Key dans Jira, sert d’identifiant unique principal pour chaque incident signalé. Il relie toutes les activités, tous les commentaires et tous les changements de statut associés, de la création à la clôture définitive. Dans le Process Mining, cet identifiant est essentiel pour reconstituer le cycle de vie complet de chaque incident et analyser l’ensemble du processus. Pourquoi c’est important Il s’agit de l’identifiant central utilisé pour regrouper tous les événements associés dans un même cas. Il constitue donc la base de toute analyse de Process Mining. Où les obtenir Il s’agit du champ « Key » standard d’un ticket dans Jira Service Management, par exemple « ITSM-123 ». Exemples INC-10234HELPDESK-5678OPS-9901
	Dernière mise à jour des données LastDataUpdate	L’horodatage indiquant la dernière actualisation des données depuis le système source.
Description Cet attribut indique la dernière mise à jour du jeu de données. Il fournit un contexte important à toute personne qui analyse le processus, en lui permettant de connaître l’actualité des données. Cette information est particulièrement importante pour les Dashboards de suivi continu, qui nécessitent des données à jour pour prendre des décisions en temps utile. La valeur est généralement identique pour tous les événements d’un même lot d’extraction. Pourquoi c’est important Indique si les données sont récentes, un élément essentiel pour garantir la pertinence et la précision de l’analyse. Où les obtenir Il s’agit de l’horodatage de l’exécution de l’extraction des données, ajouté lors de la transformation des données. Exemples 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Système source SourceSystem	Le système depuis lequel les données ont été extraites.
Description Cet attribut identifie l’origine des données, qui est ici Jira Service Management. Il est particulièrement utile dans les environnements où les données provenant de plusieurs systèmes sont combinées afin d’obtenir une vue globale du processus. La spécification du système source garantit la traçabilité des données et facilite le diagnostic des problèmes de qualité ou d’extraction. Pour ce modèle, la valeur serait statique. Pourquoi c’est important Fournit le contexte essentiel sur l’origine des données et garantit leur clarté ainsi que leur traçabilité, notamment lors d’analyses portant sur plusieurs systèmes. Où les obtenir Il s’agit d’une valeur statique qui doit être ajoutée lors de l’extraction des données. Exemples Jira Service ManagementJira Cloud
	Date de création CreatedDate	La date et l’heure auxquelles l’incident a été créé pour la première fois dans le système.
Description Cet attribut marque le début officiel du cycle de vie de l’incident. Il constitue l’horodatage de référence à partir duquel sont calculées les mesures globales, comme le délai total de résolution. La date de création est une valeur statique pour chaque incident et sert de point de départ à l’ensemble de l’analyse de Process Mining du cas. Pourquoi c’est important Sert de point de départ à tous les calculs de durée de cycle de bout en bout et aux mesures de SLA. Où les obtenir Le champ Jira standard « Created » d’une demande. Exemples 2023-10-26T09:58:12Z2023-11-01T15:20:05Z
	Date de résolution ResolutionDate	La date et l’heure auxquelles l’incident a été marqué comme résolu.
Description Cet attribut enregistre l’horodatage auquel l’incident est passé pour la première fois dans un statut résolu. Il marque la fin de la phase de traitement actif et constitue le point final du calcul du délai de résolution. La comparaison entre la date de résolution et la date de création fournit la principale mesure de l’efficacité du processus. Elle joue également un rôle important dans l’évaluation de la conformité aux SLA. Pourquoi c’est important Marque la fin du processus de résolution et permet de calculer la durée totale du cycle ainsi que la performance des SLA. Où les obtenir Le champ Jira standard « Resolved » d’une demande. Exemples 2023-10-28T11:20:30Z2023-11-02T10:00:00Z
	Groupe d’affectation AssignmentGroup	L’équipe ou le groupe chargé de traiter l’incident.
Description Le groupe d’affectation représente l’équipe chargée de l’incident. Il peut s’agir d’un niveau d’assistance tel que « L1 Helpdesk », d’une équipe spécialisée comme « Network Operations » ou d’une équipe de développement. L’analyse des transitions entre les groupes d’affectation est essentielle pour comprendre les escalades et les transferts du processus. Elle permet de mesurer les performances des équipes, d’identifier les goulots d’étranglement à leur niveau et d’analyser les dépendances entre équipes. Pourquoi c’est important Essentiel pour analyser la performance des équipes, le débit de traitement et la circulation du travail entre les différents niveaux de support ou groupes spécialisés. Où les obtenir Ce champ est souvent configuré comme champ personnalisé dans Jira, par exemple « Team » ou « Assignment Group ». Il peut parfois être déduit des composants Jira ou des rôles de projet. Exemples Support niveau 1Équipe infrastructureAdministrateurs de bases de données
	Priorité Priority	Le niveau de priorité attribué à l’incident, qui indique l’urgence de sa résolution.
Description La priorité détermine la rapidité requise pour traiter un incident. Elle combine souvent l’impact et l’urgence, et influence directement les objectifs de SLA. L’analyse des incidents par priorité permet de vérifier si les incidents prioritaires sont traités plus rapidement que les autres et si la priorisation est appliquée de manière cohérente. Il s’agit d’une dimension essentielle pour filtrer et comparer la performance des processus. Pourquoi c’est important Essentiel pour analyser la performance des SLA et vérifier que les ressources sont correctement affectées aux incidents les plus importants. Où les obtenir Le champ Jira standard « Priority » d’une demande. Exemples Très élevéeÉlevéeMoyenneFaible
	Responsable Assignee	L’utilisateur actuellement chargé de traiter l’incident.
Description Le responsable est l’agent ou l’utilisateur chargé de l’incident à un moment donné. Le suivi des changements de responsable est essentiel pour analyser les transferts, comprendre la répartition de la charge de travail et identifier les personnes intervenant dans certaines étapes du processus. Cet attribut permet de répondre aux questions relatives à la performance individuelle et à l’allocation des ressources au sein des équipes de support. Pourquoi c’est important Permet de suivre la charge de travail individuelle, d’identifier les goulots d’étranglement liés à certains agents et d’analyser l’impact des transferts sur le délai de résolution. Où les obtenir Le champ Jira standard « Assignee » d’une demande. Exemples John SmithEmily JonesServiceDeskAgent1
	Statut Status	L’étape actuelle de l’incident dans son cycle de vie.
Description Le champ d’état indique l’état actuel d’un incident dans le flux de travail défini, par exemple « Ouvert », « En cours », « En attente du client » ou « Résolu ». Les changements d’état constituent la principale source utilisée pour générer le journal d’activités du Process Mining. L’analyse du temps passé dans chaque état est fondamentale pour identifier les goulots d’étranglement et comprendre où les incidents restent le plus longtemps. Pourquoi c’est important Reflète directement l’avancement de l’incident et constitue la principale source d’identification des étapes du processus et des temps d’attente. Où les obtenir Le champ Jira standard « Status » d’une demande. Exemples En coursEn attente du clientRésoluFermé
	Catégorie de cause racine RootCauseCategory	La classification de la cause racine sous-jacente de l’incident.
Description Cet attribut décrit la raison fondamentale de l’incident, par exemple « Software Defect », « Hardware Failure » ou « User Error ». Il est généralement renseigné après investigation et est essentiel à une Gestion des problèmes efficace ainsi qu’à la prévention des incidents futurs. L’analyse des catégories de causes racines permet d’identifier les faiblesses systémiques et de hiérarchiser les initiatives d’amélioration. Un taux élevé de causes racines « Unknown » peut signaler la nécessité d’améliorer les processus d’investigation. Pourquoi c’est important Permet d’analyser les causes racines et de passer d’une approche réactive à une approche préventive en identifiant et en traitant l’origine des incidents. Où les obtenir Il s’agit presque toujours d’un champ personnalisé dans Jira. Son nom et ses options dépendent largement de la configuration propre à l’organisation. Exemples Erreur de configurationPanne réseauBug logiciel
	Composant Component	Le système, l’application ou la partie de l’infrastructure affectée par l’incident.
Description Les composants sont des sous-sections d’un projet Jira qui servent à regrouper les demandes en ensembles plus restreints, tels que « User Interface », « Database » ou « API ». L’analyse des incidents par composant permet de repérer les parties d’un système les plus sujettes aux problèmes. Ces informations sont utiles pour l’analyse des causes racines et peuvent orienter les efforts d’amélioration du service ou de réduction de la dette technique. Pourquoi c’est important Permet de filtrer et d’analyser les incidents selon le produit ou la zone du système concernée, afin d’identifier les points sensibles de l’environnement technologique. Où les obtenir Le champ Jira standard « Components » d’une demande. Exemples Service d'authentificationDashboard de reportingApplication mobile
	Déclarant Reporter	L’utilisateur qui a initialement créé ou signalé l’incident.
Description Le déclarant est la personne, souvent un utilisateur final, ou un autre système, qui a enregistré l’incident en premier. L’analyse des incidents par déclarant peut aider à identifier les utilisateurs ou services qui rencontrent fréquemment des problèmes. Elle peut également servir à comprendre les modes de communication, notamment lors de l’analyse d’activités telles que « Waiting for Customer » et « Customer Responded ». Pourquoi c’est important Permet d’analyser l’origine des incidents, d’identifier les tendances liées à certains utilisateurs ou services et de comprendre les délais dans les échanges avec les clients. Où les obtenir Le champ Jira standard « Reporter » d’une demande. Exemples Alice JohnsonBob Williamsmonitoring-tool@example.com
	Dépassement du SLA SlaBreach	Un indicateur précisant si le délai de résolution de l’incident a dépassé l’objectif du SLA.
Description Cet attribut booléen calculé indique si l’incident a dépassé son SLA « Time to Resolution ». Sa valeur est vraie lorsque « IncidentResolutionCycleTime » est supérieur à « TimeToResolutionTarget ». Cet indicateur simplifie l’analyse et la visualisation, et facilite le filtrage ainsi que l’agrégation nécessaires au calcul du KPI de taux de non-respect du SLA. Il constitue la principale mesure de résultat du Dashboard de suivi de la performance des SLA. Pourquoi c’est important Fournit un résultat binaire clair sur la performance des SLA et simplifie le calcul des taux de dépassement ainsi que l’identification des problèmes. Où les obtenir Calculé comme suit : (« IncidentResolutionCycleTime » > « TimeToResolutionTarget »). Exemples truefalse
	Gravité Severity	La mesure de l’impact de l’incident sur l’activité.
Description La gravité définit l’ampleur de l’impact d’un incident sur l’activité, depuis l’affectation d’un seul utilisateur jusqu’à l’interruption d’un système essentiel. Alors que la priorité détermine l’ordre de traitement, la gravité indique l’impact global sur l’activité. L’analyse par niveau de gravité permet d’évaluer la performance du processus pour les incidents les plus importants pour l’organisation. Elle est souvent combinée à la priorité afin d’obtenir une analyse plus précise. Pourquoi c’est important Fournit une vue de l’impact sur l’activité et permet de concentrer l’analyse sur les incidents les plus préjudiciables aux opérations. Où les obtenir Il s’agit généralement d’un champ personnalisé dans Jira, car ce n’est pas un champ système standard. Consultez la configuration du projet Jira Service Management. Exemples CritiqueMajeureMineureNégligeable
	ID du problème associé LinkedProblemId	L’identifiant d’un ticket Problem associé à cet incident.
Description Les incidents qui sont les symptômes d’un problème sous-jacent plus vaste sont souvent associés à un ticket Problem. Ce champ contient l’ID du Problem correspondant. L’analyse de ces liens permet de comprendre la relation entre incidents et problèmes, de mesurer l’efficacité du processus de Gestion des problèmes et d’identifier les incidents récurrents qui nécessitent une correction définitive. Pourquoi c’est important Relie les incidents aux problèmes sous-jacents et permet d’analyser l’efficacité avec laquelle l’organisation traite les causes racines afin de prévenir de futurs incidents. Où les obtenir Ces informations sont stockées dans la section « Issue Links » d’une demande Jira. Exemples PROB-123PROB-456Aucun
	Indicateur de reprise IsRework	Un indicateur précisant si l’incident a fait l’objet d’une reprise, par exemple s’il a été rouvert.
Description Cet attribut booléen calculé identifie les incidents renvoyés à une étape précédente du processus, le plus souvent après avoir été rouverts une fois résolus. Les boucles de reprise constituent une source importante d’inefficacité et d’insatisfaction client. Cet indicateur permet de quantifier facilement le taux de reprise et de concentrer l’analyse sur les raisons pour lesquelles les incidents ne sont pas correctement résolus dès la première intervention. Pourquoi c’est important Met en évidence les problèmes de qualité et les inefficacités du processus en signalant les incidents qui nécessitent un travail répété, ce qui facilite directement l’analyse des reprises. Où les obtenir Calculé en détectant des séquences précises de changements de statut dans le journal d’événements, telles que « Resolved » -> « Reopened ». Exemples truefalse
	Nombre de transferts HandoffCount	Le nombre de fois où l’incident a été réaffecté à un autre groupe ou utilisateur.
Description Cette mesure calculée compte le nombre de changements des champs « Assignee » ou « AssignmentGroup » au cours du cycle de vie de l’incident. Un nombre élevé de transferts révèle souvent une inefficacité du processus, l’absence de résolution au premier contact ou des lacunes en matière de connaissances, ce qui entraîne des délais de résolution plus longs. L’analyse de ce KPI aide à optimiser le processus d’affectation et à améliorer la collaboration entre les équipes. Pourquoi c’est important Quantifie les frictions et les inefficacités du processus liées aux réaffectations et aide à identifier les possibilités d’amélioration. Où les obtenir Calculé en comptant le nombre de changements apportés au champ « Assignee » ou « AssignmentGroup » dans le journal des modifications de la demande. Exemples 015
	Objectif de délai de résolution TimeToResolutionTarget	La durée cible du SLA pour résoudre l’incident.
Description Cet attribut définit le délai maximal attendu pour résoudre un incident d’une priorité ou d’un type donné. Il sert de référence pour comparer le délai de résolution réel et déterminer la conformité au SLA. Cette valeur est généralement définie dynamiquement selon des règles prenant en compte des facteurs tels que la priorité, la gravité ou le type de demande. Elle est fondamentale pour tout Dashboard de suivi de la performance des SLA. Pourquoi c’est important Fournit la référence nécessaire pour mesurer la conformité aux SLA et constitue la base du KPI de taux de non-respect du SLA des incidents. Où les obtenir Cette valeur est dérivée de la configuration des SLA dans Jira Service Management. L’objectif précis, par exemple « Time to resolution », doit être identifié. Exemples 4 h8 h3 j
	Résolution Resolution	Le résultat final ou le motif de résolution de l’incident.
Description Le champ Résolution explique pourquoi un incident a été placé dans un état résolu. Les résolutions courantes incluent « Fixed », « Duplicate », « Won’t Do » ou « Cannot Reproduce ». L’analyse de la répartition des types de résolution peut fournir des indications sur la qualité des signalements entrants et l’efficacité du processus de résolution. Par exemple, un nombre élevé de résolutions « Duplicate » peut révéler un problème lors de la création ou du triage des incidents. Pourquoi c’est important Apporte un contexte sur l’issue de l’incident, aide à catégoriser les résolutions et permet d’identifier les tendances dans la clôture des incidents. Où les obtenir Le champ Jira standard « Resolution » d’une demande. Ce champ est généralement renseigné lorsqu’une demande passe dans une catégorie de statut « Done ». Exemples TerminéCorrigéDoublonNe sera pas corrigé
	Type de demande IssueType	Le type de demande, par exemple Incident, Service Request ou Problem.
Description Jira utilise les types de demande pour distinguer les différentes catégories de tâches. Dans le contexte de la Gestion des incidents, le type principal est « Incident », mais d’autres types, comme « Sub-task », peuvent également être pertinents. Cet attribut est essentiel pour filtrer le jeu de données afin de ne conserver que les incidents et de garantir que l’analyse de Process Mining porte sur le bon processus. Pourquoi c’est important Garantit que l’analyse porte bien sur les incidents et les distingue des autres types de travail, comme les demandes de service ou les changements. Où les obtenir Le champ Jira standard « Issue Type » d’une demande. Exemples IncidentAssistance informatiqueBug
	Type de demande client CustomerRequestType	Le type précis de demande soumise par le client via le portail de services.
Description Ce champ catégorise les demandes du point de vue du client, telles qu’elles sont présentées sur le portail Jira Service Management, par exemple « Report a system issue ». Il fournit une classification de l’incident compréhensible par l’utilisateur, qui peut différer du « Issue Type » interne. L’analyse de cet attribut peut apporter des indications sur la manière dont les clients perçoivent et signalent les problèmes, et contribuer à améliorer la conception du portail ainsi que l’offre de services. Pourquoi c’est important Fournit une vue des catégories d’incidents centrée sur le client, utile pour analyser la demande et améliorer l’expérience client. Où les obtenir Le champ « Customer Request Type », propre aux projets Jira Service Management. Exemples Obtenir de l'aide informatique > Signaler un problème systèmeE-mail > Demande d'accès

Obligatoire Recommandé Facultatif

Activités de la Gestion des incidents

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir et analyser précisément vos flux de travail de résolution des incidents.

7 Recommandé 8 Facultatif

	Activité	Description
	En attente du client	Marque le moment où l’équipe de support attend des informations ou une action de la part du client. Cet événement est déduit du passage à un statut d’attente dédié, tel que « Waiting for customer ».
Pourquoi c’est important Isoler cette période de mise en attente est essentiel pour mesurer précisément les SLA, car elle est souvent exclue du calcul du délai de résolution. Cela permet d’analyser les retards de réponse du client. Où les obtenir Cet événement est déduit de l’historique des changements de statut du ticket. Il correspond à l’horodatage du passage au statut « Waiting for customer » ou à un statut similaire. Collecte Identifiez l’horodatage du passage au statut « Waiting for customer ». Type d’événement inferred
	Incident clôturé	Représente la clôture administrative définitive du ticket d’incident après sa résolution et sa vérification. Cet événement est déduit du passage au statut « Closed ».
Pourquoi c’est important Il s’agit de l’événement final du processus. L’analyse du délai entre « Resolved » et « Closed » peut révéler des retards dans le nettoyage administratif ou dans les processus de confirmation par l’utilisateur. Où les obtenir Cet événement est déduit de l’historique des changements de statut du ticket. Il correspond à l’horodatage du passage à l’état final « Closed ». Collecte Identifiez l’horodatage du passage au statut « Closed ». Type d’événement inferred
	Incident créé	Marque le début officiel du cycle de vie de l’incident, lorsqu’un rapport d’incident est envoyé et qu’un nouveau ticket est créé dans Jira. Cet événement est explicitement enregistré lorsqu’un nouveau ticket de type « Incident » est saisi dans le système.
Pourquoi c’est important Il s’agit de l’événement de début principal du processus. L’analyse du délai entre cette activité et la résolution est fondamentale pour mesurer le temps de cycle global et le respect des SLA. Où les obtenir Il s’agit d’un événement explicite, enregistré à partir de l’horodatage « created » du ticket d’incident dans Jira. La création du ticket est consignée dans son historique. Collecte Utilisez l’horodatage de création du ticket. Type d’événement explicit
	Incident réaffecté	Se produit lorsqu’un incident est transféré d’un agent ou d’un groupe à un autre après l’affectation initiale. Cet événement est déduit de toute modification du champ « Assignee » ou « Assigned Group ».
Pourquoi c’est important Le suivi des réaffectations est essentiel pour analyser les transferts. Un nombre élevé de réaffectations révèle souvent des inefficacités de processus, des lacunes de connaissances ou un routage initial inadapté, ce qui entraîne des retards de résolution. Où les obtenir Cet événement est déduit de l’historique du ticket en détectant toute mise à jour du champ « Assignee » après son premier renseignement. Chaque modification constitue un événement de réaffectation. Collecte Identifiez les modifications ultérieures du champ « Assignee » après l’affectation initiale. Type d’événement inferred
	Incident résolu	Cette activité confirme que l’incident a été résolu avec succès et que le service est rétabli. Elle coïncide souvent avec le passage au statut « Resolved ».
Pourquoi c’est important Il s’agit de la principale étape de réussite du processus. La durée jusqu’à ce point constitue l’indicateur le plus couramment suivi : le délai de résolution, ou TTR. Où les obtenir Déduit du changement d’état vers « Résolu ». Dans de nombreux flux de travail, il s’agit du même événement que « Résolution proposée », qui représente le principal point de résolution. Collecte Identifiez l’horodatage du passage au statut « Resolved ». Type d’événement inferred
	Investigation commencée	Indique qu’un agent affecté a commencé à travailler activement au diagnostic de l’incident. Cet événement est généralement déduit lorsque le statut du ticket passe de « Open » ou « New » à « In Progress ».
Pourquoi c’est important Cette étape importante marque le début des efforts actifs de résolution. Mesurer le délai jusqu’à cette activité permet d’identifier les attentes initiales en file et les problèmes de disponibilité des ressources. Où les obtenir Cet événement est déduit de l’historique des changements de statut du ticket. Son horodatage correspond au passage à un statut indiquant un travail actif, tel que « In Progress ». Collecte Identifiez l’horodatage du passage au statut « In Progress ». Type d’événement inferred
	Résolution proposée	Cette activité indique qu’une résolution a été identifiée et mise en œuvre et que l’incident attend une confirmation ou une validation finale. Elle est déduite du passage au statut « Resolved ».
Pourquoi c’est important Il s’agit d’une étape importante qui marque la fin du travail actif de l’équipe de support. C’est souvent l’événement qui arrête le décompte du SLA. Où les obtenir Cet événement est déduit de l’historique des changements de statut du ticket. Son horodatage correspond au passage au statut « Resolved » ou à un statut équivalent. Collecte Identifiez l’horodatage du passage au statut « Resolved ». Type d’événement inferred
	Commentaire ajouté	Représente tout événement de communication ou de prise de notes au cours duquel un utilisateur ajoute un commentaire au ticket d’incident. Il s’agit d’un événement explicite, enregistré chaque fois qu’un commentaire est publié.
Pourquoi c’est important L’analyse de la fréquence des commentaires peut fournir des informations sur les habitudes de communication, l’efficacité de la collaboration et la complexité d’un incident. Elle peut mettre en évidence les incidents nécessitant un volume excessif de communications. Où les obtenir Il s’agit d’un événement explicite. Jira conserve chaque commentaire avec son horodatage et son auteur, accessibles dans l’historique des commentaires du ticket ou via l’API. Collecte Utilisez l’horodatage de chaque commentaire ajouté au ticket. Type d’événement explicit
	Incident affecté	Cette activité indique l’affectation initiale de l’incident à un agent ou à un groupe de support chargé de son traitement. Elle est enregistrée en suivant le premier renseignement du champ « Assignee » ou « Assigned Group ».
Pourquoi c’est important Mesure le délai de première réponse et d’affectation, qui constitue un élément important des indicateurs SLA. Il aide à identifier les retards avant le début de l’investigation active. Où les obtenir Cet événement est déduit de l’historique du ticket en identifiant la première modification du champ « Assignee » lorsque sa valeur précédente était « Unassigned ». Collecte Détectez la première mise à jour du champ « Assignee » dans l’historique du ticket. Type d’événement inferred
	Incident priorisé	Représente la définition de la priorité et/ou de la gravité de l’incident, qui détermine son niveau d’urgence et son impact métier. Cet événement est généralement déduit du premier renseignement ou de la première mise à jour des champs « Priority » ou « Severity » après la création.
Pourquoi c’est important Le suivi de la priorisation permet d’analyser si les incidents sont évalués rapidement et de manière cohérente. Les retards à cette étape peuvent avoir une incidence directe sur le calcul des SLA et l’affectation des ressources. Où les obtenir Cet événement est déduit de l’historique du ticket, qui enregistre les modifications apportées à tous les champs. Recherchez la première mise à jour du champ « Priority » ou d’un champ personnalisé « Severity » après la création du ticket. Collecte Détectez la première modification du champ « Priority » dans l’historique du ticket. Type d’événement inferred
	Incident rouvert	Représente une situation dans laquelle un incident précédemment résolu est réactivé parce que le problème s’est reproduit ou que la correction était inefficace. Cet événement est déduit du passage du statut « Resolved » ou « Closed » à un statut ouvert.
Pourquoi c’est important Les incidents rouverts mesurent directement la qualité de la résolution et constituent un indicateur majeur des reprises. Leur analyse permet d’identifier les clôtures prématurées et les solutions inefficaces. Où les obtenir Cet événement est déduit de l’historique des changements de statut du ticket. Il est enregistré lorsque le statut passe d’un état final tel que « Resolved » ou « Closed » à « Open » ou « In Progress ». Collecte Détectez le passage du statut « Resolved » ou « Closed » à un statut ouvert. Type d’événement inferred
	Lié à un ticket Problem	Se produit lorsqu’un incident est lié à un ticket « Problem » pour effectuer une analyse des causes profondes. Il s’agit d’un événement explicite, enregistré lorsqu’un lien « relates to » ou « caused by » est créé vers un ticket de type « Problem ».
Pourquoi c’est important Le suivi de ce lien est essentiel pour comprendre dans quelle mesure l’organisation passe efficacement de l’atténuation de l’incident à l’analyse et à la prévention des causes profondes. Où les obtenir Il s’agit d’un événement explicite enregistré dans l’historique des liens du ticket. Chaque création de lien comporte un horodatage et peut être filtrée pour identifier les liens vers des tickets de type « Problem ». Collecte Utilisez l’horodatage de création d’un lien vers un ticket de type « Problem ». Type d’événement explicit
	Réponse du client reçue	Indique que le client a fourni les informations demandées et que l’incident peut reprendre son cours. Cet événement est déduit lorsque le statut quitte « Waiting for customer » pour revenir à un statut actif.
Pourquoi c’est important Cette activité marque la fin du délai imputable au client. L’analyse de la durée entre « Waiting For Customer » et cet événement révèle le délai moyen de réponse du client. Où les obtenir Cet événement est déduit de l’historique des changements de statut du ticket. Il se produit lorsque le statut passe de « Waiting for customer » à un statut tel que « In Progress », souvent après l’ajout d’un commentaire par le client. Collecte Détectez le passage du statut « Waiting for customer » à « In Progress ». Type d’événement inferred
	Solution temporaire fournie	Représente la mise en œuvre d’une correction temporaire permettant de rétablir le service pendant l’élaboration d’une solution définitive. Cet événement peut être déduit d’un changement de statut ou d’un commentaire spécifique.
Pourquoi c’est important Mesurer le délai nécessaire pour fournir une solution temporaire est un indicateur important de la rapidité de rétablissement du service. Cela permet de distinguer l’atténuation temporaire de la résolution définitive. Où les obtenir Cet événement est souvent déduit. Il peut correspondre au passage au statut « Workaround Provided » ou à l’ajout d’un commentaire public contenant des mots-clés tels que « workaround ». Collecte Identifiez un changement de statut précis ou un mot-clé dans un commentaire. Type d’événement inferred
	Transféré à une équipe spécialisée	Indique que l’incident a été transmis à une équipe spécialisée, par exemple le niveau 2 ou l’équipe de développement, pour bénéficier d’un support avancé. Cet événement est déduit d’une modification du champ personnalisé « Support Team » ou d’une réaffectation spécifique.
Pourquoi c’est important Met en évidence les incidents qui nécessitent des connaissances spécialisées et suit les transferts entre les différents niveaux d’assistance. Vous pouvez ainsi identifier les goulots d’étranglement au sein des équipes spécialisées et analyser les schémas d’escalade. Où les obtenir Cet événement est déduit de l’historique du ticket en suivant les modifications d’un champ personnalisé représentant l’équipe affectée ou en identifiant une modification du champ « Assignee » vers un membre d’un groupe de spécialistes connu. Collecte Détectez une modification du champ personnalisé « Assigned Team » ou des changements spécifiques d’agent affecté. Type d’événement inferred

Recommandé Facultatif

Guides d'extraction

Comment récupérer vos données depuis Jira Service Management

Étapes

Vérifier les prérequis : cette méthode nécessite une application de la Marketplace Jira, telle que 'Better Excel Exporter' ou 'Exporter for Jira', car l'export CSV standard intégré n'inclut pas l'historique détaillé des tickets (changelog) nécessaire pour reconstituer la chronologie du processus. Vérifiez qu'une telle application est installée et que vous disposez des autorisations nécessaires pour l'utiliser.
Accéder à la recherche avancée des tickets : connectez-vous à votre instance Jira Service Management. Dans la barre de navigation supérieure, sélectionnez 'Filters', puis 'Advanced issue search'. L'Issue Navigator s'ouvre avec l'éditeur de requêtes JQL.
Exécuter la requête JQL : dans la barre de requête JQL, saisissez la requête fournie afin de sélectionner tous les tickets d'incident compris dans une période donnée. Cette sélection constituera la base de votre export de données brutes. Une requête type serait issuetype = Incident AND project = "[Your JSM Project Key]" AND created >= "-180d".
Configurer les colonnes d'export : repérez l'option d'export, qui peut être intitulée 'Export' ou se trouver dans un menu propre à l'application. Configurez l'export pour créer un fichier CSV. Il est essentiel d'inclure les champs suivants : Issue Key, Created, Resolved, Status, Priority, Assignee et, surtout, l'intégralité du Changelog ou de l'historique. Les applications d'export permettent souvent d'exporter chaque élément du changelog sur une ligne distincte, ce qui constitue le format idéal pour la transformation.
Exporter les données brutes : lancez l'export et téléchargez le fichier CSV obtenu. Ce fichier contiendra les données brutes, non transformées, probablement avec une ligne par modification de ticket plutôt qu'une ligne par ticket.
Préparer l'environnement de transformation : le script Python fourni est nécessaire pour transformer l'export brut en journal d'événements valide. Vérifiez que Python et la bibliothèque pandas sont installés sur votre système. Vous pouvez installer pandas en exécutant pip install pandas dans votre terminal.
Exécuter le script de transformation : enregistrez le script Python fourni dans un fichier, par exemple transform_jira_log.py. Placez le fichier CSV exporté dans le même répertoire. Modifiez le script afin d'indiquer les noms corrects des fichiers d'entrée et de sortie.
Lancer le script : exécutez le script depuis votre terminal à l'aide de la commande : python transform_jira_log.py. Le script traitera les données brutes et générera un nouveau fichier CSV nommé jira_incident_event_log.csv, correctement formaté pour le Process Mining.
Vérifier et importer : ouvrez le fichier final jira_incident_event_log.csv pour en valider le contenu. Une fois vérifié, ce journal d'événements peut être importé dans votre outil de Process Mining.

Configuration

Requête JQL : la requête JQL (Jira Query Language) constitue le filtre principal pour sélectionner les données. Les filtres essentiels sont les suivants :
- issuetype = Incident : garantit que seuls les tickets d'incident sont extraits.
- project = "[Your JSM Project Key]" : limite les données à un projet de Service Desk donné. Remplacez l'espace réservé par la clé de votre projet, par exemple 'ITSUP'.
- created >= "-180d" : définit la période d'extraction. Une période de 3 à 6 mois ('-90d' à '-180d') est recommandée pour équilibrer le volume de données et la qualité de l'analyse.
Configuration de l'application d'export : l'application d'export de la Marketplace doit être configurée pour produire le changelog. Le format idéal comporte une ligne par modification, avec des colonnes indiquant la clé du ticket, le champ modifié, l'ancienne valeur, la nouvelle valeur et l'horodatage de la modification.
Champs requis pour l'export : vérifiez que l'export inclut au minimum Issue Key, Created, Resolved, Creator, Priority, Status, Assignee, [Assignment Group Custom Field], [Support Team Custom Field] et l'historique complet du Changelog (horodatage, auteur, champ, from string, to string).
Prérequis : cette méthode nécessite une licence Jira Service Management, les autorisations permettant d'accéder à l'Issue Navigator et d'exécuter des requêtes JQL, ainsi qu'une application de la Marketplace Jira capable d'exporter les changelogs détaillés des tickets.

a Exemple de requête sql

import pandas as pd
import numpy as np
from datetime import datetime

# --- Configuration ---
# Specify the path to your raw CSV file exported from Jira
# This file should have one row per changelog item.
INPUT_CSV_PATH = '[Your-Jira-Export-File].csv'
# Specify the desired name for the final event log file
OUTPUT_CSV_PATH = 'jira_incident_event_log.csv'

# --- Main Transformation Logic ---
def transform_jira_to_event_log(input_path, output_path):
    """Transforms a detailed Jira changelog export into a process mining event log."""
    try:
        # Load the raw data, assuming common column names from Jira exporters.
        # Adjust column names here to match your specific export file.
        # 'Issue Key' -> Incident ID
        # 'Date' -> Timestamp of the change
        # 'Field' -> The field that was changed (e.g., 'status', 'assignee')
        # 'Original value' -> Old value
        # 'New value' -> New value
        # You must also include columns for 'Created', 'Resolved', 'Priority', etc., at the issue level.
        df_raw = pd.read_csv(input_path)
    except FileNotFoundError:
        print(f"Error: Input file not found at '{input_path}'. Please check the path.")
        return

    # Standardize column names for easier processing
    # Replace these with the actual column names from your export
    column_map = {
        'Issue key': 'IncidentId',
        'History Date': 'EventTimestamp',
        'History Author': 'Author',
        'Field': 'ChangedField',
        'From String': 'OldValue',
        'To String': 'NewValue',
        'Created': 'CreatedDate',
        'Resolved': 'ResolutionDate',
        'Priority': 'Priority',
        'Status': 'Status',
        'Assignee': 'Assignee',
        # Add mappings for your custom fields if necessary
        # '[Your Assignment Group Field]': 'AssignmentGroup'
    }
    df_raw.rename(columns=column_map, inplace=True)

    # Ensure timestamp columns are in datetime format
    df_raw['EventTimestamp'] = pd.to_datetime(df_raw['EventTimestamp'], errors='coerce')
    df_raw['CreatedDate'] = pd.to_datetime(df_raw['CreatedDate'], errors='coerce')
    df_raw['ResolutionDate'] = pd.to_datetime(df_raw['ResolutionDate'], errors='coerce')

    events = []
    # Group by incident to process each ticket's lifecycle
    for incident_id, group in df_raw.groupby('IncidentId'):
        # Sort changes chronologically
        group = group.sort_values(by='EventTimestamp').reset_index()

        # Get issue-level attributes from the first record
        first_record = group.iloc[0]
        created_date = first_record['CreatedDate']
        resolved_date = first_record['ResolutionDate']

        # 1. Incident Created Event
        events.append({
            'IncidentId': incident_id,
            'ActivityName': 'Incident Created',
            'EventTimestamp': created_date,
            'Assignee': first_record.get('Assignee'),
            'AssignmentGroup': first_record.get('AssignmentGroup'),
            'Status': first_record.get('Status'),
            'Priority': first_record.get('Priority')
        })

        assignee_set = False
        priority_set = False

        # 2. Process Changelog for other events
        for _, row in group.iterrows():
            activity = None
            field = row['ChangedField']
            old_val = str(row['OldValue'])
            new_val = str(row['NewValue'])
            timestamp = row['EventTimestamp']

            # Map changelog entries to activities
            if field == 'status':
                if new_val == 'In Progress' and old_val not in ['Waiting for customer', 'In Progress']:
                    activity = 'Investigation Started'
                elif new_val == 'Waiting for customer':
                    activity = 'Waiting For Customer'
                elif old_val == 'Waiting for customer' and new_val not in ['Resolved', 'Closed']:
                    activity = 'Customer Responded'
                elif new_val == 'Resolved':
                    activity = 'Resolution Proposed'
                    # Also add Incident Resolved at the same time
                    events.append({'IncidentId': incident_id, 'ActivityName': 'Incident Resolved', 'EventTimestamp': timestamp, 'Assignee': row.get('Assignee'), 'AssignmentGroup': row.get('AssignmentGroup'), 'Status': new_val, 'Priority': row.get('Priority')})
                elif new_val == 'Closed':
                    activity = 'Incident Closed'
                elif old_val in ['Resolved', 'Closed'] and new_val not in ['Resolved', 'Closed']:
                    activity = 'Incident Reopened'

            elif field == 'assignee':
                if not assignee_set and new_val != 'nan':
                    activity = 'Incident Assigned'
                    assignee_set = True
                elif assignee_set and new_val != old_val:
                    activity = 'Incident Reassigned'

            elif field == 'priority' and not priority_set:
                activity = 'Incident Prioritized'
                priority_set = True

            elif field == '[Support Team Custom Field]': # Placeholder for your escalation field
                activity = 'Escalated To Specialist Team'
            
            elif field == 'Link' and 'Problem' in new_val:
                 activity = 'Linked To Problem Ticket'

            # Other activities like 'Workaround Provided' and 'Comment Added' are not typically in the changelog
            # and would require different extraction methods (e.g., API calls for comments).

            if activity:
                events.append({
                    'IncidentId': incident_id,
                    'ActivityName': activity,
                    'EventTimestamp': timestamp,
                    'Assignee': row.get('Assignee'),
                    'AssignmentGroup': row.get('AssignmentGroup'),
                    'Status': new_val if field == 'status' else row.get('Status'),
                    'Priority': new_val if field == 'priority' else row.get('Priority')
                })

    # Create final event log DataFrame
    if not events:
        print("Warning: No events were generated. Check your input file and column mappings.")
        return
        
    df_events = pd.DataFrame(events)

    # Add required and recommended attributes
    df_events['SourceSystem'] = 'Jira Service Management'
    df_events['LastDataUpdate'] = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    
    # Merge issue-level details back to get created/resolved dates for all rows
    issue_details = df_raw[['IncidentId', 'CreatedDate', 'ResolutionDate']].drop_duplicates(subset='IncidentId')
    df_final = pd.merge(df_events, issue_details, on='IncidentId', how='left')

    # Calculate cycle time
    df_final['IncidentResolutionCycleTime'] = (df_final['ResolutionDate'] - df_final['CreatedDate']).dt.total_seconds() / 3600.0
    
    # Sort and write to CSV
    df_final = df_final.sort_values(by=['IncidentId', 'EventTimestamp'])
    df_final.to_csv(output_path, index=False)
    print(f"Successfully created event log at '{output_path}' with {len(df_final)} events.")

# --- Script Execution ---
if __name__ == '__main__':
    transform_jira_to_event_log(INPUT_CSV_PATH, OUTPUT_CSV_PATH)

Étapes

Prérequis et accès : obtenez un accès en lecture seule à la base de données Jira Service Management On-Premise. Vous aurez besoin de l'adresse et du port du serveur de base de données, du nom de la base, d'un nom d'utilisateur et d'un mot de passe. Vérifiez qu'un client SQL tel que DBeaver, SQL Developer ou un outil similaire est installé.
Comprendre le schéma Jira : familiarisez-vous avec les principales tables de la base Jira. Les tables utilisées pour cette extraction sont principalement jiraissue (données centrales des incidents), changegroup et changeitem (historique des tickets), jiraaction (commentaires), issuelink (liens vers d'autres tickets), project (filtrage par projet) et issuetype (filtrage des tickets de type 'Incident').
Identifier les identifiants des champs personnalisés : de nombreux attributs importants, comme 'Assignment Group', sont souvent des champs personnalisés dans Jira. Vous devez identifier leurs identifiants uniques en interrogeant la table customfield, par exemple SELECT id, cfname FROM customfield WHERE cfname LIKE '%Assignment Group%';. Notez ces identifiants pour les utiliser dans la requête principale.
Se connecter à la base de données : ouvrez votre client SQL et établissez une connexion à la base Jira à l'aide des identifiants de l'étape 1.
Personnaliser la requête SQL : copiez la requête SQL complète fournie ci-dessous. Vous devez remplacer les valeurs d'espace réservé pour les adapter à votre configuration Jira. Portez une attention particulière à [your_project_key], [start_date], [end_date] et aux identifiants des champs personnalisés tels que [custom_field_id_for_assignment_group].
Exécuter la requête : lancez la requête personnalisée dans votre client SQL. Selon la taille de votre instance Jira et la période sélectionnée, l'opération peut prendre plusieurs minutes.
Vérifier les résultats : une fois la requête terminée, examinez rapidement les résultats. Vérifiez que les colonnes IncidentId, ActivityName et EventTimestamp sont renseignées comme prévu. Assurez-vous que la colonne ActivityName contient différentes activités.
Exporter au format CSV : exportez l'ensemble des résultats depuis votre client SQL vers un fichier CSV. Choisissez l'encodage UTF-8 afin d'éviter les problèmes de caractères.
Formater pour ProcessMind : vérifiez que le fichier CSV comporte une ligne d'en-tête avec les noms de colonnes exacts indiqués dans la requête (IncidentId, ActivityName, etc.). Vérifiez que la colonne EventTimestamp utilise un format compatible avec ProcessMind, tel que YYYY-MM-DD HH:MI:SS.
Importer dans ProcessMind : le fichier CSV est maintenant prêt à être importé et utilisé pour créer une nouvelle analyse de processus dans ProcessMind.

Configuration

Identifiants de base de données : un utilisateur et un mot de passe de base de données en lecture seule sont nécessaires pour éviter toute modification accidentelle des données Jira.
Filtrage par projet et type de ticket : la requête est conçue pour être filtrée sur un ou plusieurs projets Jira Service Management précis via la clause p.pkey IN ('[your_project_key]'). Elle est également filtrée sur le type de ticket 'Incident' à l'aide de it.pname = 'Incident'. Ce filtrage est essentiel pour les performances et la pertinence des résultats.
Période : il est vivement recommandé de commencer par une période limitée, par exemple 3 à 6 mois de données, afin de garantir une exécution efficace de la requête. Adaptez les espaces réservés [start_date] et [end_date] en conséquence.
Champs personnalisés : des attributs tels que 'Assignment Group' ou 'Severity' peuvent être des champs personnalisés. La requête utilise des espaces réservés, par exemple [custom_field_id_for_assignment_group], que vous devez remplacer par les identifiants numériques corrects issus de la table customfield de votre instance Jira.
Version de Jira : le schéma de la base de données peut légèrement varier entre les versions majeures de Jira. Cette requête s'appuie sur une structure de schéma courante, mais peut nécessiter des ajustements mineurs pour les versions très anciennes ou très récentes de Jira Server ou Data Center.
Performances : l'exécution de cette requête sur une instance Jira volumineuse et active peut mobiliser une part importante des ressources de la base de données. Il est fortement recommandé de la lancer en dehors des heures de pointe afin de limiter son impact sur les utilisateurs Jira.

a Exemple de requête sql

WITH Incidents AS (
  SELECT
    i.id AS issue_id,
    p.pkey || '-' || i.issuenum AS IncidentId,
    i.assignee AS assignee_key,
    i.issuestatus AS status_id,
    i.priority AS priority_id,
    i.created AS CreatedDate,
    i.resolutiondate AS ResolutionDate,
    EXTRACT(EPOCH FROM (i.resolutiondate - i.created)) AS IncidentResolutionCycleTime
  FROM jiraissue i
  JOIN project p ON i.project = p.id
  JOIN issuetype it ON i.issuetype = it.id
  WHERE it.pname = 'Incident'
    AND p.pkey IN ('[your_project_key]') -- E.g., 'ITSM', 'HELPDESK'
    AND i.created BETWEEN '[start_date]' AND '[end_date]' -- E.g., '2023-01-01' AND '2023-06-30'
)
-- 1. Incident Created
SELECT
  i.IncidentId,
  'Incident Created' AS ActivityName,
  i.CreatedDate AS EventTimestamp,
  'Jira Service Management' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  au.display_name AS Assignee,
  cfo.customvalue AS AssignmentGroup,
  s.pname AS Status,
  pr.pname AS Priority,
  i.CreatedDate,
  i.ResolutionDate,
  i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN app_user au ON i.assignee_key = au.user_key
LEFT JOIN issuestatus s ON i.status_id = s.id
LEFT JOIN priority pr ON i.priority_id = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group] -- Placeholder for Assignment Group custom field ID
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id

UNION ALL

-- 2. Incident Prioritized (First Time)
SELECT
  i.IncidentId, 'Incident Prioritized' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, T.Priority, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, au_cg.display_name AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status, ci.newstring AS Priority,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN app_user au_cg ON cg.author = au_cg.user_key
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.field = 'Priority'
) T ON i.issue_id = T.issueid AND T.rn = 1

UNION ALL

-- 3. Incident Assigned (First Time)
SELECT
  i.IncidentId, 'Incident Assigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn = 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 4. Investigation Started
SELECT
  i.IncidentId, 'Investigation Started' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Open', 'New') AND ci.newstring = 'In Progress'

UNION ALL

-- 5. Comment Added
SELECT
  i.IncidentId, 'Comment Added' AS ActivityName, ja.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM jiraaction ja
JOIN Incidents i ON ja.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ja.actiontype = 'comment'

UNION ALL

-- 6. Incident Reassigned
SELECT
  i.IncidentId, 'Incident Reassigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn > 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 7. Escalated To Specialist Team
SELECT
  i.IncidentId, 'Escalated To Specialist Team' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, ci.newstring, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
JOIN customfield cf ON cf.cfname = '[Support Team Custom Field Name]' -- Placeholder for custom field name, e.g., 'Support Team'
JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
WHERE ci.field = cf.id

UNION ALL

-- 8. Waiting For Customer
SELECT
  i.IncidentId, 'Waiting For Customer' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Waiting for Customer'

UNION ALL

-- 9. Customer Responded
SELECT
  i.IncidentId, 'Customer Responded' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring = 'Waiting for Customer'

UNION ALL

-- 10. Workaround Provided
SELECT
  i.IncidentId, 'Workaround Provided' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Workaround Provided' -- Assumes this status exists

UNION ALL

-- 11. Resolution Proposed & 14. Incident Resolved
SELECT
  i.IncidentId, 'Resolution Proposed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Resolved'

UNION ALL

-- Also capture Incident Resolved from the resolutiondate field for cases where history might be missed.
SELECT
  i.IncidentId, 'Incident Resolved' AS ActivityName, i.ResolutionDate AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE i.ResolutionDate IS NOT NULL

UNION ALL

-- 12. Linked To Problem Ticket
SELECT
  i.IncidentId, 'Linked To Problem Ticket' AS ActivityName, il.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM issuelink il
JOIN Incidents i ON il.source = i.issue_id
JOIN jiraissue linked_issue ON il.destination = linked_issue.id
JOIN issuetype linked_issuetype ON linked_issue.issuetype = linked_issuetype.id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE linked_issuetype.pname = 'Problem'

UNION ALL

-- 13. Incident Reopened
SELECT
  i.IncidentId, 'Incident Reopened' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Resolved', 'Closed') AND ci.newstring NOT IN ('Resolved', 'Closed')

UNION ALL

-- 15. Incident Closed
SELECT
  i.IncidentId, 'Incident Closed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Closed'

Étapes

Configurer l'environnement Python : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques nécessaires avec pip : pip install requests pandas python-dateutil.
Générer un jeton d'API Jira : connectez-vous à votre compte Jira. Accédez aux paramètres de votre profil, sélectionnez 'Security', puis 'Create and manage API tokens'. Créez un nouveau jeton et copiez-le dans un emplacement sécurisé. Ce jeton servira à l'authentification à la place du mot de passe.
Identifier les identifiants des champs personnalisés : de nombreux attributs Jira, comme 'Assignment Group' ou 'Severity', sont des champs personnalisés. Vous devez trouver leurs identifiants internes. Accédez à Jira Settings > Issues > Custom fields. Repérez le champ concerné et cliquez sur le menu '...' pour sélectionner 'View'. L'identifiant figure dans l'URL, par exemple customFieldId=10021. Notez ces identifiants.
Configurer le script Python : ouvrez le script Python fourni dans un éditeur de texte. Mettez à jour les variables d'espace réservé de la section ## CONFIGURATION ## avec l'URL de votre site Jira, votre adresse e-mail, le jeton d'API généré et les identifiants des champs personnalisés que vous avez relevés.
Définir la requête JQL : modifiez la variable JQL_QUERY dans le script. Cette requête Jira Query Language (JQL) définit le périmètre des incidents à extraire. Commencez par un projet précis et une période limitée pour effectuer un test, par exemple : project = 'ITSM' AND issuetype = 'Incident' AND created >= '-90d'.
Lancer le script d'extraction : exécutez le script depuis la ligne de commande avec python your_script_name.py. Le script se connectera à l'API Jira, récupérera les données des incidents, traitera l'historique de chaque ticket et générera les événements.
Suivre la progression du script : le script affiche la progression dans la console, notamment le nombre de tickets traités. Pour les volumes importants, l'opération peut prendre beaucoup de temps en raison des limites de débit de l'API et du volume de données.
Vérifier le fichier de sortie : une fois le script terminé, il génère un fichier nommé jira_incident_event_log.csv dans le même répertoire. Ce fichier contient le journal d'événements extrait.
Transformer et formater les données : ouvrez le fichier CSV dans un tableur pour le vérifier. Le script calcule automatiquement IncidentResolutionCycleTime. Vérifiez que le format de date de EventTimestamp est cohérent et compatible avec les exigences de ProcessMind, par exemple YYYY-MM-DDTHH:MI:SSZ.
Importer dans ProcessMind : le fichier CSV généré est prêt à être importé dans ProcessMind. Associez les colonnes du fichier CSV aux attributs correspondants dans ProcessMind : IncidentId à Case ID, ActivityName à Activity et EventTimestamp à Timestamp.

Configuration

URL Jira : l’URL de base de votre instance Jira, par exemple https://your-company.atlassian.net.
Identifiants Jira : une adresse e-mail et un jeton d’API Jira sont nécessaires pour l’authentification. N’utilisez pas directement votre mot de passe dans le script.
Requête JQL : la requête JQL est le paramètre le plus important pour définir le périmètre des données. Il est vivement recommandé de filtrer avec issuetype = 'Incident' et de sélectionner un projet précis. Utilisez un filtre de période sur le champ created, par exemple created >= '-180d', afin de maîtriser le volume de données. Une période de trois à six mois est généralement adaptée pour une première analyse.
Identifiants des champs personnalisés : le script nécessite les identifiants précis des champs personnalisés utilisés dans votre instance Jira, tels que ASSIGNMENT_GROUP_FIELD_ID. Ils doivent être correctement configurés pour que les attributs correspondants soient renseignés.
Noms des états : le script déduit les activités à partir des transitions d’état. Vous devez mettre à jour les noms d’état dans le script, par exemple 'In Progress', 'Waiting for customer' et 'Resolved', afin qu’ils correspondent exactement aux noms utilisés dans le flux de travail de votre projet.
Paramètres de pagination : le paramètre maxResults de l’appel d’API détermine le nombre d’incidents récupérés par requête. Le script gère automatiquement la pagination, mais une valeur plus faible peut réduire la sollicitation de l’API si vous rencontrez des limites de débit.

a Exemple de requête python

import requests
import pandas as pd
import os
from datetime import datetime, timezone
from dateutil.parser import parse

class=class="hl-string">"hl-comment">## CONFIGURATION ##
class=class="hl-string">"hl-comment"># Your Jira instance URL
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
class=class="hl-string">"hl-comment"># Your email address used for Jira login
JIRA_EMAIL = class="hl-string">"[your-email@company.com]"
class=class="hl-string">"hl-comment"># Your Jira API token. Store this securely, for example as an environment variable.
API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"[Your_Jira_API_Token]")

class=class="hl-string">"hl-comment"># JQL query to fetch incidents. It is recommended to limit the date range.
JQL_QUERY = class="hl-string">"issuetype = Incident AND project = '[YOUR_PROJECT_KEY]' AND created >= '-180d'"

class=class="hl-string">"hl-comment"># Custom field IDs for recommended attributes. Find these in your Jira settings.
class=class="hl-string">"hl-comment"># Example: class="hl-string">'customfield_10021'
ASSIGNMENT_GROUP_FIELD_ID = class="hl-string">"[customfield_id_for_assignment_group]"

class=class="hl-string">"hl-comment"># Status names as defined in your Jira workflow
STATUS_IN_PROGRESS = class="hl-string">'In Progress'
STATUS_WAITING_FOR_CUSTOMER = class="hl-string">'Waiting for customer'
STATUS_RESOLVED = class="hl-string">'Resolved'
STATUS_CLOSED = class="hl-string">'Closed'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

def get_field_value_from_changelog(item):
    class=class="hl-string">"hl-comment"># Helper to get the actual value, which can be in different keys
    return item.get(class="hl-string">'toString') or item.get(class="hl-string">'to') or class="hl-string">''

def get_field_from_changelog(item):
    return item.get(class="hl-string">'fromString') or item.get(class="hl-string">'from') or class="hl-string">''

def calculate_cycle_time(start_str, end_str):
    if not start_str or not end_str:
        return None
    try:
        start_dt = parse(start_str)
        end_dt = parse(end_str)
        duration_seconds = (end_dt - start_dt).total_seconds()
        return round(duration_seconds / 3600, 2) class=class="hl-string">"hl-comment"># Return cycle time in hours
    except (ValueError, TypeError):
        return None

def fetch_jira_issues(jql):
    class="hl-string">"""Fetches issues from Jira API, handling pagination."""
    auth = (JIRA_EMAIL, API_TOKEN)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    issues = []
    start_at = 0
    max_results = 50

    while True:
        api_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_url, headers=headers, params=params, auth=auth)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            issues.extend(data.get(class="hl-string">'issues', []))

            total = data.get(class="hl-string">'total', 0)
            start_at += len(data.get(class="hl-string">'issues', []))
            print(fclass="hl-string">"Fetched {start_at} of {total} issues...")

            if start_at >= total:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Jira: {e}")
            if e.response is not None:
                print(fclass="hl-string">"Response content: {e.response.text}")
            break

    return issues

def create_event_log(issues):
    class="hl-string">"""Processes issues and their changelogs to create a structured event log."""
    event_log = []
    last_data_update = datetime.now(timezone.utc).isoformat()

    for issue in issues:
        incident_id = issue[class="hl-string">'key']
        fields = issue[class="hl-string">'fields']
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        created_date = fields.get(class="hl-string">'created')
        resolution_date = fields.get(class="hl-string">'resolutiondate')
        cycle_time = calculate_cycle_time(created_date, resolution_date)

        class=class="hl-string">"hl-comment"># Track current state for attributes
        current_assignee = fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None
        current_status = fields.get(class="hl-string">'status', {}).get(class="hl-string">'name')
        current_priority = fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name') if fields.get(class="hl-string">'priority') else None
        current_assignment_group = fields.get(ASSIGNMENT_GROUP_FIELD_ID)

        class=class="hl-string">"hl-comment"># Base attributes for every event of this case
        base_event = {
            class="hl-string">'IncidentId': incident_id,
            class="hl-string">'SourceSystem': class="hl-string">'Jira Service Management',
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'CreatedDate': created_date,
            class="hl-string">'ResolutionDate': resolution_date,
            class="hl-string">'IncidentResolutionCycleTime': cycle_time
        }

        class=class="hl-string">"hl-comment"># 1. Incident Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Incident Created',
            class="hl-string">'EventTimestamp': created_date,
            class="hl-string">'Assignee': current_assignee,
            class="hl-string">'AssignmentGroup': current_assignment_group,
            class="hl-string">'Status': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'Priority': current_priority
        })

        class=class="hl-string">"hl-comment"># 2. Comments Added
        if fields.get(class="hl-string">'comment', {}).get(class="hl-string">'comments'):
            for comment in fields[class="hl-string">'comment'][class="hl-string">'comments']:
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': class="hl-string">'Comment Added',
                    class="hl-string">'EventTimestamp': comment[class="hl-string">'created'],
                    class="hl-string">'Assignee': current_assignee, class=class="hl-string">"hl-comment"># Note: Assignee at time of comment is not easily available
                    class="hl-string">'AssignmentGroup': current_assignment_group,
                    class="hl-string">'Status': current_status,
                    class="hl-string">'Priority': current_priority
                })

        class=class="hl-string">"hl-comment"># 3. Linked To Problem Ticket
        if fields.get(class="hl-string">'issuelinks'):
            for link in fields[class="hl-string">'issuelinks']:
                link_type = link.get(class="hl-string">'type', {}).get(class="hl-string">'name')
                if class="hl-string">'inwardIssue' in link and link.get(class="hl-string">'inwardIssue', {}).get(class="hl-string">'fields', {}).get(class="hl-string">'issuetype', {}).get(class="hl-string">'name') == class="hl-string">'Problem':
                     event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': class="hl-string">'Linked To Problem Ticket',
                        class="hl-string">'EventTimestamp': created_date, class=class="hl-string">"hl-comment"># Approximation: link creation time is not readily available
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

        class=class="hl-string">"hl-comment"># Process changelog for state changes
        first_assignment = True
        first_prioritization = True

        for history in sorted(changelog, key=lambda x: x[class="hl-string">'created']):
            event_timestamp = history[class="hl-string">'created']
            author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

            for item in history[class="hl-string">'items']:
                field = item.get(class="hl-string">'field', class="hl-string">'').lower()
                activity = None

                class=class="hl-string">"hl-comment"># Track attribute changes over time
                if field == class="hl-string">'assignee':
                    current_assignee = get_field_value_from_changelog(item)
                    if first_assignment and get_field_from_changelog(item) is None:
                        activity = class="hl-string">'Incident Assigned'
                        first_assignment = False
                    elif not first_assignment:
                        activity = class="hl-string">'Incident Reassigned'
                elif field == class="hl-string">'priority' and first_prioritization:
                    current_priority = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Incident Prioritized'
                    first_prioritization = False
                elif field == class="hl-string">'status':
                    from_status = item.get(class="hl-string">'fromString')
                    to_status = item.get(class="hl-string">'toString')
                    current_status = to_status
                    if to_status == STATUS_IN_PROGRESS:
                        activity = class="hl-string">'Investigation Started'
                    elif to_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Waiting For Customer'
                    elif from_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Customer Responded'
                    elif to_status == STATUS_RESOLVED:
                        class=class="hl-string">"hl-comment"># This can represent both Proposed and Resolved
                        event_log.append({
                            **base_event,
                            class="hl-string">'ActivityName': class="hl-string">'Resolution Proposed',
                            class="hl-string">'EventTimestamp': event_timestamp,
                            class="hl-string">'Assignee': current_assignee,
                            class="hl-string">'AssignmentGroup': current_assignment_group,
                            class="hl-string">'Status': to_status,
                            class="hl-string">'Priority': current_priority
                        })
                        activity = class="hl-string">'Incident Resolved'
                    elif to_status == STATUS_CLOSED:
                        activity = class="hl-string">'Incident Closed'
                    elif from_status in [STATUS_RESOLVED, STATUS_CLOSED] and to_status not in [STATUS_RESOLVED, STATUS_CLOSED]:
                         activity = class="hl-string">'Incident Reopened'
                elif item.get(class="hl-string">'fieldId') == ASSIGNMENT_GROUP_FIELD_ID:
                    current_assignment_group = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Escalated To Specialist Team'
                elif field == class="hl-string">'resolution' and item.get(class="hl-string">'toString') == class="hl-string">'Workaround provided':
                    class=class="hl-string">"hl-comment"># This is one way to capture class="hl-string">'Workaround Provided', highly dependent on configuration
                    activity = class="hl-string">'Workaround Provided'

                if activity:
                    event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': activity,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira incident data extraction...")
    issues_data = fetch_jira_issues(JQL_QUERY)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues to create event log...")
        event_log_data = create_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        class=class="hl-string">"hl-comment"># Sort by case and timestamp for a logical event log order
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        
        output_filename = class="hl-string">'jira_incident_event_log.csv'
        df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nExtraction complete. Event log saved to '{output_filename}'.")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

Étapes

Dans Jira Service Management, créez ou sélectionnez une règle d'automatisation pour le projet d'incidents. Utilisez un déclencheur de création de ticket pour les nouveaux tickets Incident et un déclencheur de mise à jour de ticket pour les modifications ultérieures. Configurez la règle pour le projet et le type de ticket concernés, en utilisant [Configure based on your system] pour définir précisément le projet et le type de ticket.
Configurez les conditions de la règle afin de ne traiter que les tickets d'incident. Incluez les mises à jour du statut, de la priorité, de la sévérité, de l'agent assigné, du groupe d'affectation, de l'équipe de support, des commentaires, de la résolution, des liens de tickets et des autres champs nécessaires pour identifier les activités listées ci-dessous.
Configurez l'action Webhook pour envoyer la charge utile complète du ticket au format JSON vers [Your webhook endpoint]. Incluez l'identifiant du ticket, son type, les horodatages, les champs actuels, le changelog ou les informations de modification des champs lorsqu'ils sont disponibles, les commentaires, les liens, le statut, l'agent assigné, le groupe d'affectation, la priorité, la sévérité, l'équipe de support, la date de création et la date de résolution. Utilisez la méthode d'authentification requise par le point de terminaison destinataire.
Configurez la règle pour envoyer une charge utile lors de la création du ticket et une charge utile pour chaque mise à jour répondant aux critères. Ne comptez pas sur ProcessMind pour déduire les activités à partir d'un instantané de l'état actuel du ticket. Le service destinataire doit conserver chaque charge utile Webhook et son horodatage d'événement afin de pouvoir produire chaque activité requise sous forme de ligne du journal d'événements.
Dans le service destinataire, validez la signature ou l'authentification du Webhook, stockez la charge utile JSON brute et enregistrez l'heure de réception du Webhook. Conservez séparément l'horodatage de l'événement Jira et celui de la réception. Dédupliquez les nouvelles tentatives à l'aide de l'identifiant du ticket Jira, de l'identifiant de l'événement Webhook lorsqu'il est disponible, de l'horodatage de l'événement et du hachage de la charge utile.
Transformez chaque charge utile selon le schéma du journal d'événements. Associez l'identifiant de l'incident à IncidentId, le libellé de l'activité à ActivityName, l'heure de l'événement source à EventTimestamp, Jira Service Management à SourceSystem et l'heure d'actualisation de l'extraction à LastDataUpdate. Renseignez également Assignee, AssignmentGroup, Status, Priority, CreatedDate et ResolutionDate lorsqu'ils sont disponibles.
Émettez Incident Created lorsqu'un nouveau ticket Incident est créé. Émettez Incident Prioritized lors du premier renseignement ou de la première mise à jour de Priority ou Severity. Émettez Incident Assigned lors du premier renseignement de Assignee ou Assignment Group. Émettez Investigation Started lorsque le statut passe de Open ou New à In Progress. Émettez Comment Added pour chaque commentaire publié.
Émettez Incident Reassigned lors des modifications ultérieures de Assignee ou Assignment Group. Émettez Escalated To Specialist Team lorsque Support Team est remplacé par une équipe spécialisée ou lorsque la condition de réaffectation spécialisée configurée est remplie. Émettez Waiting For Customer lorsque le statut passe au statut d'attente configuré. Émettez Customer Responded lorsque le ticket quitte ce statut d'attente pour un statut actif. Émettez Workaround Provided lorsque la condition configurée de statut ou de commentaire relatif à une solution de contournement est remplie.
Émettez Resolution Proposed lorsque le statut passe à Resolved. Émettez Linked To Problem Ticket lorsqu'un lien de ticket admissible est créé vers un ticket Problem. Émettez Incident Reopened lorsque le statut passe de Resolved ou Closed à un statut ouvert. Émettez Incident Resolved lorsque la confirmation de résolution configurée est reçue, généralement lors du passage à Resolved, et Incident Closed lorsque le statut passe à Closed. Si une même mise à jour source satisfait plusieurs règles d'activité, émettez des lignes distinctes avec le même horodatage source, sauf si la configuration métier distingue explicitement les horodatages.
Vérifiez l'ordre, les horodatages, les identifiants et les libellés d'activité, puis exportez un journal d'événements à plat au format CSV ou dans un autre format pris en charge par ProcessMind. Incluez une ligne par occurrence explicite d'activité, conservez les colonnes requises, utilisez un horodatage ISO 8601 cohérent avec le fuseau horaire et importez le fichier dans ProcessMind. Ne fournissez pas uniquement une table de tickets représentant leur état actuel, car ProcessMind lit le journal d'événements tel quel et ne reconstitue pas les événements manquants.

Configuration

Périmètre des déclencheurs : configurez les déclencheurs d'automatisation issue-created et issue-updated pour le projet Jira Service Management et le type de ticket Incident concernés. Utilisez [Configure based on your system] lorsque le projet, le type de ticket, le statut, le champ ou les identifiants de champs personnalisés diffèrent.
Destination du Webhook : définissez la destination sur [Your webhook endpoint]. Configurez l'authentification, TLS, le délai d'attente, les nouvelles tentatives et la validation de la signature selon les exigences du service destinataire.
Historique des modifications : incluez les détails du changelog ou des modifications de champs dans le traitement du Webhook. La représentation actuelle d'un ticket ne permet pas à elle seule d'identifier de manière fiable la première affectation, les réaffectations, les transitions de statut, les commentaires, les liens ou les réouvertures.
Règles d'activité : configurez des règles explicites pour les 15 activités suivantes : Incident Created, Incident Prioritized, Incident Assigned, Investigation Started, Comment Added, Incident Reassigned, Escalated To Specialist Team, Waiting For Customer, Customer Responded, Workaround Provided, Resolution Proposed, Linked To Problem Ticket, Incident Reopened, Incident Resolved et Incident Closed.
Colonnes de sortie requises : IncidentId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate doivent figurer sur chaque ligne. Les colonnes recommandées sont Assignee, AssignmentGroup, Status, Priority, CreatedDate et ResolutionDate.
Période : pour établir une base historique, traitez environ 3 à 6 mois d'historique conservé des tickets, puis poursuivez avec une ingestion en temps réel par Webhook. Sélectionnez une période couvrant des cycles complets de résolution des incidents et les réouvertures attendues.
Filtres : filtrez sur le projet Jira concerné, le type de ticket Incident et la période des incidents. N'appliquez des filtres sur l'entreprise, le service, l'équipe ou l'environnement que si ces valeurs sont disponibles et nécessaires au périmètre du processus. N'utilisez pas de filtres de base de données non pris en charge.
Gestion des horodatages : stockez les horodatages sources avec les informations de fuseau horaire. Utilisez l'heure réelle de la transition, du commentaire, du lien ou de la modification de champ pour EventTimestamp, et l'heure d'extraction ou d'actualisation pour LastDataUpdate.
Ordre et nouvelles tentatives : préservez autant que possible l'ordre source, puis triez les événements finaux par IncidentId et EventTimestamp, avec un critère de départage déterministe pour les horodatages identiques. Dédupliquez les nouvelles tentatives de Webhook sans supprimer les commentaires répétés légitimes ni les modifications admissibles répétées.
Performances : utilisez un traitement asynchrone des Webhooks, placez les charges utiles entrantes en file d'attente, regroupez la transformation et l'export, puis indexez IncidentId et EventTimestamp dans le système destinataire. Limitez la conservation des charges utiles et le remplissage historique au périmètre requis.
Prérequis : vous devez disposer des autorisations d'administration nécessaires pour créer et activer des règles d'automatisation Jira, des droits permettant de consulter les champs, commentaires, changelogs et liens de tickets des incidents, d'un accès au récepteur de Webhook et d'un mode d'import pris en charge par ProcessMind. Les fonctionnalités d'automatisation, d'API ou d'historique d'audit requises dépendent de l'édition et de la configuration de Jira.
Dépendances de configuration : définissez les valeurs exactes des équipes spécialisées, le statut d'attente, les statuts actifs, la condition de solution de contournement, le type de ticket Problem, les types de liens admissibles et la règle de confirmation de résolution avant d'activer l'extraction en production.

a Exemple de requête sql

WITH source_events AS (
    SELECT
        CAST(NULL AS VARCHAR(255)) AS IncidentId,
        CAST(NULL AS VARCHAR(255)) AS ActivityName,
        CAST(NULL AS TIMESTAMP) AS EventTimestamp,
        CAST(NULL AS VARCHAR(255)) AS SourceSystem,
        CAST(NULL AS TIMESTAMP) AS LastDataUpdate,
        CAST(NULL AS VARCHAR(255)) AS Assignee,
        CAST(NULL AS VARCHAR(255)) AS AssignmentGroup,
        CAST(NULL AS VARCHAR(255)) AS Status,
        CAST(NULL AS VARCHAR(255)) AS Priority,
        CAST(NULL AS TIMESTAMP) AS CreatedDate,
        CAST(NULL AS TIMESTAMP) AS ResolutionDate
    WHERE 1 = 0
), webhook_events AS (
    SELECT
        CAST([Your incident identifier expression] AS VARCHAR(255)) AS IncidentId,
        CAST([Your activity name expression] AS VARCHAR(255)) AS ActivityName,
        CAST([Your source event timestamp expression] AS TIMESTAMP) AS EventTimestamp,
        CAST('Jira Service Management' AS VARCHAR(255)) AS SourceSystem,
        CAST([Your extraction refresh timestamp expression] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Your assignee expression] AS VARCHAR(255)) AS Assignee,
        CAST([Your assignment group expression] AS VARCHAR(255)) AS AssignmentGroup,
        CAST([Your status expression] AS VARCHAR(255)) AS Status,
        CAST([Your priority expression] AS VARCHAR(255)) AS Priority,
        CAST([Your created date expression] AS TIMESTAMP) AS CreatedDate,
        CAST([Your resolution date expression] AS TIMESTAMP) AS ResolutionDate,
        CAST([Your issue type expression] AS VARCHAR(255)) AS IssueType,
        CAST([Your previous status expression] AS VARCHAR(255)) AS PreviousStatus,
        CAST([Your changed field expression] AS VARCHAR(255)) AS ChangedField,
        CAST([Your previous assignee expression] AS VARCHAR(255)) AS PreviousAssignee,
        CAST([Your previous assignment group expression] AS VARCHAR(255)) AS PreviousAssignmentGroup,
        CAST([Your support team expression] AS VARCHAR(255)) AS SupportTeam,
        CAST([Your previous support team expression] AS VARCHAR(255)) AS PreviousSupportTeam,
        CAST([Your comment identifier expression] AS VARCHAR(255)) AS CommentIdentifier,
        CAST([Your issue link type expression] AS VARCHAR(255)) AS IssueLinkType,
        CAST([Your linked issue type expression] AS VARCHAR(255)) AS LinkedIssueType,
        CAST([Your workaround condition expression] AS BOOLEAN) AS WorkaroundCondition,
        CAST([Your resolution confirmation expression] AS BOOLEAN) AS ResolutionConfirmation
    FROM [Your webhook event source]
    WHERE CAST([Your issue type expression] AS VARCHAR(255)) = 'Incident'
      AND CAST([Your source event timestamp expression] AS TIMESTAMP) >= CAST([Your start date parameter] AS TIMESTAMP)
      AND CAST([Your source event timestamp expression] AS TIMESTAMP) < CAST([Your end date parameter] AS TIMESTAMP)
      AND [Your company or scope filter expression]
), activity_events AS (
    SELECT IncidentId, 'Incident Created' AS ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Created'
    UNION ALL
    SELECT IncidentId, 'Incident Prioritized', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Prioritized'
       OR (ChangedField IN ('Priority', 'Severity') AND Priority IS NOT NULL)
    UNION ALL
    SELECT IncidentId, 'Incident Assigned', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Assigned'
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND (Assignee IS NOT NULL OR AssignmentGroup IS NOT NULL) AND PreviousAssignee IS NULL AND PreviousAssignmentGroup IS NULL)
    UNION ALL
    SELECT IncidentId, 'Investigation Started', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Investigation Started'
       OR (PreviousStatus IN ('Open', 'New') AND Status = 'In Progress')
    UNION ALL
    SELECT IncidentId, 'Comment Added', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Comment Added'
       OR (ChangedField = 'Comment' AND CommentIdentifier IS NOT NULL)
    UNION ALL
    SELECT IncidentId, 'Incident Reassigned', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Reassigned'
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND (PreviousAssignee IS NOT NULL OR PreviousAssignmentGroup IS NOT NULL))
    UNION ALL
    SELECT IncidentId, 'Escalated To Specialist Team', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Escalated To Specialist Team'
       OR (ChangedField = 'Support Team' AND SupportTeam IN ('[Your specialist team value]'))
       OR (ChangedField IN ('Assignee', 'Assigned Group') AND AssignmentGroup IN ('[Your specialist team value]'))
    UNION ALL
    SELECT IncidentId, 'Waiting For Customer', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Waiting For Customer'
       OR Status = '[Your waiting for customer status]'
    UNION ALL
    SELECT IncidentId, 'Customer Responded', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Customer Responded'
       OR (PreviousStatus = '[Your waiting for customer status]' AND Status <> '[Your waiting for customer status]')
    UNION ALL
    SELECT IncidentId, 'Workaround Provided', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Workaround Provided'
       OR WorkaroundCondition = TRUE
    UNION ALL
    SELECT IncidentId, 'Resolution Proposed', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Resolution Proposed'
       OR (PreviousStatus <> 'Resolved' AND Status = 'Resolved')
    UNION ALL
    SELECT IncidentId, 'Linked To Problem Ticket', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Linked To Problem Ticket'
       OR (IssueLinkType IN ('relates to', 'caused by') AND LinkedIssueType = 'Problem')
    UNION ALL
    SELECT IncidentId, 'Incident Reopened', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Reopened'
       OR (PreviousStatus IN ('Resolved', 'Closed') AND Status IN ('Open', 'New', 'Reopened', 'In Progress'))
    UNION ALL
    SELECT IncidentId, 'Incident Resolved', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Resolved'
       OR (ResolutionConfirmation = TRUE)
       OR (PreviousStatus <> 'Resolved' AND Status = 'Resolved')
    UNION ALL
    SELECT IncidentId, 'Incident Closed', EventTimestamp, SourceSystem, LastDataUpdate, Assignee, AssignmentGroup, Status, Priority, CreatedDate, ResolutionDate
    FROM webhook_events
    WHERE ActivityName = 'Incident Closed'
       OR (PreviousStatus <> 'Closed' AND Status = 'Closed')
)
SELECT
    IncidentId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    Assignee,
    AssignmentGroup,
    Status,
    Priority,
    CreatedDate,
    ResolutionDate
FROM activity_events
WHERE IncidentId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY IncidentId, EventTimestamp, ActivityName;

Prêt à commencer ?

Utilisez ce template de données pour transformer votre Gestion des incidents, repérer les inefficacités et réduire les délais de résolution. Commencez dès aujourd'hui à optimiser votre processus.

Retour au guide d’amélioration Télécharger le modèle

Optimisez la Gestion des incidents et résolvez-les plus rapidement

Réduisez le MTTR de 35 % et augmentez la satisfaction des utilisateurs grâce à des processus optimisés.

Démarrer l'essai gratuit

Aucune carte bancaire requise • Configuration en 5 minutes

Votre template de données pour la Gestion des incidents

Votre template de données pour la Gestion des incidents

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d'extraction

Export CSV de l'Issue Navigator de Jira Service Management

Étapes

Configuration

a Exemple de requête sql

Requête SQL directe sur la base de données Jira On-Premise

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API REST Jira pour l'extraction des données

Étapes

Configuration

a Exemple de requête python

Règle d'automatisation Jira avec Webhook pour une extraction en temps réel

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez la Gestion des incidents et résolvez-les plus rapidement

Votre template de données pour la Gestion des incidents

Votre template de données pour la Gestion des incidents

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d'extraction

Export CSV de l'Issue Navigator de Jira Service Management

Étapes

Configuration

a Exemple de requête sql

Requête SQL directe sur la base de données Jira On-Premise

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API REST Jira pour l'extraction des données

Étapes

Configuration

a Exemple de requête python

Règle d'automatisation Jira avec Webhook pour une extraction en temps réel

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez la Gestion des incidents et résolvez-les plus rapidement

Nous attachons de l’importance à votre confidentialité