您的事件管理数据模板

Freshservice

← 返回改进指南

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

您的事件管理数据模板

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

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

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

下载模板

事件管理属性

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

5 必需 7 建议 7 可选

	名称	说明
	事件ID IncidentId	每条事件记录的唯一标识符，也是跟踪整个事件生命周期的主键。
说明 Incident ID是事件管理分析的核心。它充当Case ID，将所有相关活动、时间戳和属性变更关联为一条完整、连贯的流程路径。在流程挖掘中，每条事件日志记录都与Incident ID关联，从而重建每个事件的端到端流程。它对于计算周期时间、分析流程变体以及识别特定案例的瓶颈至关重要。没有唯一标识符，就无法区分不同事件，也无法分析事件从报告到解决的完整路径。为什么重要它能够唯一标识每个事件，实现从创建到关闭的全生命周期跟踪与分析。获取位置这是工单的主标识符，可通过Freshservice Tickets API获取，位于工单对象的“id”字段中。示例 INC-10234INC-10235INC-10236
	事件时间戳 EventTimestamp	活动或事件实际发生的准确日期和时间。
说明 Event Timestamp也称为Start Time，用于标记活动发生的准确时刻。从创建到关闭，事件生命周期中的每项活动都有对应的时间戳。该属性是所有基于时间的流程挖掘分析的关键。它用于按时间顺序排列事件、计算活动间隔时长、衡量案例总周期时间以及分析等待时间，也是构建跟踪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	事件生命周期中某一时点发生的具体业务活动或事件的名称。
说明 Activity Name描述事件管理流程中的单个步骤或事件，例如“Incident Assigned to Group”“Status Changed to Pending”或“Incident Resolved”。这些活动源自事件数据随时间发生的变化。该属性是流程挖掘的基础，决定了发现的流程图中的节点。通过分析活动的顺序和频率，组织可以直观了解实际的事件解决流程，识别常见路径，发现偏差，并定位频繁重新分配等返工循环。为什么重要它定义流程图中的步骤，支持对事件解决流程、瓶颈和偏差进行可视化与分析。获取位置该属性不是Freshservice中的直接字段，而是根据工单状态、优先级、代理或组分配以及新增备注等属性的变化推导得出。示例事件已报告事件已分配至团队已添加解决备注事件已解决
	源系统 SourceSystem	提取数据的系统，通常为“Freshservice”。
说明该属性用于标识数据来源。在此场景中，它通常固定为“Freshservice”；但在需要合并多个系统数据以获得完整流程视图的环境中，这是一个关键字段。纳入Source System是数据治理和可追溯性的最佳实践。它可以明确数据来源，有助于验证、调试，以及未来将其他服务管理或运营系统纳入流程挖掘项目。为什么重要它通过明确标识事件管理数据的来源，确保数据可追溯并支持数据治理。获取位置这通常是在数据转换（ETL）过程中添加的静态值，用于标记数据集。示例 FreshserviceFreshservice-EUFreshservice-PROD
	事件严重性 IncidentSeverity	事件的严重程度，用于表示其业务影响。
说明 Incident Severity用于衡量事件对业务的影响，通常分为Low、Medium、High或Critical。它与优先级相关，但严重程度关注影响，优先级关注紧迫性。严重程度与影响的组合通常决定最终优先级。按严重程度分析，有助于了解组织处理重大业务影响事件的能力。仪表板可按严重程度细分解决时长和SLA表现，确保影响最大的事件在整个生命周期中获得适当的关注和资源。为什么重要它衡量事件的业务影响，支持针对影响最严重问题的分析和缓解。获取位置这是Freshservice中的默认字段，可通过Tickets API的“impact”字段获取。取值为数字。示例低中高
	事件优先级 IncidentPriority	事件的优先级，用于确定响应和解决的紧迫程度。
