> Amélioration continue des processus > Gestion des incidents > Freshservice > Modèle de données

Votre modèle de données pour la gestion des incidents

Freshservice

Attributs de gestion des incidents(19) Activités de gestion des incidents(14) Guides d’extraction(3)

Votre modèle de données pour la gestion des incidents

Ce modèle vous aide à préparer les données nécessaires à l’analyse de la gestion des incidents. Il présente les attributs essentiels à recueillir, les activités importantes à suivre et des conseils pratiques pour extraire ces informations de votre système source. Utilisez cette ressource pour simplifier la préparation de vos données.

Attributs recommandés à recueillir
Activités clés à suivre
Conseils d’extraction

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de gestion des incidents

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus de gestion des incidents.

5 Obligatoire 7 Recommandé 7 Facultatif

	Nom	Description
	ID de l’incident IncidentId	Identifiant unique de chaque fiche d’incident, utilisé comme clé principale pour suivre l’ensemble de son cycle de vie.
Description L’ID de l’incident est au cœur de l’analyse de la gestion des incidents. Il sert d’ID de cas et relie toutes les activités, tous les horodatages et toutes les modifications d’attributs associés en un seul parcours cohérent. En Process Mining, chaque entrée du journal d’événements est associée à un ID d’incident, ce qui permet de reconstituer le déroulement complet du processus pour chaque incident. Cet identifiant est indispensable pour calculer les temps de cycle, analyser les variantes du processus et repérer les goulots d’étranglement propres à chaque cas. Sans identifiant unique, il serait impossible de distinguer les incidents et d’analyser leur parcours, du signalement à la résolution. Pourquoi est-ce important ? Il identifie chaque incident de manière unique et permet de suivre et d’analyser son cycle de vie complet, de sa création à sa clôture. Où trouver ces données Il s’agit de l’identifiant principal d’un ticket. Dans l’API Tickets de Freshservice, il est disponible dans l’objet ticket sous le champ « id ». Exemples INC-10234INC-10235INC-10236
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation ou extraction des données de ce processus.
Description Cet attribut indique la date et l’heure de la dernière mise à jour de l’ensemble des données depuis le système source. Il s’agit d’un champ de métadonnées qui concerne le jeu de données dans son ensemble, et non chaque événement, mais il est souvent repris au niveau des événements par souci de cohérence. En analyse, cette information permet de connaître l’actualité des données et la période couverte par les Dashboards et les KPI. Elle aide les utilisateurs à savoir si les analyses reposent sur des données récentes et à déterminer si les incidents les plus récents sont inclus. Pourquoi est-ce important ? Il renseigne les utilisateurs sur l’actualité des données et la période couverte par l’analyse. Où trouver ces données Il s’agit d’un horodatage de métadonnées généré lors de l’extraction des données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Horodatage de l’événement EventTimestamp	Date et heure exactes auxquelles l’activité ou l’événement s’est produit.
Description L’horodatage de l’événement, ou heure de début, indique le moment précis où une activité a eu lieu. Chaque activité du cycle de vie de l’incident, de sa création à sa clôture, est associée à un horodatage. Cet attribut est indispensable à toutes les analyses de Process Mining fondées sur le temps. Il sert à ordonner les événements chronologiquement, à calculer la durée entre les activités, à mesurer le temps de cycle total d’un cas et à analyser les temps d’attente. Il constitue la base des Dashboards qui suivent la performance du SLA, les délais de transfert et les délais globaux de résolution. Pourquoi est-ce important ? Il établit l’ordre chronologique des événements, indispensable pour calculer les durées, analyser les temps de cycle et comprendre la performance du processus. Où trouver ces données Il est déduit de différents champs d’horodatage de Freshservice, comme « created_at » et « updated_at », ainsi que des horodatages présents dans les conversations ou les journaux d’audit du ticket. Exemples 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Nom de l’activité ActivityName	Nom de l’activité métier ou de l’événement qui s’est produit à un moment donné du cycle de vie de l’incident.
Description Le nom de l’activité décrit une étape ou un événement du processus de gestion des incidents, par exemple « Incident Assigned to Group », « Status Changed to Pending » ou « Incident Resolved ». Ces activités sont déduites de l’évolution des données de l’incident. Cet attribut est fondamental en Process Mining, car il définit les nœuds de la carte de processus découverte. L’analyse de l’ordre et de la fréquence des activités permet aux organisations de visualiser le processus réel de résolution des incidents, de repérer les parcours fréquents, les écarts par rapport à la procédure standard et les boucles de reprise, comme les réaffectations répétées. Pourquoi est-ce important ? Il définit les étapes de la carte de processus et permet de visualiser et d’analyser le déroulement de la résolution des incidents, les goulots d’étranglement et les écarts. Où trouver ces données Cet attribut ne correspond pas à un champ direct de Freshservice. Il est déduit des changements apportés aux propriétés du ticket, comme le statut, la priorité, l’affectation à un agent ou à un groupe, ainsi que l’ajout de notes. Exemples Incident signaléIncident affecté à un groupeNote de résolution ajoutéeIncident résolu
	Système source SourceSystem	Système dont les données ont été extraites, généralement « Freshservice ».
Description Cet attribut indique l’origine des données. Dans ce contexte, sa valeur sera toujours « Freshservice », mais il est essentiel lorsque des données issues de plusieurs systèmes sont réunies pour obtenir une vue globale du processus. Inclure l’attribut du système source est une bonne pratique en matière de gouvernance et de traçabilité des données. Cela permet de connaître clairement leur provenance, ce qui facilite la validation et le débogage, et prépare l’extension du projet de Process Mining à d’autres systèmes de gestion des services ou d’exploitation. Pourquoi est-ce important ? Il assure la traçabilité et la gouvernance des données en indiquant clairement leur origine. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de la transformation des données (ETL) pour identifier le jeu de données. Exemples FreshserviceFreshservice-EUFreshservice-PROD
	Agent affecté AssignedAgent	Nom ou ID de l’agent d’assistance actuellement chargé de résoudre l’incident.
