您的事件管理数据模板

Freshservice

← 返回改进指南

事件管理属性(19) 事件管理活动(14) 数据提取指南(3)

您的事件管理数据模板

此模板旨在帮助您准备数据，以便有效分析事件管理流程。模板列出了需要收集的必要属性和跟踪的关键活动，并提供从源系统提取这些信息的实用指南。借助此资源，您可以简化数据准备工作。

建议收集的属性
需要跟踪的关键活动
数据提取指南

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

事件管理属性

以下是建议纳入事件日志的数据字段，可用于全面分析事件管理流程。

5 必填 7 建议填写 7 选填

	名称	说明
	事件ID IncidentId	每条事件记录的唯一标识符，也是跟踪整个事件生命周期的主键。
说明事件ID是事件管理分析的核心。它充当案例ID，将相关活动、时间戳和属性变更关联起来，形成完整的处理轨迹。在流程挖掘中，每条事件日志记录都与一个事件ID关联，因此可以还原每个事件的端到端流程。这对于计算周期时间、分析流程变体以及识别单个案例中的瓶颈至关重要。没有唯一标识符，就无法区分不同事件，也无法分析事件从上报到解决的处理路径。重要性它能唯一标识每个事件，支持从创建到关闭的全生命周期跟踪与分析。获取途径这是工单的主要标识符，可通过Freshservice Tickets API中的工单对象“id”字段获取。示例 INC-10234INC-10235INC-10236
	事件时间戳 EventTimestamp	活动或事件发生的确切日期和时间。
说明事件时间戳，也称为开始时间，记录活动发生的准确时刻。从创建到关闭，事件生命周期中的每项活动都有对应的时间戳。此属性是所有基于时间的流程挖掘分析的关键。它用于按时间顺序排列事件、计算活动间隔、衡量案例总周期时间和分析等待时间，也是构建仪表板的基础，可用于跟踪SLA绩效、交接延迟和整体解决时间。重要性它提供事件的时间顺序，是计算时长、分析周期时间和了解流程绩效的基础。获取途径此属性根据Freshservice中的多个时间戳字段推导得出，例如“created_at”“updated_at”，以及工单对话记录或审计日志中的时间戳。示例 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	数据上次更新时间 LastDataUpdate	表示此流程数据上次刷新或提取时间的时间戳。
说明此属性记录整个数据集上次从源系统更新的时间戳。它是适用于整个数据集而非单个事件的元数据字段，但为保持一致性，通常也会将其纳入事件级数据。在分析中，此信息有助于了解数据的新鲜度，以及仪表板和KPI涵盖的时间范围。用户可以据此判断分析结果的时效性，并了解最新事件是否已纳入分析。重要性它能告知用户数据的时效性，帮助其了解分析所涵盖的时间范围。获取途径这是在数据提取（ETL）过程中生成的元数据时间戳。示例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	活动名称 ActivityName	事件生命周期中某个时间点发生的具体业务活动或事件名称。
说明活动名称用于描述事件管理流程中的单个步骤或事件，例如“事件分配给支持组”“状态变更为待处理”或“事件已解决”。这些活动根据事件数据随时间发生的变化推导得出。此属性是流程挖掘的基础，用于定义发现的流程图中的节点。通过分析活动的顺序和频率，组织可以直观查看实际的事件解决流程，识别常见路径，发现偏离标准过程的情况，并找出频繁重新分配等返工循环。重要性它定义流程图中的步骤，支持可视化和分析事件解决流程、瓶颈及偏差。获取途径此属性不是Freshservice中的直接字段，而是根据工单属性的变化推导得出，例如状态、优先级、客服人员或支持组分配，以及备注的添加。示例事件已报告事件已分派至支持组已添加解决说明事件已解决
	源系统 SourceSystem	提取数据的系统，通常为“Freshservice”。
说明此属性用于标识数据来源。在此场景中，其值始终为“Freshservice”；但如果需要整合多个系统的数据，以全面了解流程，这一字段就十分重要。纳入源系统属性是数据治理和可追溯性的最佳实践。它能明确数据来源，便于验证和调试，也有助于未来将其他服务管理或运营系统纳入流程挖掘项目。重要性它能明确标识事件管理数据的来源，确保数据可追溯并便于治理。获取途径这通常是在数据转换（ETL）过程中添加的静态值，用于标记数据集。示例 FreshserviceFreshservice-EUFreshservice-PROD
	事件严重程度 IncidentSeverity	事件的严重程度，用于表示其业务影响。