说明 Incident Priority是决定事件处理速度和关注程度的关键字段。它通常采用Low、Medium、High和Urgent等级别，并经常用于确定SLA目标。在流程挖掘中，优先级是重要的筛选和分析维度。它支持比较高优先级与低优先级事件的解决流程，确保关键问题得到高效处理。仪表板通常按优先级细分周期时间和SLA达标情况等指标，为支持管理者提供可执行的洞察。为什么重要它有助于优先分析最关键的事件，对于评估SLA表现和资源分配至关重要。获取位置可通过Freshservice Tickets API的“priority”字段获取。取值为数字，例如1表示Low，4表示Urgent。示例低中高紧急
	事件状态 IncidentStatus	事件在生命周期中的当前状态，例如Open、Pending、Resolved或Closed。
说明 Incident Status表示事件的当前状态。状态变更是构成发现流程图基础的关键事件，例如从“In Progress”变为“Pending”，或从“Resolved”变为“Closed”。该属性是了解事件处理路径的基础。分析每种状态的停留时间，有助于识别瓶颈，例如事件在“Pending”状态等待用户响应的时间过长。它对于定义周期时间的起点和终点也至关重要。为什么重要它跟踪事件在生命周期中的进展，并帮助识别经常发生延迟的阶段。获取位置可通过Freshservice Tickets API的“status”字段获取。取值为数字。示例开放处理中待处理已解决已关闭
	事件类别 IncidentCategory	用于对事件分类的类别，例如Hardware、Software或Network。
说明 Incident Category用于根据报告问题的类型对事件进行分类。这种分层分类有助于将事件路由至正确团队，也是趋势分析的重要基础。该属性用于“Incident Categorization Accuracy”仪表板，分析初始分类错误是否因重新分配而延长解决时长。按类别分组事件后，组织可以识别反复出现的问题，了解支持工作主要集中在哪些领域，并制定有针对性的改进措施。为什么重要它支持事件趋势分析，并帮助判断错误分类是否导致解决延迟。获取位置这是Freshservice中的默认可自定义字段。可通过Tickets API的“category”字段获取，相关字段包括“sub_category”和“item_category”。示例硬件软件网络问题账户访问
	指定处理人员 AssignedAgent	当前负责解决事件的支持代理名称或ID。
说明 Assigned Agent用于标识特定时点负责处理事件的服务台员工。该属性发生变化，表示代理之间发生了责任转移。该属性对于绩效分析至关重要，可用于构建跟踪代理工作量、代理平均解决时长和首次联系解决率的仪表板。它还可用于分析代理之间的交接，因为交接可能造成延迟和效率损失。通过跟踪代理分配，管理者可以识别培训需求并发现表现优秀的团队成员。为什么重要它支持分析代理绩效、工作量分配以及代理交接对解决时长的影响。获取位置可通过Freshservice Tickets API的“responder_id”字段获取。将该ID与Agents API关联后，即可获取代理名称。示例 John DoeJane SmithSupportBot
	指定处理组 AssignedGroup	当前负责处理事件的支持组或团队。
说明 Assigned Group用于标识负责处理事件的团队，例如“Level 1 Support”“Network Team”或“Database Admins”。该属性发生变化，表示事件在不同职能团队之间升级或转移。分析Assigned Group对于了解交接和转移延迟至关重要。流程挖掘可以直观展示事件在各组之间的流转，突出常见升级路径，并衡量每个团队采取行动前的等待时间。这有助于识别组织瓶颈，并发现简化跨团队协作的机会。为什么重要它记录负责处理事件的团队，对于分析交接、升级和团队间延迟至关重要。获取位置可通过Freshservice Tickets API的“group_id”字段获取。将该ID与Groups API关联后，即可获取组名称。示例服务台网络运营基础设施支持
	解决SLA目标时间 ResolutionSlaTargetTime	根据SLA策略，事件预计应完成解决的时间戳。