Description L’agent affecté désigne la personne du centre de services responsable de l’incident à un moment donné. Toute modification de cet attribut correspond à un transfert de responsabilité entre agents. Cet attribut est essentiel à l’analyse des performances. Il permet de créer des Dashboards qui suivent la charge de travail des agents, leur temps moyen de résolution et leur taux de résolution au premier contact. Il sert également à analyser les transferts entre agents, qui peuvent entraîner des délais et des pertes d’efficacité. Le suivi des affectations aide les responsables à repérer les besoins de formation et à reconnaître les membres de l’équipe les plus performants. Pourquoi est-ce important ? Il permet d’analyser les performances des agents, la répartition de leur charge de travail et l’effet des transferts sur les délais de résolution. Où trouver ces données Disponible dans l’API Tickets de Freshservice sous le champ « responder_id ». Cet ID peut être associé aux données de l’API Agents pour obtenir le nom de l’agent. Exemples John DoeJane SmithSupportBot
	Catégorie de l’incident IncidentCategory	Catégorie utilisée pour classer l’incident, par exemple matériel, logiciel ou réseau.
Description La catégorie de l’incident permet de classer les incidents selon le type de problème signalé. Cette classification hiérarchique aide à orienter l’incident vers la bonne équipe et joue un rôle important dans l’analyse des tendances. Cet attribut est utilisé dans le Dashboard « Précision de la catégorisation des incidents » pour déterminer si une mauvaise catégorisation initiale allonge les délais de résolution en raison de réaffectations. Le regroupement des incidents par catégorie permet aux organisations de repérer les problèmes récurrents, de comprendre où se concentre l’essentiel des efforts d’assistance et de définir des initiatives d’amélioration adaptées. Pourquoi est-ce important ? Il permet d’analyser les tendances des incidents et de déterminer si une catégorisation incorrecte entraîne des retards de résolution. Où trouver ces données Il s’agit d’un champ par défaut personnalisable dans Freshservice. Il est disponible dans l’API Tickets sous le nom « category », avec les champs associés « sub_category » et « item_category ». Exemples MatérielLogicielProblème réseauAccès au compte
	Échéance du SLA de résolution ResolutionSlaTargetTime	Date et heure auxquelles l’incident doit être résolu selon les règles de son SLA.
Description Cet attribut enregistre la date et l’heure limites de résolution d’un incident. Cette échéance est déterminée par le SLA appliqué au ticket et dépend généralement de facteurs tels que la priorité. Cette échéance est indispensable au calcul du KPI « Taux de respect du SLA » et au fonctionnement du Dashboard de performance du SLA. En comparant l’horodatage réel de résolution à cette échéance, il est possible de déterminer si l’incident a été résolu dans les délais ou si le SLA n’a pas été respecté. Cette comparaison est fondamentale pour mesurer le respect des engagements de niveau de service. Pourquoi est-ce important ? Il indique l’échéance de résolution, nécessaire pour calculer le respect du SLA et repérer les incidents susceptibles de dépasser le délai. Où trouver ces données Disponible dans l’API Tickets de Freshservice sous les champs « fr_due_by » (première réponse) et « due_by » (résolution). Exemples 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Gravité de l’incident IncidentSeverity	Niveau de gravité de l’incident, qui indique son impact sur l’activité.
Description La gravité de l’incident mesure son impact sur l’activité. Elle est souvent classée comme faible, moyenne, élevée ou critique. La gravité est liée à la priorité, mais elle mesure l’impact, tandis que la priorité reflète l’urgence. La gravité et l’impact déterminent souvent ensemble la priorité finale. L’analyse par niveau de gravité permet d’évaluer la manière dont l’organisation traite les incidents ayant des conséquences importantes sur l’activité. Les Dashboards s’en servent pour ventiler les délais de résolution et la performance du SLA, afin que les problèmes les plus lourds de conséquences reçoivent l’attention et les ressources nécessaires tout au long de leur cycle de vie. Pourquoi est-ce important ? Il mesure l’impact d’un incident sur l’activité et permet de concentrer l’analyse sur les problèmes les plus dommageables. Où trouver ces données Il s’agit d’un champ par défaut de Freshservice, disponible dans l’API Tickets sous le nom « impact ». Les valeurs sont numériques. Exemples FaibleMoyenneÉlevée
	Groupe affecté AssignedGroup	Groupe ou équipe d’assistance actuellement chargé de l’incident.
Description Le groupe affecté indique quelle équipe, par exemple « Assistance de niveau 1 », « Équipe réseau » ou « Administrateurs de bases de données », est responsable de l’incident. Toute modification de cet attribut signale une escalade ou un transfert entre équipes fonctionnelles. L’analyse du groupe affecté est essentielle pour comprendre les délais de transfert et de prise en charge. Le Process Mining permet de visualiser le passage des incidents d’un groupe à l’autre, de repérer les parcours d’escalade fréquents et de mesurer le temps d’attente avant l’intervention de chaque groupe. Ces éléments aident à repérer les goulots d’étranglement organisationnels et les possibilités d’améliorer la collaboration entre équipes. Pourquoi est-ce important ? Il indique quelle équipe est responsable et permet d’analyser les transferts, les escalades et les délais entre équipes. Où trouver ces données Disponible dans l’API Tickets de Freshservice sous le champ « group_id ». Cet ID peut être associé aux données de l’API Groups pour obtenir le nom du groupe. Exemples Centre de servicesOpérations réseauAssistance infrastructure
	Priorité de l’incident IncidentPriority	Niveau de priorité de l’incident, qui détermine le degré d’urgence de la réponse et de la résolution.
Description La priorité de l’incident détermine la rapidité et le niveau d’attention requis pour son traitement. Elle est généralement définie sur une échelle allant de faible à urgente, en passant par moyenne et élevée, et détermine souvent les objectifs du SLA. En Process Mining, la priorité est un axe d’analyse important. Elle permet de comparer les processus de résolution des incidents prioritaires et moins prioritaires, et de vérifier que les problèmes les plus urgents sont traités efficacement. Les Dashboards ventilent souvent les métriques, comme le temps de cycle et le respect du SLA, par priorité afin d’aider les responsables de l’assistance à prendre des décisions concrètes. Pourquoi est-ce important ? Il aide à concentrer l’analyse sur les incidents les plus importants et permet d’évaluer la performance du SLA ainsi que l’affectation des ressources. Où trouver ces données Disponible dans l’API Tickets de Freshservice sous le champ « priority ». Les valeurs sont numériques, par exemple 1 pour faible et 4 pour urgente. Exemples FaibleMoyenneÉlevéeUrgente
	Statut de l’incident IncidentStatus	Statut actuel de l’incident au cours de son cycle de vie, par exemple ouvert, en attente, résolu ou clôturé.