说明事件严重程度用于衡量事件对业务的影响，通常分为低、中、高或严重。严重程度与优先级相关，但侧重点不同：严重程度关注影响，优先级关注紧迫性。严重程度和影响范围通常共同决定最终优先级。按严重程度分析，有助于了解组织处理重大业务影响事件的能力。仪表板可按严重程度细分解决时间和SLA绩效，确保影响最大的事件在整个生命周期中获得适当的关注和资源。重要性它衡量事件对业务的影响，支持针对危害最大的事件开展分析。获取途径这是Freshservice中的默认字段，可通过Tickets API中的“impact”字段获取。其值为数字。示例低中高
	事件优先级 IncidentPriority	事件的优先级，用于确定响应和解决的紧迫程度。
说明事件优先级是决定事件处理速度和关注程度的关键字段。通常按低、中、高和紧急等等级划分，并常用于确定SLA目标。在流程挖掘中，优先级是重要的筛选和分析维度。通过它可以比较高优先级与低优先级事件的解决流程，确保关键问题得到高效处理。仪表板通常会按优先级细分周期时间和SLA达成情况等指标，为支持管理者提供可采取行动的洞察。重要性它有助于优先分析最关键的事件，也是评估SLA绩效和资源分配的重要依据。获取途径可在Freshservice Tickets API的“priority”字段中获取。其值为数字，例如1表示低，4表示紧急。示例低中高紧急
	事件状态 IncidentStatus	事件生命周期中的当前状态，例如未处理、待处理、已解决或已关闭。
说明事件状态表示事件当前所处的状态。状态变更是构成发现的流程图的关键事件，例如从“处理中”变为“待处理”，或从“已解决”变为“已关闭”。此属性是了解事件处理轨迹的基础。分析事件在各状态中停留的时间，有助于识别瓶颈，例如事件因等待用户回复而在“待处理”状态停留过久。此属性对于定义周期时间的起点和终点也至关重要。重要性它能跟踪事件在生命周期中的进展，并帮助识别常见延迟的阶段。获取途径可在Freshservice Tickets API的“status”字段中获取。其值为数字。示例未处理处理中待处理已解决已关闭
	事件类别 IncidentCategory	用于对事件分类的类别，例如硬件、软件或网络。
说明事件类别用于根据上报问题的类型对事件进行分类。这种分层分类有助于将事件转交给正确的团队，也是趋势分析的重要依据。此属性可用于“事件分类准确率”仪表板，分析初始分类错误是否因重新分配而延长解决时间。按类别对事件分组后，组织可以识别重复发生的问题，了解支持工作主要集中在哪些方面，并制定有针对性的改进措施。重要性它支持分析事件趋势，并帮助判断分类错误是否导致解决延迟。获取途径这是Freshservice中的默认可自定义字段，可通过Tickets API中的“category”字段获取，相关字段还包括“sub_category”和“item_category”。示例硬件软件网络问题账户访问
	分配的客服人员 AssignedAgent	当前负责解决事件的客服人员姓名或ID。
说明分配的客服人员用于标识在特定时间负责处理事件的服务台员工。此属性发生变化，表示负责权已在客服人员之间转移。此属性对于绩效分析至关重要，可用于构建仪表板，跟踪客服人员的工作量、每位客服人员的平均解决时间和首次联系解决率。它还可用于分析客服人员之间的交接，因为交接可能造成延迟和效率低下。通过跟踪人员分配情况，管理者可以识别培训需求，并发现表现出色的团队成员。重要性它支持分析客服人员绩效、工作量分配，以及人员交接对解决时间的影响。获取途径可在Freshservice Tickets API的“responder_id”字段中获取。将此ID与Agents API关联后，即可获取客服人员姓名。示例 John DoeJane SmithSupportBot
	分配的支持组 AssignedGroup	当前负责处理事件的支持组或团队。
说明分配的支持组用于标识负责处理事件的团队，例如“一级支持”“网络团队”或“数据库管理员”。此属性发生变化，表示事件已升级，或已转交给其他职能团队。分析分配的支持组对于了解交接和转派延迟至关重要。流程挖掘可以直观呈现事件在各支持组之间的流转，突出常见的升级路径，并衡量各组等待处理的时间。这有助于识别组织层面的瓶颈，并发现简化跨团队协作的机会。重要性它能跟踪负责团队，对于分析交接、升级和团队间延迟至关重要。获取途径可在Freshservice Tickets API的“group_id”字段中获取。将此ID与Groups API关联后，即可获取支持组名称。示例服务台网络运营基础设施支持
	解决SLA目标时间 ResolutionSlaTargetTime	根据SLA策略，事件预期解决时间的截止时间戳。