说明该属性存储解决事件的截止日期和时间。该目标由应用于工单的服务级别协议（SLA）策略确定，通常取决于优先级等因素。该目标时间对于计算“SLA Adherence Rate”KPI和支持“SLA Performance Dashboard”至关重要。通过将实际解决时间戳与目标进行比较，可以判断事件是否按时解决或违反SLA。这是衡量服务级别合规情况的基础。为什么重要它提供解决截止时间，是计算SLA合规情况和识别存在风险事件的必要依据。获取位置可通过Freshservice Tickets API的“fr_due_by”（首次响应）和“due_by”（解决）字段获取。示例 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	交接次数 HandoffCount	事件在不同代理或组之间转移的次数。
说明 Handoff Count是用于量化事件在生命周期内重新分配次数的计算指标。“AssignedAgent”或“AssignedGroup”属性每发生一次变更，该计数就会增加。交接次数较多通常表明流程效率低下、初始路由错误或代理专业知识不足。该指标直接支持“Incident Handoff Count”KPI和“Handoff And Transfer Delay Analysis”仪表板，有助于识别转移过多并导致延迟的事件或流程路径。为什么重要它量化返工和重新分配情况，有助于识别因路由错误或知识缺口造成的效率问题。获取位置这是一个计算指标，通过统计单个事件生命周期内“AssignedAgent”或“AssignedGroup”字段的不同值数量或变更次数得出。示例 0125
	已提供临时解决方案 WorkaroundProvided	用于标识在最终解决方案确定前是否向用户提供了临时解决方法。
说明该布尔属性用于表示在制定永久解决方案期间，是否实施了临时修复或解决方法以减轻事件影响。它通常通过复选框或特定状态进行跟踪。在流程挖掘中，该属性支持“Workaround Effectiveness Metrics”仪表板。通过比较提供和未提供解决方法的事件的解决时长，可以判断临时修复是否有效减少业务中断，并从用户角度加快整体解决。为什么重要它有助于衡量临时解决方法在降低事件影响和加快用户感知的解决速度方面的效果。获取位置这通常是自定义布尔字段（复选框）。必须在Freshservice的“Ticket Fields”配置中确认其是否存在。示例 truefalse
	报告渠道 ReportingChannel	报告事件所使用的方式或渠道，例如Email、Portal或Phone。
说明 Reporting Channel也称为来源，用于标识事件如何进入支持系统。常见渠道包括电子邮件、自助服务门户、电话或聊天。分析该属性有助于评估不同报告渠道的效率。“Reporting Channel Efficiency”仪表板按渠道比较事件量和平均解决时长，以判断哪些方式最有效，以及哪些渠道需要改进。例如，通过门户报告的事件如果一开始就包含更结构化的信息，可能会更快得到解决。为什么重要它有助于识别最高效的报告渠道，并发现改进事件受理流程的机会。获取位置可通过Freshservice Tickets API的“source”字段获取。取值为数字。示例电子邮件门户电话聊天
	是否违反SLA IsSlaBreached	如果事件未在定义的SLA目标时间内解决，则该计算标记为true。
说明该布尔属性是一个计算指标，用于表示事件解决时长是否超过SLA目标。它通过比较实际解决时间戳与“ResolutionSlaTargetTime”得出。该标记直接用于“SLA Adherence Rate”KPI和“SLA Performance Dashboard”。它为每个事件的SLA表现提供清晰的二元结果，简化汇总和趋势分析，并帮助快速识别未达到服务承诺的事件数量和占比。为什么重要它直接衡量每个事件的SLA合规情况，便于计算整体达标率并识别问题区域。获取位置这是一个计算字段，在数据转换过程中通过比较“Incident Resolved”时间戳与“ResolutionSlaTargetTime”字段得出。示例 truefalse
	是否重新打开 IsReopened	如果事件在解决或关闭后重新打开，则该计算标记为true。