Description Le statut de l’incident indique son état actuel. Les changements de statut sont des événements clés qui constituent la base de la carte de processus découverte, par exemple le passage de « In Progress » à « Pending » ou de « Resolved » à « Closed ». Cet attribut est fondamental pour comprendre le parcours de l’incident. L’analyse du temps passé dans chaque statut permet de repérer les goulots d’étranglement, par exemple les incidents qui restent trop longtemps en attente d’une réponse de l’utilisateur. Cet attribut est également essentiel pour définir les points de départ et de fin du calcul du temps de cycle. Pourquoi est-ce important ? Il suit l’avancement de l’incident au cours de son cycle de vie et aide à repérer les étapes où les retards sont fréquents. Où trouver ces données Disponible dans l’API Tickets de Freshservice sous le champ « status ». Les valeurs sont numériques. Exemples OuvertEn coursEn attenteRésoluClôturé
	Canal de signalement ReportingChannel	Méthode ou canal utilisé pour signaler l’incident, par exemple par e-mail, via le portail ou par téléphone.
Description Le canal de signalement, également appelé source, indique comment un incident a été transmis au système d’assistance. Les canaux courants comprennent l’e-mail, le portail en libre-service, le téléphone et la messagerie instantanée. L’analyse de cet attribut permet d’évaluer l’efficacité des différents canaux de signalement. Le Dashboard « Efficacité des canaux de signalement » compare le volume d’incidents et le délai moyen de résolution par canal afin de déterminer quelles méthodes sont les plus efficaces et lesquelles pourraient nécessiter des améliorations. Par exemple, les incidents signalés via le portail peuvent être résolus plus rapidement si les informations fournies dès le départ sont mieux structurées. Pourquoi est-ce important ? Il aide à repérer les canaux de signalement les plus efficaces et les possibilités d’améliorer la prise en charge initiale des incidents. Où trouver ces données Disponible dans l’API Tickets de Freshservice sous le champ « source ». Les valeurs sont numériques. Exemples E-mailPortailTéléphoneMessagerie instantanée
	Cause première RootCause	Raison sous-jacente ou cause première identifiée après l’analyse de l’incident.
Description L’attribut « Cause première » décrit le problème fondamental à l’origine de l’incident. Les agents d’assistance le renseignent généralement pendant ou après la résolution, dans le cadre d’une analyse des causes premières. Cet attribut est essentiel au Dashboard « Incidents récurrents et causes premières » et au KPI « Taux de réalisation des analyses des causes premières ». L’analyse des causes fréquentes permet aux organisations de passer d’une correction réactive des incidents à une gestion préventive des problèmes, en mettant en place des solutions durables qui évitent de nouveaux incidents et réduisent leur récurrence. Pourquoi est-ce important ? Il permet de gérer les problèmes de manière préventive en aidant à repérer et à éliminer les causes sous-jacentes des incidents récurrents. Où trouver ces données Il s’agit souvent d’un champ personnalisé dans Freshservice, car les fonctionnalités par défaut peuvent être limitées. Vérifiez dans la configuration « Ticket Fields » si un champ nommé « Root Cause » ou similaire existe. Exemples Bogue logicielErreur de configuration réseauProblème de formation des utilisateursPanne matérielle
	Incident rouvert ? IsReopened	Indicateur calculé, vrai si un incident a été rouvert après avoir été résolu ou clôturé.
Description Cet attribut booléen indique si un incident a été rouvert. Il prend la valeur vrai si, après avoir atteint le statut « Resolved » ou « Closed », l’incident repasse à un statut ouvert ou en cours. Cet indicateur est essentiel au calcul du KPI « Taux de réouverture des incidents » et au Dashboard « Incidents récurrents ». Un taux élevé de réouverture peut signaler une résolution initiale de mauvaise qualité, une analyse incomplète des causes premières ou une clôture prématurée. L’analyse de ces cas aide à améliorer la qualité et la durabilité des corrections. Pourquoi est-ce important ? Il met en évidence les échecs du processus de résolution, en repérant les incidents pour lesquels la correction initiale n’a pas fonctionné et a entraîné des reprises. Où trouver ces données Ce champ calculé est déduit de la séquence d’activités du journal d’événements. Il prend la valeur vrai si une activité telle que « Incident Reopened » se produit, ou si une activité correspondant à un état ouvert suit un état clôturé pour le même ID d’incident. Exemples truefalse
	Nombre de transferts HandoffCount	Nombre de transferts de l’incident entre différents agents ou groupes.
Description Le nombre de transferts est une métrique calculée qui dénombre les réaffectations d’un incident au cours de son cycle de vie. Chaque modification de l’attribut « AssignedAgent » ou « AssignedGroup » augmente ce nombre. Un nombre élevé de transferts peut indiquer un processus inefficace, une mauvaise orientation initiale ou un manque d’expertise des agents. Cette métrique alimente directement le KPI « Nombre de transferts d’incidents » et le Dashboard « Analyse des délais de transfert et de prise en charge ». Elle aide à repérer les incidents ou les parcours qui comportent trop de transferts et entraînent des retards. Pourquoi est-ce important ? Il quantifie les reprises et les réaffectations, et aide à repérer les pertes d’efficacité dues à une mauvaise orientation ou à un manque de connaissances. Où trouver ces données Cette métrique calculée est obtenue en comptant les valeurs distinctes ou les changements des champs « AssignedAgent » ou « AssignedGroup » au cours du cycle de vie d’un incident. Exemples 0125
	Service du demandeur RequestersDepartment	Service auquel appartient l’utilisateur qui a signalé l’incident.
Description Cet attribut indique le service du demandeur, par exemple les ventes, les finances ou l’informatique. Ces informations proviennent généralement du profil de l’utilisateur dans Freshservice. L’analyse des incidents par service du demandeur peut révéler si certains services sont particulièrement touchés par des problèmes ou s’ils rencontrent des difficultés qui leur sont propres. Elle apporte un contexte utile pour comprendre l’impact des incidents sur l’activité et peut aider à prioriser les corrections qui concernent des services essentiels. Pourquoi est-ce important ? Il apporte un contexte métier et permet d’analyser les tendances des incidents ainsi que leurs effets sur certains services. Où trouver ces données Ces informations sont associées au demandeur du ticket. Elles peuvent être récupérées depuis le point de terminaison de l’API « Requesters » à l’aide du champ « requester_id » du ticket, puis en consultant « department_id » et le nom du service. Exemples VentesMarketingFinancesRessources humaines
	SLA dépassé ? IsSlaBreached	Indicateur calculé, vrai si l’incident n’a pas été résolu dans le délai prévu par son SLA.