说明此属性存储解决事件的具体截止日期和时间。该目标由应用于工单的服务级别协议（SLA）策略确定，通常取决于优先级等因素。此目标时间是计算“SLA达成率”KPI和生成“SLA绩效”仪表板的必要依据。将实际解决时间戳与目标时间进行比较，即可判断事件是否按时解决或违反SLA。这是衡量服务级别承诺履行情况的基础。重要性它提供解决事件的截止时间，是计算SLA达成情况和识别风险事件的必要依据。获取途径可在Freshservice Tickets API的“fr_due_by”（首次响应）和“due_by”（解决）字段中获取。示例 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	上报渠道 ReportingChannel	上报事件的方式或渠道，例如电子邮件、门户或电话。
说明上报渠道也称为来源，用于标识事件通过何种方式进入支持系统。常见渠道包括电子邮件、自助服务门户、电话或聊天。分析此属性有助于评估不同上报渠道的效率。“上报渠道效率”仪表板按渠道比较事件数量和平均解决时间，以判断哪些方式更有效，哪些渠道可能需要改进。例如，通过门户上报的事件如果一开始就包含更规范的信息，解决速度可能更快。重要性它有助于识别效率最高的上报渠道，并发现改进事件受理流程的机会。获取途径可在Freshservice Tickets API的“source”字段中获取。其值为数字。示例电子邮件门户电话聊天
	交接次数 HandoffCount	事件在不同客服人员或支持组之间转交的次数。
说明交接次数是一个计算指标，用于统计事件生命周期中重新分配的次数。每当“AssignedAgent”或“AssignedGroup”属性发生变化，计数就会增加。交接次数偏高通常表明流程效率低下、初始路由错误或客服人员缺乏相关专业知识。此指标可直接用于“事件交接次数”KPI和“交接与转派延迟分析”仪表板，帮助识别转交过多并导致延迟的事件或流程路径。重要性它量化返工和重新分配情况，有助于识别因路由错误或知识缺口导致的效率问题。获取途径这是一个计算指标，通过统计单个事件生命周期内“AssignedAgent”或“AssignedGroup”字段的不同值或变更次数得出。示例 0125
	已提供变通方案 WorkaroundProvided	用于标记是否在最终解决前向用户提供了临时解决方案。
说明此布尔属性用于标记是否在制定永久解决方案期间实施了临时修复或替代方案，以减轻事件影响。通常通过复选框或特定状态进行跟踪。在流程挖掘中，此属性可用于“临时解决方案效果指标”仪表板。通过比较采用和未采用临时解决方案的事件解决时间，可以判断临时修复是否有效减少业务中断，并从用户角度加快整体解决进度。重要性它有助于衡量临时解决方案在减轻事件影响和加快用户感知的解决进度方面的效果。获取途径这通常是自定义布尔字段（复选框）。请在Freshservice的“Ticket Fields”配置中确认该字段是否存在。示例 truefalse
	是否违反SLA IsSlaBreached	计算得出的标记；如果事件未在规定的SLA目标时间内解决，则值为true。
说明此布尔属性是一个计算指标，用于标记事件解决时间是否超过SLA目标。它通过比较实际解决时间戳与“ResolutionSlaTargetTime”得出。此标记可直接用于“SLA达成率”KPI和“SLA绩效”仪表板。它为每个事件的SLA绩效提供清晰的二元结果，简化汇总和趋势分析，并帮助快速识别未达到服务承诺的事件数量和占比。重要性它直接衡量每个事件的SLA达成情况，便于计算整体达成率并识别问题领域。获取途径这是一个计算字段，在数据转换过程中通过比较“Incident Resolved”时间戳与“ResolutionSlaTargetTime”字段得出。示例 truefalse
	是否重新打开 IsReopened	计算得出的标记；如果事件在解决或关闭后重新打开，则值为true。
说明此布尔属性是一个计算标记，用于识别重新打开的事件。如果事件达到“Resolved”或“Closed”状态后，状态又变回未处理或处理中，则此标记设为true。此标记对于计算“事件重新打开率”KPI和生成“重复事件”仪表板至关重要。事件重新打开率偏高，可能说明初次解决质量不佳、根本原因分析不完整或关闭过早。分析这些案例有助于提升修复方案的质量和持久性。重要性它能发现解决流程中的问题，突出显示初次修复无效并导致返工的事件。获取途径这是根据事件日志中的活动顺序推导得出的计算字段。如果出现“事件重新打开”等活动，或同一事件ID对应的已关闭状态之后又出现未关闭状态活动，则值为true。示例 truefalse
	根本原因 RootCause	调查后确认的事件根本原因。