说明该布尔属性是用于识别重新打开事件的计算标记。如果事件达到“Resolved”或“Closed”状态后，状态又变回Open或In Progress，则该标记为true。该标记对于计算“Incident Reopening Rate”KPI和支持“Recurring Incidents”仪表板至关重要。重新打开率较高，可能表明初始解决质量不佳、根因分析不完整或关闭过早。分析这些案例有助于提高修复方案的质量和持久性。为什么重要它能够识别解决流程中的失效环节，突出初始修复无效并导致返工的事件。获取位置这是根据事件日志中的活动顺序推导出的计算字段。如果出现“Incident Reopened”等活动，或同一Incident ID先出现Closed状态活动、随后出现开放状态活动，则该字段为true。示例 truefalse
	根因 RootCause	调查后确定的事件根本原因或潜在原因。
说明 Root Cause属性记录导致事件发生的根本问题。支持代理通常会在解决过程中或解决后，作为根因分析（RCA）的一部分填写该信息。该属性对于“Recurring Incidents And Root Causes”仪表板和“Root Cause Analysis Completion Rate”KPI至关重要。通过分析常见根因，组织可以从被动修复事件转向主动问题管理，实施永久解决方案，防止事件再次发生并减少重复事件。为什么重要它有助于识别并消除重复事件的根本原因，从而支持主动问题管理。获取位置这通常是Freshservice中的自定义字段，因为默认功能可能有限。请在“Ticket Fields”配置中检查是否存在名为“Root Cause”或类似名称的字段。示例软件缺陷网络配置错误用户培训问题硬件故障
	请求人部门 RequestersDepartment	报告事件的用户所属部门。
说明该属性用于标识请求者所属的业务部门，例如“Sales”“Finance”或“IT”。这些信息通常来自Freshservice中的用户资料。按请求者部门分析事件，可以发现某些业务部门是否受到问题的不成比例影响，或是否存在部门特有的问题。它为理解事件的业务影响提供重要背景，也有助于优先修复影响关键部门的问题。为什么重要它提供业务背景，支持分析事件趋势及其对特定部门的影响。获取位置该信息与工单请求者关联。可使用工单中的“requester_id”访问“Requesters”API端点，然后获取“department_id”和部门名称。示例销售市场营销财务人力资源

必需建议可选

事件管理活动

以下是应纳入事件日志的关键流程步骤和里程碑，用于准确发现流程并识别瓶颈。

7 建议 7 可选

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

建议可选

提取指南

如何从Freshservice获取数据

步骤

访问Freshservice分析：使用具有访问和创建报告权限的账户登录您的Freshservice实例。从主菜单进入分析模块。
创建新报告：点击新建报告按钮。输入描述性名称，例如“事件管理事件日志”。系统提示选择数据源时，选择事件管理模块。
选择报告组件：在报告编辑器中添加新的组件，并选择表格类型。该表格将作为事件日志数据的基础。
添加主要数据列：从右侧数据源面板中，将所需字段拖放到表格的列配置中。先添加事件ID、创建时间、代理、组、优先级、严重性、状态和类别。
纳入活动数据：要捕获单个事件，必须连接或纳入工单活动数据。将活动数据源添加到组件中。从该数据源添加执行时间（作为事件时间戳）以及活动描述或其他描述变更内容的类似字段。
创建计算列“ActivityName”：这是最关键的一步。创建新的计算列或公式字段。使用嵌套IF语句或CASE函数，将原始活动数据转换为所需的ActivityName值。每项活动的详细逻辑请参阅查询部分。
配置“EventTimestamp”：为EventTimestamp创建另一个计算列。该列的逻辑应为“事件已报告”活动选择创建时间戳，为其他所有事件选择活动的执行时间戳。
应用报告筛选器：配置报告筛选器以缩小数据范围。至少应在“创建时间”字段上设置日期范围筛选器，建议选择最近3至6个月。您还应添加筛选器，仅包含“工单类型”为“事件”的工单。
运行并优化报告：运行报告生成数据预览。检查输出，确保ActivityName和EventTimestamp列已正确填充。根据需要调整公式和筛选器。
保存并导出报告：确认报告输出符合要求后，保存报告。使用导出选项，并选择CSV作为格式。
安排导出（可选）：如需持续分析，您可以安排报告自动运行和导出。设置计划（例如每天或每周），将CSV发送到您的电子邮箱或其他目标位置。
准备上传数据：打开导出的CSV文件。将列标题重命名为符合ProcessMind所需架构的名称：IncidentId、ActivityName、EventTimestamp、AssignedAgent、AssignedGroup等。添加静态列SourceSystem（值为“Freshservice”）和LastDataUpdate（值为当前时间戳）。现在即可上传该文件。