Description Cet attribut booléen est une métrique calculée qui indique si le délai de résolution d’un incident a dépassé l’objectif du SLA. Il est obtenu en comparant l’horodatage réel de résolution à « ResolutionSlaTargetTime ». Cet indicateur alimente directement le KPI « Taux de respect du SLA » et le Dashboard de performance du SLA. Il simplifie l’analyse en donnant un résultat clair, vrai ou faux, pour chaque incident. Les données peuvent ainsi être agrégées facilement et les tendances analysées. Il permet de repérer rapidement le nombre et la proportion d’incidents qui ne respectent pas les engagements de service. Pourquoi est-ce important ? Il mesure directement le respect du SLA pour chaque incident, ce qui facilite le calcul du taux global et le repérage des problèmes. Où trouver ces données Il s’agit d’un champ calculé lors de la transformation des données, en comparant l’horodatage « Incident Resolved » au champ « ResolutionSlaTargetTime ». Exemples truefalse
	Solution de contournement fournie WorkaroundProvided	Indique si une solution de contournement temporaire a été fournie à l’utilisateur avant la résolution définitive.
Description Cet attribut booléen indique si une correction temporaire ou une solution de contournement a été mise en place pour limiter l’impact de l’incident pendant l’élaboration d’une solution définitive. Cette information est souvent suivie à l’aide d’une case à cocher ou d’un statut spécifique. En Process Mining, cet attribut alimente le Dashboard « Indicateurs d’efficacité des solutions de contournement ». Il permet de comparer les délais de résolution des incidents avec et sans solution de contournement, afin de déterminer si ces mesures temporaires réduisent les perturbations de l’activité et accélèrent la résolution telle qu’elle est perçue par l’utilisateur. Pourquoi est-ce important ? Il aide à mesurer l’efficacité des solutions de contournement pour réduire l’impact des incidents et accélérer la résolution perçue. Où trouver ces données Il s’agit généralement d’un champ booléen personnalisé, sous forme de case à cocher. Vérifiez sa présence dans la configuration « Ticket Fields » de Freshservice. Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir le processus avec précision et repérer les goulots d’étranglement.

7 Recommandé 7 Facultatif

	Activité	Description
	Incident affecté à un groupe	Indique l’affectation initiale d’un incident à un groupe d’assistance. Celle-ci peut être effectuée automatiquement par des règles d’acheminement ou manuellement par un répartiteur. Cette activité est repérée en suivant la première valeur renseignée dans le champ « Group » du journal d’audit de l’incident.
Pourquoi est-ce important ? Le suivi des affectations est essentiel pour mesurer les délais de première réponse et repérer les goulots d’étranglement dans le processus de répartition. Il permet d’évaluer l’efficacité avec laquelle les incidents sont acheminés vers la bonne équipe. Où trouver ces données Déduit de la première entrée du journal d’activité de l’incident qui renseigne ou modifie le champ « Group ». Données à recueillir Repérez le premier horodatage auquel le champ « Group » est renseigné pour un incident. Type d’événement inferred
	Incident clôturé	Cet événement correspond à la clôture définitive et officielle de l’incident. Elle intervient généralement automatiquement après une période déterminée au statut « Resolved », mais un agent peut aussi la déclencher manuellement. Cet événement marque la fin du cycle de vie de l’incident.
Pourquoi est-ce important ? Cette activité marque la fin définitive du processus. Le temps total jusqu’à cet événement correspond à la durée complète du cycle de vie de l’incident, y compris les périodes d’attente de confirmation de l’utilisateur. Où trouver ces données Déduit du journal d’activité de l’incident en repérant le moment où le champ « Status » passe à « Closed ». Données à recueillir Utilisez l’horodatage de l’entrée du journal d’activité correspondant au passage du statut à « Closed ». Type d’événement inferred
	Incident résolu	Indique que l’agent a appliqué une correction et considère l’incident comme résolu. Cet événement est enregistré lorsque le statut de l’incident passe à « Resolved ». Dans Freshservice, cette étape importante arrête le décompte du SLA.
Pourquoi est-ce important ? Cette étape est essentielle pour mesurer le délai de résolution (TTR). La période entre les statuts « Resolved » et « Closed » permet d’analyser les retards liés à la confirmation de l’utilisateur et les règles de clôture automatique. Où trouver ces données Déduit du journal d’activité de l’incident en repérant le moment où le champ « Status » passe à « Resolved ». Données à recueillir Utilisez l’horodatage de l’entrée du journal d’activité correspondant au passage du statut à « Resolved ». Type d’événement inferred
	Incident signalé	Indique la création d’un nouvel enregistrement d’incident dans Freshservice. C’est le point de départ du cycle de vie de l’incident, généralement déclenché par un utilisateur final depuis un portail ou par courriel, ou par un agent du centre de services qui crée un ticket pour son compte. Cet événement est enregistré avec son horodatage de création.
Pourquoi est-ce important ? Cette activité marque le début du processus. L’analyse du temps écoulé entre cet événement et la résolution est essentielle pour mesurer le temps de cycle global et le respect des SLA. Où trouver ces données Récupéré à partir de l’horodatage de création dans la table des incidents. Freshservice enregistre explicitement cette information pour chaque nouveau ticket. Données à recueillir Utilisez l’horodatage « Created at » de l’enregistrement principal de l’incident. Type d’événement explicit
	Note de résolution ajoutée	Cette activité se produit lorsqu’un agent consigne la solution de l’incident dans une note de résolution. Dans Freshservice, il s’agit d’une action distincte qui précède le passage au statut « Resolved ». L’action et son contenu sont explicitement enregistrés.