说明根本原因属性用于记录导致事件发生的根本问题。支持人员通常会在解决过程中或解决后，通过根本原因分析（RCA）填写此信息。此属性对于“重复事件及根本原因”仪表板和“根本原因分析完成率”KPI至关重要。通过分析常见根本原因，组织可以从被动修复事件转向主动管理问题，实施永久性解决方案，防止事件再次发生并减少重复问题。重要性它有助于识别并消除重复事件的根本原因，从而支持主动的问题管理。获取途径由于Freshservice的默认功能可能有限，此字段通常需要自定义。请在“Ticket Fields”配置中查找名为“Root Cause”或类似名称的字段。示例软件缺陷网络配置错误用户培训问题硬件故障
	请求者所属部门 RequestersDepartment	上报事件的用户所属部门。
说明此属性用于标识请求者所属的业务部门，例如“销售”“财务”或“IT”。此信息通常来自Freshservice中的用户资料。按请求者所属部门分析事件，可以发现某些业务单元是否受到问题的影响更大，或是否存在部门特有的问题。这为了解事件的业务影响提供了重要背景，也有助于优先修复影响关键部门的问题。重要性它提供业务背景，支持分析事件趋势及其对特定部门的影响。获取途径此信息与工单请求者关联。可使用工单中的“requester_id”查询“Requesters”API端点，再获取“department_id”和部门名称。示例销售市场营销财务人力资源

必填建议填写选填

事件管理活动

以下是建议记录在事件日志中的关键流程步骤和里程碑，有助于准确发现流程并识别瓶颈。

7 建议填写 7 选填

	活动	说明
	事件关闭	表示事件记录正式结束。通常在事件处于“Resolved”状态一段时间后自动关闭，也可以由客服人员手动关闭。此事件标志着事件生命周期结束。
重要性此活动是流程的最终终点。从开始到此事件的总时长代表完整的事件生命周期，包括等待用户确认的时间。获取途径根据事件活动日志推断：当“Status”字段更新为“Closed”时记录。采集使用活动日志中状态变更为“Closed”的记录时间戳。事件类型 inferred
	事件已分派至支持组	表示事件首次分派至支持组。分派可以通过路由规则自动完成，也可以由调度人员手动完成。可通过事件审计日志中“组”字段首次填入内容的记录捕获此活动。
重要性跟踪分派情况是衡量首次响应时间、识别分派流程瓶颈的关键。这有助于分析事件是否被高效地路由至正确团队。获取途径根据事件活动日志中首次填入或更改“组”字段的记录推断。采集找出事件“组”字段首次填入内容时的时间戳。事件类型 inferred
	事件已报告	表示在Freshservice中创建了新的事件记录。这是事件处理周期的起点，通常由最终用户通过门户或电子邮件报告，也可能由服务台坐席代用户创建工单。系统会明确记录此事件及其创建时间戳。
重要性这是整个流程的主要开始事件。分析从此事件到解决所需的时间，是衡量整体周期时间和SLA达成情况的基础。获取途径从事件表的创建时间戳中获取。Freshservice会为每个新工单明确记录该时间。采集使用主事件记录中的“创建时间”时间戳。事件类型 explicit
	事件已解决	表示坐席已实施修复并认为事件已解决。事件状态更改为“已解决”时，系统会记录此活动。在Freshservice中，这是一个关键节点，SLA计时会在此停止。
重要性这是衡量解决时间（TTR）的关键节点。分析“已解决”到“已关闭”之间的时间，有助于了解用户确认延迟和自动关闭策略的影响。获取途径根据事件活动日志推断：当“Status”字段更新为“Resolved”时记录。采集使用活动日志中状态变更为“Resolved”的记录时间戳。事件类型 inferred
	事件已设定优先级	事件优先级被设定或更新时会发生此活动。优先级决定事件的紧急程度和解决SLA目标。可通过监控事件历史记录中“优先级”字段的变更来捕获此活动。