配置

Analytics模块：提取数据需要访问Freshservice Analytics模块，该模块仅在较高版本计划中提供，例如Pro、Enterprise。
所需权限：您的账户需要具备在Analytics模块中创建、编辑和运行报告的角色权限。
日期范围：必须在事件创建日期上设置日期范围筛选器，以控制数据量。建议使用滚动3至6个月的时间范围，在历史背景和性能之间取得平衡。
报告筛选器：始终筛选“Ticket Type”等于“Incident”的工单，以排除服务请求或其他工单类型，避免影响流程分析。
计算字段：该方法高度依赖计算字段（公式），为每个事件生成ActivityName和EventTimestamp。熟悉Freshservice公式编辑器会更有帮助。
数据量：请注意，每个事件都会生成多行数据，每项活动对应一行。对于规模较大的Freshservice实例，生成的CSV文件可能很大，从而影响报告生成时间和导出速度。

a 示例查询 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实例。点击右上角的个人头像，进入“Profile Settings”。打开“API Key”部分，复制您的个人API密钥。请像保护密码一样保护该密钥。
设置脚本：将提供的Python代码保存到本地计算机上的extract_freshservice_incidents.py文件中。
配置参数：使用文本编辑器打开脚本文件。更新FRESHSERVICE_DOMAIN（例如“yourcompany.freshservice.com”）、API_KEY（刚刚复制的密钥）和START_DATE_STR的占位值，其中START_DATE_STR应使用“YYYY-MM-DD”格式填写所需提取期间的开始日期。
了解脚本逻辑：脚本首先获取指定开始日期之后创建的所有事件工单，然后遍历API返回的每一页结果。对于每个工单，脚本都会再次调用API，获取其详细活动历史。
生成事件日志：脚本处理工单核心数据及其活动日志，为14项所需业务活动分别识别并创建记录。例如，“Incident Reported”根据工单创建日期生成，“Status Changed to In Progress”根据活动日志中的特定条目推导。
推导复杂事件：脚本会推导“SLA Target Breached”等事件，检查工单的解决SLA是否被违反。如果违反，则使用due_by日期作为事件时间戳，标记违规发生的时刻。
运行脚本：打开终端或命令提示符，进入保存脚本的目录，然后运行命令：python extract_freshservice_incidents.py。
监控执行过程：脚本会在控制台显示进度，包括已处理的工单数量。根据工单数量和API速率限制，执行可能需要一段时间。
检查输出：脚本完成后，会在同一目录中生成名为freshservice_incident_event_log.csv的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”角色权限，以确保能够访问不同服务台组中的所有必要工单字段和活动日志。

a 示例查询 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操作，发送Incident Reported活动。将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，尽可能限制入站访问，定期轮换凭据，减少敏感字段，并在负载中包含事件描述和备注时做好保护。

a 示例查询 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 Analytics模块数据导出为CSV

步骤

配置

a 示例查询 config

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

步骤

配置

a 示例查询 python

通过Workflow Automator Webhooks实时推送数据

步骤

配置

a 示例查询 config

准备开始了吗？

停止SLA违规：立即优化事件管理

您的事件管理数据模板

您的事件管理数据模板

事件管理属性

事件管理活动

提取指南

Freshservice Analytics模块数据导出为CSV

步骤

配置

a 示例查询 config

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

步骤

配置

a 示例查询 python

通过Workflow Automator Webhooks实时推送数据

步骤

配置

a 示例查询 config

准备开始了吗？

停止SLA违规：立即优化事件管理

我们重视您的隐私