Pourquoi est-ce important ? Cette étape marque l’identification d’une solution. Le temps écoulé avant le passage au statut « Incident Resolved » peut révéler des délais liés à une vérification interne ou à la documentation. Où trouver ces données Récupéré à partir de l’horodatage de l’ajout de la note de résolution à l’incident, consigné dans l’historique des échanges. Données à recueillir Repérez l’horodatage de l’entrée « Resolution Note » dans l’historique des échanges de l’incident. Type d’événement explicit
	Priorité de l’incident définie	Cette activité se produit lorsque la priorité de l’incident est définie ou modifiée. Le niveau de priorité détermine le degré d’urgence et les objectifs de résolution des SLA. Elle est repérée en suivant les modifications du champ « Priority » dans l’historique de l’incident.
Pourquoi est-ce important ? Une priorité définie tardivement ou de manière incorrecte peut entraîner des dépassements de SLA et une mauvaise répartition des ressources. L’analyse de cette activité permet de vérifier que les incidents critiques sont traités sans délai. Où trouver ces données Déduit du journal d’activité de l’incident, qui enregistre toutes les modifications du champ « Priority ». Données à recueillir Utilisez les horodatages du journal d’audit correspondant à la définition ou à la modification du champ « Priority ». Type d’événement inferred
	Statut passé à « In Progress »	Cette activité marque le début officiel de l’examen et du traitement actif de l’incident. Elle est enregistrée lorsqu’un agent fait passer le statut de l’incident à « In Progress ». Il s’agit d’un changement de statut standard consigné dans l’historique d’activité du ticket.
Pourquoi est-ce important ? Cette étape permet de distinguer le temps d’attente du temps de travail effectif. L’analyse de la durée pendant laquelle un incident reste « In Progress » est essentielle pour comprendre les efforts nécessaires à sa résolution. Où trouver ces données Déduit du journal d’activité de l’incident en repérant le moment où le champ « Status » passe à « In Progress ». Données à recueillir Filtrez le journal d’activité pour repérer le changement de statut à « In Progress », puis utilisez son horodatage. Type d’événement inferred
	Agent affecté à un incident	Cette activité indique le moment où un agent précis est chargé de traiter l’incident. Elle marque la prise en charge individuelle du ticket. L’historique d’activité du ticket indique quel agent a été affecté et à quel moment.
Pourquoi est-ce important ? Ces informations permettent d’analyser la charge de travail et les performances des agents, ainsi que le délai entre l’affectation au groupe et la prise en charge par un agent. Elles sont essentielles aux Dashboards de performance des agents. Où trouver ces données Suivi des modifications du champ « Agent » dans le journal d’activité ou la piste d’audit de l’incident. Données à recueillir Repérez les horodatages correspondant aux modifications du champ « Agent ». Type d’événement inferred
	Dépassement de l’objectif SLA	Cet événement calculé se produit lorsque le temps écoulé depuis la création d’un incident dépasse le délai de réponse ou de résolution défini dans son SLA. Freshservice suit le statut du SLA en interne ; cet événement peut être déduit en comparant les horodatages aux règles SLA.
Pourquoi est-ce important ? Cet événement mesure directement le respect des engagements de niveau de service. Repérer quand et pourquoi les délais sont dépassés est essentiel pour le Dashboard de performance du SLA et l’amélioration continue. Où trouver ces données Il est calculé en comparant l’horodatage de réponse ou de résolution à l’échéance prévue par le SLA. Freshservice signale souvent les tickets comme « SLA Violated ». Données à recueillir Déduisez cet événement en comparant l’horodatage « Resolved at » à celui de « Due by », ou lorsque le champ « SLA Status » passe à « Violated ». Type d’événement calculated
	Incident réaffecté	Indique que l’incident a été transféré d’un agent ou d’un groupe à un autre. Ce transfert marque une étape du processus de résolution. Il est déduit des modifications ultérieures des champs « Agent » ou « Group » après l’affectation initiale.
Pourquoi est-ce important ? Des réaffectations fréquentes indiquent souvent des inefficacités dans le processus, des lacunes dans les connaissances ou un mauvais acheminement initial. L’analyse de ces événements permet de repérer et de réduire les retards. Où trouver ces données Déduit du journal d’activité de l’incident en suivant toute modification des champs « Agent » ou « Group » après la première affectation. Données à recueillir Repérez les modifications des champs « Agent » ou « Group » dans l’historique d’audit du ticket. Type d’événement inferred
	Incident rouvert	Cet événement se produit lorsqu’un incident précédemment marqué « Resolved » repasse à un statut ouvert, généralement parce que l’utilisateur conteste la résolution. Il est déduit d’un changement de statut de « Resolved » à un état tel que « Open » ou « In Progress ».
Pourquoi est-ce important ? Un taux élevé de réouverture peut révéler des problèmes de qualité de résolution ou des corrections incomplètes. C’est un indicateur important pour analyser les reprises et les performances des agents. Où trouver ces données Déduit du journal d’activité de l’incident en repérant le passage du statut de « Resolved » à un statut actif. Données à recueillir Filtrez le journal d’activité pour repérer un changement du champ « Status » de « Resolved » à « Open » ou « In Progress ». Type d’événement inferred
	Première réponse envoyée	Cette activité correspond au premier message envoyé par un agent à l’utilisateur après le signalement de l’incident. Il peut s’agir d’une note publique ou d’une réponse directe. Freshservice enregistre les communications des agents avec leur horodatage.
Pourquoi est-ce important ? Le respect du SLA de première réponse est un KPI essentiel pour la satisfaction des clients. Cette activité permet de mesurer et d’analyser la rapidité avec laquelle les agents prennent en charge les nouveaux incidents. Où trouver ces données Repérez l’horodatage de la première note publique ou réponse ajoutée par un agent dans l’historique des échanges de l’incident. Données à recueillir Filtrez l’historique des échanges de l’incident pour trouver la première entrée ajoutée par un agent. Type d’événement explicit
	Solution de contournement fournie	Cette activité indique qu’une solution temporaire ou de contournement a été communiquée à l’utilisateur pour limiter les conséquences de l’incident. Son enregistrement nécessite souvent une configuration spécifique, comme une case à cocher dédiée, un type de note particulier ou l’analyse de mots-clés dans les notes des agents.