重要性优先级设定错误或延迟，可能导致SLA未达标和资源分配低效。分析此活动有助于确保严重事件得到及时处理。获取途径根据事件活动日志推断，该日志会记录“优先级”字段的所有更新。采集使用审计日志中“优先级”字段值被设定或更改时的时间戳。事件类型 inferred
	已添加解决说明	坐席添加解决说明、记录事件解决方案时会发生此活动。在Freshservice中，这是将状态更改为“已解决”之前的一项独立操作，系统会明确记录该操作及其内容。
重要性此活动标志着解决方案已确定。从此时到事件状态变为“已解决”之间的时间，可能反映内部审核或文档记录所需的额外时间。获取途径从事件添加解决说明时的时间戳中获取，该记录会保存在对话历史中。采集找出事件对话记录中“解决说明”条目的时间戳。事件类型 explicit
	状态已更改为处理中	此活动标记事件调查和处理正式开始。坐席将事件状态更改为“处理中”时，系统会记录此活动。这是工单活动历史中记录的标准状态变更。
重要性此节点有助于区分等待时间和实际处理时间。分析事件处于“处理中”状态的时长，是了解解决工作量的关键。获取途径根据事件活动日志推断，识别“状态”字段更新为“处理中”的时间。采集在活动日志中筛选状态更改为“处理中”的记录，并使用其时间戳。事件类型 inferred
	SLA目标超时	这是一个计算得出的事件：当事件经过的时间超过其响应或解决时限的SLA目标时，就会发生。Freshservice会在内部跟踪SLA状态，可通过将时间戳与SLA策略进行比较来推导此事件。
重要性直接衡量服务级别承诺的履行情况。识别超时发生的时间和原因，对于SLA绩效仪表板和持续改进至关重要。获取途径将解决或响应时间戳与SLA目标截止时间进行比较后计算得出。Freshservice通常会将工单标记为“SLA Violated”。采集比较“Resolved at”时间戳与“Due by”时间戳，或在“SLA Status”字段变为“Violated”时推导此事件。事件类型 calculated
	事件已重新分派	表示事件从一名坐席或一个支持组转交给另一名坐席或另一个支持组，标志着解决流程中的一次交接。可通过检测首次分派后“坐席”或“组”字段的后续变更来推断此事件。
重要性频繁重新分派或交接，往往表明流程低效、知识存在缺口或初始路由不正确。分析这些事件有助于发现并减少延迟。获取途径根据事件活动日志推断，跟踪首次分派后“坐席”或“组”字段的任何变更。采集检测工单审计历史中“坐席”或“组”字段的变更。事件类型 inferred
	事件重新打开	此前标记为“Resolved”的事件重新变为未关闭状态时，就会发生此情况，通常是用户不认可解决结果所致。可根据状态从“Resolved”变回“Open”或“In Progress”等状态来推断。
重要性重新打开率偏高，说明解决质量可能存在问题，或修复并不完整。这是分析返工和客服人员绩效的一项关键指标。获取途径根据事件活动日志推断：检测状态是否从“Resolved”变为活跃状态。采集在活动日志中筛选“Status”从“Resolved”变为“Open”或“In Progress”的记录。事件类型 inferred
	坐席已分派至事件	此活动标记特定坐席被分派处理事件的时间，表示该工单已由个人负责。工单活动历史会记录分派的坐席及分派时间。
重要性这有助于分析坐席工作量和绩效，以及事件分派至支持组后由个人接手所需的时间。对于坐席绩效仪表板而言，这项数据至关重要。获取途径通过事件活动日志或审计记录中的“坐席”字段变更进行跟踪。采集找出“坐席”字段发生变更时对应的时间戳。事件类型 inferred
	已发送首次响应	表示事件报告后坐席首次与用户沟通，可以是公开备注或直接回复。Freshservice会记录所有坐席沟通及其时间戳。
重要性达到首次响应SLA是影响客户满意度的关键指标。通过此活动，可以衡量并分析坐席响应新事件的速度。获取途径查找坐席在事件对话记录中添加的第一条公开备注或回复的时间戳。采集筛选事件对话历史，找出坐席最早添加的记录。事件类型 explicit
	已提供变通方案	此活动表示已向用户说明临时解决方案或变通方案，以减轻事件影响。要捕获此活动，通常需要进行特定系统配置，例如设置专用复选框、特定备注类型，或分析坐席备注中的关键词。