Pourquoi est-ce important ? Cette information permet d’évaluer l’efficacité des solutions de contournement pour limiter les conséquences sur l’activité et leur lien avec le délai de résolution définitive. Elle alimente le Dashboard des indicateurs d’efficacité des solutions de contournement. Où trouver ces données Il est probable qu’il ne s’agisse pas d’un événement explicite. Il peut être déduit de notes contenant des mots-clés comme « workaround », ou de l’enregistrement d’une modification du champ personnalisé « Workaround Provided ». Données à recueillir Déduit d’une modification d’un champ personnalisé ou de l’analyse des mots-clés dans les notes des agents. Type d’événement inferred
	Statut passé à « Pending »	Indique une pause dans le processus de résolution, généralement dans l’attente d’informations de l’utilisateur ou d’un tiers. Cet événement est déduit du passage à un statut « Pending ». Le temps passé dans cet état est souvent exclu du calcul des SLA.
Pourquoi est-ce important ? Repérer le temps passé dans les statuts d’attente est essentiel pour comprendre les dépendances externes et les retards. Cela permet de distinguer le temps de travail des agents du temps d’attente. Où trouver ces données Déduit du journal d’activité de l’incident lorsque le champ « Status » prend une valeur telle que « Pending » ou « Awaiting User Response ». Données à recueillir Filtrez le journal d’activité pour repérer les changements vers un statut d’attente, puis utilisez l’horodatage correspondant. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Freshservice

Étapes

Accédez au module Analyses de Freshservice : Connectez-vous à votre instance Freshservice avec un compte autorisé à consulter et à créer des rapports. Dans le menu principal, ouvrez le module Analyses.
Créez un rapport : Cliquez sur le bouton Nouveau rapport. Donnez-lui un nom explicite, par exemple « Journal d’événements de gestion des incidents ». Lorsque vous devez choisir une source de données, sélectionnez le module Gestion des incidents.
Sélectionnez un widget de rapport : Dans l’éditeur de rapport, ajoutez un widget et choisissez le type Tableau. Ce tableau servira de base à votre journal d’événements.
Ajoutez les principales colonnes de données : Dans le panneau des sources de données à droite, faites glisser les champs nécessaires dans la configuration des colonnes du tableau. Commencez par Identifiant de l’incident, Créé le, Agent, Groupe, Priorité, Gravité, Statut et Catégorie.
Ajoutez les données d’activité : Pour enregistrer chaque événement, vous devez joindre ou inclure les données des activités du ticket. Ajoutez la source de données Activités à votre widget. Dans cette source, ajoutez Effectué le (pour l’horodatage de l’événement) et Description de l’activité, ou des champs similaires décrivant le changement.
Créez une colonne calculée « ActivityName » : Cette étape est essentielle. Créez une colonne calculée ou un champ de formule. Utilisez des instructions IF imbriquées ou une fonction CASE pour convertir les données d’activité brutes en valeurs ActivityName requises. Consultez la section Requête pour connaître la logique détaillée des 14 activités.
Configurez « EventTimestamp » : Créez une autre colonne calculée pour EventTimestamp. La logique doit sélectionner l’horodatage Créé le pour l’activité « Incident signalé » et l’horodatage Effectué le de l’activité pour tous les autres événements.
Appliquez des filtres au rapport : Configurez les filtres pour limiter les données. Au minimum, définissez une plage de dates sur le champ « Créé le ». Une période glissante de 3 à 6 mois est recommandée. Ajoutez également un filtre pour ne conserver que les tickets dont le « Type de ticket » est « Incident ».
Exécutez et ajustez le rapport : Lancez le rapport pour générer un aperçu des données. Vérifiez que les colonnes ActivityName et EventTimestamp sont correctement renseignées. Ajustez les formules et les filtres au besoin.
Enregistrez et exportez le rapport : Lorsque le résultat vous convient, enregistrez le rapport. Utilisez l’option Exporter et choisissez le format CSV.
Planifiez l’exportation (facultatif) : Pour poursuivre l’analyse, vous pouvez planifier l’exécution et l’exportation automatiques du rapport. Configurez une fréquence, par exemple quotidienne ou hebdomadaire, pour recevoir le fichier CSV par e-mail ou à une autre destination.
Préparez les données à importer : Ouvrez le fichier CSV exporté. Renommez les en-têtes de colonnes pour qu’ils correspondent au schéma requis par ProcessMind : IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Ajoutez les colonnes statiques SourceSystem (avec la valeur « Freshservice ») et LastDataUpdate (avec l’horodatage actuel). Le fichier est prêt à être importé.

Configuration

Module Analyses : Cette méthode d’extraction nécessite un accès au module Analyses de Freshservice, disponible dans les forfaits supérieurs, par exemple Pro et Entreprise.
Autorisations requises : Votre compte utilisateur doit disposer d’un rôle autorisant la création, la modification et l’exécution de rapports dans le module Analyses.
Plage de dates : Il est essentiel de définir un filtre de dates sur la date de création des incidents afin de maîtriser le volume de données. Une période glissante de 3 à 6 mois est recommandée pour trouver un équilibre entre contexte historique et performances.
Filtres du rapport : Filtrez toujours sur « Type de ticket » égal à « Incident » afin d’exclure les demandes de service et les autres types de tickets de votre analyse de processus.
Champs calculés : Cette méthode repose largement sur des champs calculés (formules) pour déterminer ActivityName et EventTimestamp pour chaque événement. Il est utile de connaître l’éditeur de formules de Freshservice.
Volume de données : Notez que cette extraction génère plusieurs lignes par incident, une pour chaque activité. Dans les grandes instances Freshservice, le fichier CSV obtenu peut être volumineux, ce qui peut ralentir la génération du rapport et l’exportation.

Exemple de requête config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Étapes