重要性这有助于分析变通方案在减轻业务影响方面的效果，以及它与最终解决时间之间的关系。相关数据可用于变通方案效果指标仪表板。获取途径这可能不是系统中明确记录的事件。可以通过标记包含“变通方案”等关键词的备注来推断；如果使用自定义的“已提供变通方案”复选框字段，也可以根据其变更记录推断。采集根据自定义字段变更或坐席备注关键词分析推断。事件类型 inferred
	状态已更改为待处理	表示解决流程暂停，通常是等待用户或第三方提供信息。可根据状态更改为任意“待处理”状态来推断。此状态持续时间通常不计入SLA计算。
重要性识别处于待处理状态的时长，对于了解外部依赖和延迟至关重要。这有助于区分坐席处理时间和等待时间。获取途径当事件活动日志中的“状态”字段更新为“待处理”或“等待用户回复”等值时，可据此推断。采集在活动日志中筛选状态更改为任意待处理状态的记录，并使用相应时间戳。事件类型 inferred

建议填写选填

数据提取指南

如何从Freshservice获取数据

步骤

访问Freshservice分析模块：使用有权访问和创建报告的账户登录Freshservice。在主菜单中打开分析模块。
创建新报告：点击新建报告按钮，输入清晰的名称，例如“事件管理事件日志”。系统提示选择数据源时，选择事件管理模块。
选择报告组件：在报告编辑器中添加新组件，并选择表格类型，作为事件日志数据的基础。
添加主要数据列：从右侧数据源面板将所需字段拖入表格列配置中。建议先添加事件ID、创建时间、处理人员、组、优先级、严重程度、状态和类别。
纳入活动数据：若要记录单个事件，必须关联或纳入工单活动数据。将“活动”数据源添加到组件中，再添加“发生时间”（作为事件时间戳）以及“活动说明”等描述变更内容的字段。
创建计算列“ActivityName”：这是最关键的一步。新建计算列或公式字段，使用嵌套IF语句或CASE函数，将原始活动数据转换为所需的ActivityName值。每项14种活动的详细逻辑请参阅“查询”部分。
配置“EventTimestamp”：再创建一个EventTimestamp计算列。对于“事件已报告”活动，使用“创建时间”时间戳；对于其他事件，使用活动的“发生时间”时间戳。
设置报告筛选条件：配置报告筛选条件以缩小数据范围。至少应按“创建时间”字段设置日期范围，建议选择最近3至6个月。还应添加筛选条件，仅纳入“工单类型”为“事件”的工单。
运行并完善报告：运行报告并查看预览，确认ActivityName和EventTimestamp列已正确填充。根据需要调整公式和筛选条件。
保存并导出报告：确认报告结果无误后保存。选择导出，并将格式设为CSV。
安排导出（可选）：如需持续分析，可安排报告自动运行和导出。设置每日或每周等计划，将CSV文件发送到您的邮箱或其他位置。
准备上传数据：打开导出的CSV文件，将列标题改为ProcessMind所需的格式，例如IncidentId、ActivityName、EventTimestamp、AssignedAgent、AssignedGroup等。添加静态列SourceSystem（值为“Freshservice”）和LastDataUpdate（使用当前时间戳）。文件现已准备好上传。

配置

分析模块：提取数据需要访问Freshservice分析模块，该模块仅在较高席位等级中提供（例如Pro、Enterprise）。
所需权限：您的账户角色必须有权在分析模块中创建、编辑和运行报告。
日期范围：必须按事件创建日期设置日期范围筛选条件，以控制数据量。建议选择滚动的3至6个月，兼顾历史信息和处理性能。
报告筛选条件：始终筛选“工单类型”等于“事件”，以免将服务请求或其他工单类型纳入流程分析。
计算字段：此方法主要依靠计算字段（公式）为每个事件生成ActivityName和EventTimestamp。熟悉Freshservice公式编辑器会有所帮助。
数据量：请注意，每个事件都会生成多行数据，每项活动对应一行。对于规模较大的Freshservice实例，生成的CSV文件可能很大，从而影响报告生成和导出速度。

查询示例 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'

步骤