Prérequis : Vérifiez que Python 3.6 ou une version ultérieure est installé, ainsi que les bibliothèques requests et pandas. Vous pouvez les installer avec pip : pip install requests pandas.
Générez une clé API : Connectez-vous à votre instance Freshservice en tant qu’administrateur. Ouvrez les paramètres de votre profil en cliquant sur votre photo de profil en haut à droite. Accédez à la section « API Key » et copiez votre clé API personnelle. Traitez cette clé comme un mot de passe.
Préparez le script : Enregistrez le code Python fourni dans un fichier nommé extract_freshservice_incidents.py sur votre ordinateur.
Configurez les paramètres : Ouvrez le fichier du script dans un éditeur de texte. Remplacez les valeurs fictives de FRESHSERVICE_DOMAIN (par exemple, « votreentreprise.freshservice.com »), API_KEY (la clé que vous venez de copier) et START_DATE_STR (le début de la période d’extraction souhaitée, au format « YYYY-MM-DD »).
Comprenez le fonctionnement du script : Le script récupère d’abord tous les tickets d’incident créés après la date de début indiquée. Il parcourt chaque page de résultats renvoyée par l’API. Pour chaque ticket, il effectue un second appel à l’API afin de récupérer l’historique détaillé de ses activités.
Générez le journal d’événements : Le script traite les données principales du ticket et son journal d’activités pour repérer et créer un enregistrement pour chacune des 14 activités métier requises. Par exemple, « Incident signalé » est créé à partir de la date de création du ticket, tandis que « Statut passé à En cours » est déduit d’une entrée précise du journal d’activités.
Déduisez les événements complexes : Certains événements, comme « Objectif SLA dépassé », sont déduits. Le script vérifie si le délai de résolution prévu par le SLA de l’incident a été dépassé. Si c’est le cas, il crée un événement horodaté à la date due_by, qui indique le moment du dépassement.
Exécutez le script : Ouvrez un terminal ou une invite de commandes, accédez au répertoire où vous avez enregistré le script, puis lancez la commande : python extract_freshservice_incidents.py.
Suivez l’exécution : Le script affiche dans la console sa progression et le nombre de tickets traités. Selon le nombre de tickets et les limites de fréquence de l’API, l’opération peut prendre un certain temps.
Vérifiez le résultat : À la fin de l’exécution, un fichier CSV nommé freshservice_incident_event_log.csv est créé dans le même répertoire. Il contient le journal d’événements complet.
Préparez l’importation : Ouvrez le fichier CSV dans un tableur et vérifiez que les colonnes (IncidentId, ActivityName, EventTimestamp, etc.) sont correctement renseignées. Le fichier est prêt à être importé dans ProcessMind ou un autre outil de Process Mining.

Configuration

FRESHSERVICE_DOMAIN : L’URL Freshservice propre à votre entreprise, par exemple mycompany.freshservice.com. Ce paramètre est obligatoire dans le script.
API_KEY : La clé API personnelle d’un utilisateur disposant des autorisations nécessaires pour consulter toutes les données d’incident. Ce paramètre est obligatoire.
START_DATE_STR : La date de début de l’extraction des données, au format « YYYY-MM-DD ». Pour obtenir une analyse pertinente, il est recommandé d’extraire une première période de 3 à 6 mois.
PAGE_SIZE : La valeur est définie sur 100, le maximum autorisé par l’API Freshservice, afin de réduire le nombre d’appels API et d’améliorer les performances. Il est généralement déconseillé de la modifier.
Limitation du débit de l’API : Le script inclut un appel time.sleep(1) après le traitement de chaque ticket afin de respecter les limites de fréquence de l’API Freshservice. Pour les instances à fort volume, cette valeur devra peut-être être ajustée pour éviter les erreurs.
Autorisations requises : La clé API doit appartenir à un compte utilisateur, par exemple un compte de service dédié, disposant au minimum des autorisations du rôle « SD Agent ». Cela garantit l’accès à tous les champs de ticket et journaux d’activités nécessaires dans les différents groupes du centre de services.

Exemple de requête python

import requests
import pandas as pd
import time
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

if __name__ == class="hl-string">"__main__":
    main()

Étapes

Vérifiez que votre forfait Freshservice et vos autorisations d’administrateur permettent d’utiliser les règles d’automatisation des flux de travail, les actions webhook, l’accès aux incidents et l’historique des activités des tickets. Avec l’équipe destinataire, vérifiez le point de terminaison, la méthode d’authentification, les exigences TLS et la politique de conservation.
Définissez le contrat d’événement avant de configurer l’automatisation. Utilisez un objet JSON par envoi webhook, avec IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory et ResolutionSlaTargetTime. Configurez le système destinataire pour qu’il conserve la charge utile d’origine du webhook et l’horodatage de réception.
Créez une règle d’automatisation des flux de travail pour la création d’incidents. Configurez-la pour qu’elle s’exécute à la création d’un incident, puis ajoutez une action webhook qui envoie l’activité Incident Reported. Définissez EventTimestamp sur l’horodatage de création de l’incident et ActivityName sur Incident Reported.
Créez des règles de mise à jour pour les changements d’affectation, de priorité, de statut, de communication, de notes, de SLA et de clôture. Configurez les conditions à partir des champs d’incident et de l’historique des activités disponibles dans votre compte Freshservice. Chaque règle doit envoyer un événement webhook distinct lorsque l’activité correspondante se produit. Ne comptez pas sur ProcessMind pour déduire les activités à partir d’un instantané final de l’incident.
Configurez explicitement l’association des activités. Envoyez Incident Assigned to Group lorsque le champ Group reçoit sa valeur initiale, Agent Assigned to Incident lorsque le champ Agent reçoit sa valeur initiale, Incident Prioritized lorsque Priority est défini ou modifié, First Response Sent lorsqu’une première réponse publique ou note publique admissible d’un agent est enregistrée, Incident Reassigned lorsque Agent ou Group change après l’affectation initiale, Status Changed to In Progress et Status Changed to Pending lors des transitions de statut correspondantes, Workaround Provided uniquement si un indicateur de solution de contournement configuré est présent, Resolution Note Added lorsqu’une note de résolution est ajoutée, Incident Resolved lorsque le statut passe à Resolved, SLA Target Breached lorsque la condition de dépassement du SLA configurée est remplie, Incident Reopened lorsque le statut passe de Resolved à un statut ouvert et Incident Closed lorsque le statut passe à Closed.
Configurez le corps de la requête webhook au format JSON et incluez l’identifiant de l’incident, le nom de l’activité, l’horodatage de l’événement, le système source, la date de dernière mise à jour et les attributs contextuels recommandés. Utilisez les variables webhook proposées par votre compte Freshservice. Si une variable requise n’est pas disponible dans l’éditeur webhook, renseignez-la dans le service destinataire en appelant une interface Freshservice approuvée, ou laissez sa valeur vide plutôt que de l’inventer.
Configurez l’idempotence et le traitement des envois au point de terminaison. Utilisez un identifiant d’événement stable si Freshservice en fournit un. Sinon, créez une clé de déduplication à partir de IncidentId, ActivityName, EventTimestamp et de l’identifiant de livraison source. Ne renvoyez une réponse HTTP de réussite qu’une fois la charge utile enregistrée de façon durable.
Testez chaque règle avec des incidents contrôlés. Créez un incident, attribuez un groupe et un agent, modifiez la priorité et le statut, envoyez une réponse admissible, ajoutez une solution de contournement et une note de résolution si elles sont configurées, puis résolvez, rouvrez et clôturez l’incident. Testez séparément un dépassement de SLA à l’aide d’une politique ou d’une file d’attente de test contrôlée. Vérifiez que chaque activité attendue arrive dans une charge utile webhook distincte.
Enregistrez les charges utiles webhook dans une zone de préparation durable, normalisez les horodatages dans un même fuseau horaire et transformez chaque charge utile en une ligne du journal d’événements. Conservez une ligne par activité webhook explicite. Renseignez LastDataUpdate avec l’horodatage d’actualisation de l’extraction ou de l’ingestion, et non avec celui de l’événement métier.
Validez le journal d’événements préparé, supprimez uniquement les livraisons strictement identiques en double et conservez les répétitions légitimes, comme plusieurs changements de priorité ou transitions de statut. Vérifiez que IncidentId, ActivityName, EventTimestamp, SourceSystem et LastDataUpdate sont renseignés pour chaque ligne.
Exportez le journal d’événements normalisé au format CSV ou dans un autre format pris en charge par ProcessMind. Utilisez exactement les noms de colonnes IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory et ResolutionSlaTargetTime. Importez le fichier ou connectez la source d’événements préparée à ProcessMind, en associant IncidentId à l’identifiant du cas et ActivityName au champ d’activité.