准备工作：确保已安装Python 3.6或更新版本，以及requests和pandas库。可使用pip安装：pip install requests pandas。
生成API密钥：以管理员身份登录Freshservice实例。点击右上角的个人头像，进入个人资料设置。找到“API Key”部分并复制个人API密钥。请像保护密码一样妥善保管此密钥。
准备脚本：将提供的Python代码保存到本地文件，命名为extract_freshservice_incidents.py。
配置参数：使用文本编辑器打开脚本文件。更新FRESHSERVICE_DOMAIN（例如'yourcompany.freshservice.com'）、API_KEY（刚复制的密钥）和START_DATE_STR（所需数据提取周期的起始日期，格式为'YYYY-MM-DD'）的占位值。
了解脚本逻辑：脚本首先获取指定起始日期之后创建的所有事件工单，并遍历API返回的每一页结果。对于每张工单，脚本会再次调用API，获取其详细活动历史。
生成事件日志：脚本处理工单核心数据及活动日志，为14项所需业务活动逐一生成记录。例如，“事件已报告”根据工单创建日期生成，“状态变更为处理中”则根据活动日志中的特定条目生成。
推导复杂事件：脚本会推导“超出SLA目标”等事件，并检查工单的解决SLA是否违反。如果违反，脚本会以due_by日期作为事件时间戳，标记违规发生的时刻。
运行脚本：打开终端或命令提示符，切换到脚本保存目录，然后运行：python extract_freshservice_incidents.py。
监控运行进度：脚本会在控制台显示进度，包括已处理的工单数量。耗时取决于工单数量和API速率限制。
检查输出：脚本运行完成后，会在同一目录下生成freshservice_incident_event_log.csv文件，其中包含完整的事件日志。
准备上传：使用电子表格程序打开CSV文件，确认各列（IncidentId、ActivityName、EventTimestamp等）均已按预期填充。之后即可将文件上传到ProcessMind或其他流程挖掘工具。

配置

FRESHSERVICE_DOMAIN：您公司的Freshservice专属网址，例如mycompany.freshservice.com。这是脚本必需的参数。
API_KEY：拥有足够权限读取所有事件数据的用户个人API密钥。这是必需参数。
START_DATE_STR：数据提取的起始日期，格式为“YYYY-MM-DD”。建议首次提取3至6个月的数据，以便开展有效分析。
PAGE_SIZE：设为100，这是Freshservice API允许的最大值，可减少API调用次数并提升性能。通常不建议更改此值。
API速率限制：脚本会在处理每张工单后调用一次基础的time.sleep(1)，以遵守Freshservice的API速率限制。对于高数据量实例，可能需要调整此设置以避免错误。
所需权限：API密钥必须属于具备至少“SD Agent”角色权限的用户账户（例如专用服务账户），以确保能够访问不同服务台组中的所有必要工单字段和活动日志。

查询示例 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()

步骤

确认您的Freshservice席位等级和管理员权限支持Workflow Automator规则、Webhook操作、事件访问及工单活动历史访问。与接收团队确认目标端点、身份验证方式、TLS要求和保留策略。
配置自动化规则前，先定义事件数据规范。每次Webhook交付使用一个JSON对象，包含IncidentId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdate、AssignedAgent、AssignedGroup、IncidentPriority、IncidentSeverity、IncidentStatus、IncidentCategory和ResolutionSlaTargetTime。配置接收端保留原始Webhook负载和交付时间戳。
为事件创建配置Workflow Automator规则。设置规则在创建事件时运行，再添加Webhook操作以发送“事件已报告”活动。将EventTimestamp设为事件创建时间戳，ActivityName设为Incident Reported。
为分配、优先级、状态、沟通、备注、SLA和关闭变更创建更新规则。根据Freshservice账户中可用的事件字段和活动历史配置条件。每项活动发生时，相应规则都必须单独发送Webhook事件。不要依赖ProcessMind根据最终事件快照推断活动。
明确配置活动映射。Group字段首次赋值时发送Incident Assigned to Group；Agent字段首次赋值时发送Agent Assigned to Incident；设置或更改Priority时发送Incident Prioritized；记录第一条符合条件的公开处理人员回复或备注时发送First Response Sent；初次分配后Agent或Group发生变化时发送Incident Reassigned；状态发生相应转换时发送Status Changed to In Progress和Status Changed to Pending；仅在存在已配置的临时解决方案标记时发送Workaround Provided；添加解决备注时发送Resolution Note Added；状态变为Resolved时发送Incident Resolved；满足已配置的SLA超时条件时发送SLA Target Breached；状态从Resolved变为未关闭状态时发送Incident Reopened；状态变为Closed时发送Incident Closed。
将Webhook请求正文设为JSON，并包含事件标识符、活动名称、事件时间戳、源系统、上次数据更新时间及建议的上下文属性。使用Freshservice账户提供的Webhook变量。如果Webhook编辑器中没有所需变量，请通过获准的Freshservice接口在接收服务中填充，或将其留空，不要自行编造。
在端点配置幂等处理和交付机制。如Freshservice提供稳定的事件标识符，请使用该标识符；否则，根据IncidentId、ActivityName、EventTimestamp和源交付标识符构造去重键。只有在负载已可靠持久化接收后，才返回成功的HTTP响应。
使用受控事件测试每条规则。创建事件，分配组和处理人员，更改优先级和状态，发送符合条件的回复，并在已配置的情况下添加临时解决方案和解决备注，然后解决、重新打开并关闭事件。另用受控策略或测试队列单独测试SLA超时。确认每项预期活动都以独立Webhook负载到达。
将Webhook负载写入可靠的暂存区，将时间戳统一为同一时区，并将每个负载展平为一行事件日志。每项明确的Webhook活动保留一行。LastDataUpdate应填写数据提取或接收刷新时间戳，而非业务事件时间戳。
验证暂存的事件日志，仅删除完全重复的交付记录，并保留多次优先级变更或状态转换等真实重复活动。确保每行均包含IncidentId、ActivityName、EventTimestamp、SourceSystem和LastDataUpdate。
将规范化后的事件日志导出为CSV或其他ProcessMind支持的格式。列名必须准确使用IncidentId、ActivityName、EventTimestamp、SourceSystem、LastDataUpdate、AssignedAgent、AssignedGroup、IncidentPriority、IncidentSeverity、IncidentStatus、IncidentCategory和ResolutionSlaTargetTime。上传文件或将准备好的事件数据源连接到ProcessMind，并将IncidentId映射为案例标识符，将ActivityName映射为活动字段。