Configuration

Portée des déclencheurs : Configurez des règles d’automatisation des flux de travail distinctes pour la création d’incidents et pour chaque condition de mise à jour. Une règle générale couvrant toutes les mises à jour peut générer des événements en double ou ambigus, à moins que le système destinataire n’applique une association stricte des activités.
Charge utile webhook : Incluez tous les attributs requis dans chaque charge utile. Ajoutez les attributs recommandés lorsqu’ils sont disponibles au moment de l’événement. Conservez la charge utile brute à des fins d’audit et de rejeu.
Sémantique des activités : Distinguez les affectations initiales du groupe et de l’agent des changements ultérieurs. Ces derniers génèrent Incident Reassigned, tandis que l’affectation initiale génère l’activité correspondante.
Gestion des statuts : Associez les valeurs exactes des statuts configurés dans le compte Freshservice. Si le compte utilise des statuts personnalisés pour les incidents en attente ou ouverts, configurez explicitement leur association.
Première réponse : Définissez si une réponse publique, une note publique ou un autre type de communication est admissible. Appliquez cette définition de manière cohérente et ne générez l’événement que pour la première communication admissible de chaque incident.
Détection des solutions de contournement : Configurez un champ dédié, une case à cocher, un type de note ou une règle de mots-clés approuvée. Sans cette configuration, il est impossible d’identifier de façon fiable l’activité Workaround Provided.
Dépassement du SLA : Configurez un déclencheur explicite de dépassement du SLA ou un processus planifié distinct qui compare l’heure actuelle à ResolutionSlaTargetTime. Un instantané final de l’incident ne suffit pas à reconstituer l’horodatage du dépassement.
Plage de dates : Pour la validation initiale, utilisez environ 3 à 6 mois d’incidents. En temps réel, commencez l’ingestion avant la période d’analyse visée et conservez l’historique des webhooks pour permettre leur rejeu.
Filtres : Appliquez uniquement les filtres approuvés pour l’entreprise, l’espace de travail, le service, la catégorie ou la date. Ne présumez pas de noms de champs Freshservice ni d’une syntaxe de filtre qui ne figurent pas dans la configuration du compte.
Performances : Traitez les webhooks de manière asynchrone, placez les requêtes entrantes en file d’attente, regroupez les écritures en aval et indexez IncidentId et EventTimestamp. Évitez les appels d’enrichissement synchrones à la réception des webhooks.
Fiabilité : Configurez les nouvelles tentatives, la gestion des messages non distribuables, la surveillance et la suppression des doublons. Consignez les échecs de livraison et relancez leur traitement après correction.
Prérequis : Accès administrateur, disponibilité de l’automatisation des flux de travail, autorisations webhook, point de terminaison HTTPS, configuration de l’authentification, fonctionnalités adaptées du forfait Freshservice et processus de dépôt ou d’importation compatible avec ProcessMind.
Sécurité : Utilisez HTTPS, limitez si possible les accès entrants, renouvelez les identifiants, réduisez au minimum les champs sensibles et protégez les descriptions et les notes d’incident si elles figurent dans les charges utiles.

Exemple de requête config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

Prêt à commencer ?

Utilisez ce modèle pour structurer correctement vos données et mieux comprendre vos flux de travail de gestion des incidents. Commencez dès aujourd’hui à réduire les délais de résolution.

Retour au guide d’amélioration

Télécharger le modèle

Évitez les dépassements de SLA : optimisez dès aujourd’hui la gestion des incidents

Rejoignez les entreprises qui réduisent leur MTTR de 35 % et évitent les dépassements de SLA coûteux.

Démarrez votre essai gratuit

Essai gratuit de 14 jours, sans carte bancaire.

Votre modèle de données pour la gestion des incidents

Votre modèle de données pour la gestion des incidents

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d’extraction

Exportation des données du module Analyses de Freshservice au format CSV

Étapes

Configuration

Exemple de requête config

Extraction par script Python via l’API REST de Freshservice

Étapes

Configuration

Exemple de requête python

Envoi des données en temps réel par des webhooks de l’automatisation des flux de travail

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Évitez les dépassements de SLA : optimisez dès aujourd’hui la gestion des incidents

Votre modèle de données pour la gestion des incidents

Votre modèle de données pour la gestion des incidents

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d’extraction

Exportation des données du module Analyses de Freshservice au format CSV

Étapes

Configuration

Exemple de requête config

Extraction par script Python via l’API REST de Freshservice

Étapes

Configuration

Exemple de requête python

Envoi des données en temps réel par des webhooks de l’automatisation des flux de travail

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Évitez les dépassements de SLA : optimisez dès aujourd’hui la gestion des incidents

Prêt à commencer ?

Évitez les dépassements de SLA : optimisez dès aujourd’hui la gestion des incidents