配置

**触发范围：**为事件创建和每种更新条件分别配置Workflow Automator规则。若接收端没有严格执行活动映射，单条宽泛的更新规则可能产生重复或含义不明确的事件。
**Webhook负载：**每个负载都应包含所有必需属性，并在事件发生时纳入可用的建议属性。保留原始负载，以便审计和重放。
**活动定义：**必须区分首次分配组和处理人员与后续变更。后续变更生成Incident Reassigned，首次填写则生成相应的初始分配活动。
**状态处理：**映射Freshservice账户中配置的准确状态值。如果账户使用自定义的待处理或未关闭状态，请为这些值配置明确映射。
**首次响应：**明确公开回复、公开备注或其他沟通类型中哪些符合条件。统一应用该定义，并且每个事件仅在首次符合条件的沟通发生时生成活动。
**临时解决方案检测：**配置专用字段、复选框、备注类型或获准的关键词规则。若未进行此类配置，就无法可靠识别Workaround Provided。
**SLA超时：**配置明确的SLA超时触发条件，或单独安排流程，将当前时间与ResolutionSlaTargetTime进行比较。仅凭最终事件快照无法还原超时发生的时间戳。
**日期范围：**首次验证时，建议使用约3至6个月的事件数据。实时运行时，应在目标分析时段开始前启动数据接收，并保留Webhook历史记录以供重放。
**筛选条件：**仅应用获准的公司、工作空间、部门、服务、类别或日期筛选条件。不要假定账户配置中未提供的Freshservice字段名称或筛选语法。
**性能：**采用异步Webhook处理，将传入请求放入队列，批量写入下游数据，并为IncidentId和EventTimestamp建立索引。避免在接收Webhook时同步调用接口补充数据。
**可靠性：**配置重试、死信处理、监控和重复抑制。记录交付失败，并在问题修复后重放。
**前提条件：**管理员访问权限、可用的Workflow Automator、Webhook权限、HTTPS端点、身份验证配置、足够的Freshservice席位等级功能，以及兼容ProcessMind的数据接收或上传流程。
**安全性：**使用HTTPS，尽可能限制入站访问，定期轮换凭据，减少敏感字段，并在负载中包含事件描述和备注时妥善保护这些内容。

查询示例 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
};

准备好开始了吗？

使用此模板正确设置数据，深入了解事件管理工作流。立即开始优化事件解决时间。

返回改进指南

下载模板

避免SLA超时：立即优化事件管理

加入将平均解决时间缩短35%、避免高额SLA违约成本的企业行列。

开始免费试用

免费试用14天，无需信用卡。

您的事件管理数据模板

您的事件管理数据模板

事件管理属性

事件管理活动

数据提取指南

将Freshservice分析模块数据导出为CSV

步骤

配置

查询示例 config

通过Freshservice REST API使用Python脚本提取数据

步骤

配置

查询示例 python

通过Workflow Automator Webhook实时推送数据

步骤

配置

查询示例 config

准备好开始了吗？

避免SLA超时：立即优化事件管理