> 持续流程改进 > 理赔处理 > Salesforce Financial Services Cloud > 数据模板

数据模板：理赔处理

Salesforce Financial Services Cloud

您的理赔流程数据模板

此模板为您有效分析理赔处理工作流程所需的核心数据提供了结构化概览。它详细说明了要收集的关键属性、要追踪的各项活动，并提供从您的 Salesforce Financial Services Cloud 提取这些数据的实用指南。利用此资源准备您的 event log，以便进行深入的 Process Mining 分析。

建议收集的属性
需要追踪的关键活动
Salesforce 金融服务云数据提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

理赔处理属性

这些是您的 event log 中建议包含的 data 字段，以便全面分析理赔流程。

5 必填 7 推荐 12 可选

	名称	描述
	理赔ID ClaimId	每个保险索赔的唯一标识符，作为流程分析的主要 case ID。
描述理赔编号是核心的案件标识符，它将单个保险理赔从提交到结案的所有活动、事件和数据点关联起来。在 Process Mining 中，此属性对于重构每个理赔的端到端旅程至关重要。它能将所有相关事件聚合为一个连贯的案例，从而实现对单个理赔的周期时间、流程变体和瓶颈进行分析。为何重要这是追踪理赔 lifecycle 的关键标识。如果没有唯一的 Claim ID，就无法将各个流程步骤连接成一个连贯的 journey 以进行分析。获取方式这通常是 Case 对象上的 'CaseNumber' 字段，或是 'Claim' (FinancialServicesCloud.Claim) 对象上的一个自定义唯一 ID field。示例 CL-00012345CL-00012346CL-00012347
	Event 时间 EventTime	指示特定活动或事件发生时间的时间戳。
描述事件时间提供了理赔生命周期中各项活动的精确日期和时间。这些时间数据对于按时间顺序排列事件和计算持续时间至关重要。在分析中，时间戳用于计算所有与时间相关的指标，包括活动间的周期时间、等待时间以及案件总时长。它们是创建动态流程动画以及识别延迟发生的时间和地点的基础。为何重要这个属性记录了每个 event 的发生时间，能够据此计算 duration，分析流程随时间变化的绩效，并识别时间维度上的瓶颈。获取方式对于状态变更，这是从对象字段历史（例如 CaseHistory）中的 'CreatedDate'。对于任务，则是 'CompletedDateTime' 或 'CreatedDate'。示例 2023-04-15T10:22:05Z2023-04-16T14:05:10Z2023-04-18T09:00:00Z
	最后数据更新 LastDataUpdate	此属性指示data最后一次从Salesforce Financial Services Cloud提取的日期和时间，为分析数据“新鲜度”提供背景。这对于dashboard用户理解分析时效性至关重要，有助管理数据及时性预期，并验证data pipelines是否按计划运行。
描述此属性指示data最后一次从Salesforce Financial Services Cloud提取的日期和时间，为分析数据“新鲜度”提供背景。这对于dashboard用户理解分析时效性至关重要，有助管理数据及时性预期，并验证data pipelines是否按计划运行。为何重要提供关键的数据时效性背景信息，确保分析师和业务用户清楚了解流程视图的最新程度。获取方式此值在执行时，由数据提取工具或 ETL 流程生成并标记到数据集上。示例 2023-10-27T02:00:00Z
	活动名称 ActivityName	在索赔生命周期中，特定业务活动或事件发生时的名称。
描述此属性描述了理赔流程中的单个步骤或里程碑，例如“索赔已提交”、“已执行初步审查”或“已发出付款”。它构成了流程图的骨干。分析活动的顺序和频率有助于识别最常见的流程路径（变体），发现与标准流程的偏差，并找出频繁重复的活动，从而指示返工。为何重要它定义了流程中的“内容”，支持流程流的可视化，并识别瓶颈、返工循环和流程变体。获取方式源自理赔/案例对象上'Status'字段的变更，或源自相关任务或事件记录的'Subject'。示例理赔提交初步审查已执行请求补充信息理赔结案
	源系统 SourceSystem	识别记录事件数据的源系统。
描述此属性说明了数据提取的源 application 或平台。对于本流程，它始终是 'Salesforce Financial Services Cloud'。尽管此属性值看似固定不变，但在数据可能从多个 system 合并的环境中，明确追踪源 system 仍是一种最佳实践。它能确保数据来源的清晰性，并有助于 data governance 和 validation。为何重要确认数据来源，这对数据治理、故障排除以及整合来自多个企业系统的数据至关重要。获取方式这通常是在 data 提取和 transformation 过程中添加的静态值，用于标记 dataset 的来源。示例 Salesforce Financial Services Cloud
	指派理赔员 AssignedAdjuster	负责处理索赔的用户或理赔员的姓名。
描述此属性标识了负责某个活动或整个索赔 case 的理赔员。它通常来源于索赔 case 的所有者或完成特定任务的人员。按理赔员分析绩效对于运营管理至关重要。“理赔员工作量与绩效”之类的 dashboard 使用此属性来追踪每位人员的索赔量、活跃 case 和周期时间，从而支持平衡的工作量分配并识别培训机会。为何重要此属性对于分析团队和个人绩效、管理工作量以及识别最佳实践或培训需求至关重要。获取方式这是 Case 或 Claim 对象上的 'OwnerId' 字段，它链接到 User 对象以获取理赔员的姓名。示例爱丽丝·约翰逊Robert SmithMaria Garcia
	提交渠道 SubmissionChannel	理赔最初提交的方式或渠道。
描述此属性指示索赔最初的报告方式，例如通过 web portal、mobile app、电话或电子邮件。提交渠道可以显著影响初始信息的质量和后续处理步骤。按提交渠道分析索赔有助于理解需求模式和不同接收方法的效率。“索赔处理量与数量”dashboard 使用此属性来追踪随着时间的推移，每个渠道的索赔数量，这可以为资源分配和技术投资决策提供依据。为何重要有助于评估不同受理渠道的效率，并了解某些渠道是否会导致更多的返工或更长的周期时间。获取方式这通常是 Claim/Case 对象上的一个自定义 picklist field，通常标记为 'Origin'（来源）或 'Channel'（渠道）。示例网络门户移动应用电话电子邮件
	理赔状态 ClaimStatus	事件发生时理赔的当前状态（例如：开放、审核中、已关闭）。
描述理赔状态能提供理赔生命周期中（例如“新建”、“调查中”、“待客户响应”或“已结案”）所处阶段的快照，是理解流程当前状态的关键属性。该属性在“未结理赔账龄报告”等运营仪表板中广泛使用，用于可视化工作量并识别长时间停滞的理赔。状态间转换分析也是定义流程图活动的主要方法。为何重要实时掌握正在处理中索赔的当前状态，有助于管理积压案件并识别停滞不前的案例。获取方式这是 Case 或 Claim 对象上的标准 'Status' 字段。示例已登记调查中已提供赔付方案已结案 - 已赔付已关闭 - 已拒绝
	理赔类型 ClaimType	保险索赔的类别，例如汽车险、财产险或责任险。
描述理赔类型是细分和分析理赔流程的关键维度。不同类型理赔通常流程各异，复杂性不同，且适用不同SLA。分析师可根据理赔类型筛选或比较绩效，以发现特定瓶颈，评估SLA合规性，并理解不同类别间的流程差异。此属性在“理赔SLA合规性概览”和“理赔拒绝原因分析”等仪表板中用于提供更具针对性的洞察。为何重要允许对理赔进行细分，以比较流程、识别特定类型的问题并定制改进方案。获取方式这通常是 Case 或 Claim 对象上的一个标准 'Type' 字段或自定义 picklist field。示例汽车房主商业财产综合责任
	索赔总额 TotalClaimAmount	保单持有人最初索赔的总金额。
描述该属性表示客户在流程启动时索赔的损失或损害总金额。此金额往往会影响理赔的复杂程度、所需的审查级别及其后续处理路径。通过分析索赔金额相关的流程 metric，可以揭示重要的模式。例如，高价值索赔可能需要更长的 cycle time、涉及更多处理步骤，或被分派给专业团队处理。这有助于设定切合实际的 SLA 并预测财务储备。为何重要为每个案件提供财务背景，以便分析索赔金额如何影响流程复杂性、持续时间及最终结果。获取方式这将是 Financial Services Cloud 中“索赔 (Claim)”对象上的一个自定义货币字段，例如 'ClaimedAmount__c'。示例 1500.0025000.50125.75
	结束时间 EndTime	标记活动完成的时间戳。用于精确计算持续时间。
描述结束时间属性记录活动完成确切时刻，与开始时间（EventTime）共同衡量活动时长。精确计算活动“处理时间”，区别于“等待时间”。这对于构建“流程步骤时长明细”dashboard、识别特定任务低效环节至关重要。为何重要支持精确计算每个活动的主动处理时间，这对区分增值时间与等待时间至关重要。获取方式源自时间戳数据。例如，如果“执行初步审查”是由状态变更触发的，那么EndTime可以是下一次状态变更的时间戳。示例 2023-04-15T11:05:30Z2023-04-16T17:20:00Z2023-04-18T09:45:12Z
	部门 Department	负责处理索赔的内部部门或团队。
描述此属性指定了负责该理赔的业务部门或团队，例如“个人险”、“商业车险”或“特殊调查组”。按部门分析流程有助于识别团队间的绩效差异，了解工作量分配情况，并找出部门特有的流程偏差或瓶颈。在“理赔 SLA 合规概览”等 dashboard 中，这个 dimension 尤其有价值，能清晰展现组织内不同部门的绩效。为何重要支持不同业务部门之间的绩效比较，帮助识别最佳实践并更有效地分配资源。获取方式这可能是 Claim/Case 对象上的一个自定义 field，也可根据 User 对象中被分配用户的 profile 或 role 进行推断。示例个人汽车理赔商业财产欺诈调查部门
	SLA 状态 SlaStatus	表明理赔案件是否在其定义的服务水平协议 (SLA) 内解决。
描述此属性为分类结果，如“已达成”或“已违反”，通过比较索赔实际完成日期（最终活动时间戳）与“SlaTargetDate”得出。作为“SLA达成率”KPI及“索赔SLA合规性概览”dashboard核心指标，它提供明确绩效标准，对合规报告和运营管理至关重要。为何重要清晰展现流程在时效性目标上的表现，这对提升客户满意度和确保合规性至关重要。获取方式计算字段：如果最终事件的'EndTime'小于或等于'SlaTargetDate'，则为'Met'，否则为'Breached'。此逻辑在数据转换期间或流程挖掘工具中应用。示例已达成已超期
	SLA 目标日期 SlaTargetDate	根据服务水平协议，索赔预期解决的截止日期。
描述 SLA目标日期是计算或手动设定的索赔结案截止期限，也是衡量及时性基准。此属性对监控客户或监管承诺履行至关重要。它是“SLA达成率”KPI和“索赔SLA合规性概览”dashboard基础，用于追踪按时解决索赔，识别未达标类型或部门。为何重要定义理赔解决时间的绩效目标，从而能够直接衡量SLA合规性。获取方式这通常是 Claim/Case 对象上的一个自定义 formula field 或 date field，根据提交日期和索赔类型计算得出。示例 2023-05-15T23:59:59Z2023-06-20T23:59:59Z2023-07-01T23:59:59Z
	保单号 PolicyNumber	与索赔相关联的保险单的唯一标识符。
描述保单号关联索赔与客户有效保单，提供承保范围、限额及保单持有人历史等背景信息。它虽非流程主要驱动，但作为关键背景数据，可用于结合索赔 data 和保单 data 进行深入分析，以识别特定保单类型与高频或复杂索赔关联。为何重要将理赔与底层保单关联，从而能够对与特定保单或承保类型相关的理赔模式进行更广泛的分析。获取方式这将是“索赔 (Claim)”对象上的一个查找字段，它引用 Financial Services Cloud 中的“保险保单 (InsurancePolicy)”对象。示例 POL-987654321POL-123456789POL-555444333
	地点 Location	与索赔或保单相关的地理位置（国家、州或地区）。
描述这个属性提供了理赔的地理位置信息，例如损失发生地所在的州或保单持有人的国家。这些数据可以从保单持有人的地址或损失详情中获取。地理分析能够揭示不同区域在理赔类型、频率和处理时间上的趋势。此外，它还可以用于评估各区域办事处的表现，并确保符合当地法规。为何重要允许对理赔进行地理区域分析，这有助于突出区域绩效差异、欺诈模式或局部事件的影响。获取方式通常从关联的“账户 (Account)”或“联系人 (Contact)”对象上的地址字段（例如 'BillingState'、'BillingCountry'）派生。示例美国加利福尼亚州英国
	客户ID CustomerId	提交理赔的客户或投保人的唯一标识符。
描述客户ID 将理赔与提交该理赔的个人或组织关联起来。在 Salesforce 中，这通常是客户或联系人对象的查找字段。此属性支持以客户为中心的理赔流程视图。它可用于分析每个客户的理赔历史、识别频繁索赔者并提供个性化服务。将理赔数据与 CRM 中的其他客户数据进行关联，以获得全面的业务视图也至关重要。为何重要支持以客户为中心的分析，帮助了解单个客户的理赔模式，并衡量理赔流程对客户关系的影响。获取方式这是 Claim/Case 对象上的一个 lookup field，它指向 Account 或 Contact 对象（例如 'AccountId' 或 'ContactId'）。示例 0018d00000abcdeFAA0018d00000fghijKLM0018d00000mnopqrSTU
	拒绝理由 ReasonForRejection	索赔被拒绝或驳回时提供的具体原因。
描述当理赔的最终决定是“已拒绝”时，此属性提供其根本原因，例如“不在保单范围内”、“疑似欺诈”或“信息不完整”。这是“理赔拒绝原因分析”dashboard 的关键属性。通过分析不同拒绝原因的频率（通常按理赔类型或部门划分），组织可以识别改进承保、澄清保单语言或增强信息收集流程以减少无效提交的机会。为何重要直接揭示理赔被拒的原因，这对于改进核保政策和减少无效索赔的资源浪费至关重要。获取方式这通常是 Claim/Case 对象上的一个自定义 picklist field，当 status 变为 'Rejected'（已拒绝）或 'Closed - Denied'（已关闭 - 拒绝）时，此 field 将变为必填项。示例保险已过期损失不在承保范围疑似欺诈重复理赔
	损失日期 LossDate	触发理赔的事故或损失发生日期。
描述损失日期记录保险单承保事件发生具体日期，异于索赔提交日。此属性对合规性及分析事件发生与报告滞后时间至关重要。大间隔可能预示潜在问题或需不同处理方式，为理解事件时间线提供宝贵背景。为何重要有助于分析事件发生与报告之间的滞后，这可能会影响调查和结案。获取方式这将是“索赔 (Claim)”对象上的一个自定义日期字段，例如 'DateOfLoss__c'。示例 2023-04-122023-05-202023-06-01
	是否自动化 IsAutomated	一个布尔标志，指示活动是由自动化系统而非人工用户执行的。
描述此 flag 用于区分由人工理赔员完成的任务，以及通过自动化 workflow、规则或 system 集成执行的任务。例如，最初的理赔登记过程可能实现完全自动化。分析自动化程度是理解流程效率的关键。它有助于衡量自动化举措的成功，识别哪些步骤是未来自动化的理想候选，并比较自动化任务与人工任务的速度和一致性。为何重要区分人工和系统驱动的活动，这对评估自动化的影响和有效性至关重要。获取方式这通常是推导而来的。如果与 event 关联的用户是通用的 'System' 或 'Integration' 用户，则此 flag 将被设为 true。示例 truefalse
	是否返工 IsRework	一个布尔标志，指示一项或一系列活动是否代表返工。
描述当理赔流程回溯到之前的阶段时，此 flag 将被设置为 true。一个典型例子是从“调查完成”返回到“请求补充信息”。识别返工的逻辑是基于流程知识来定义的。此属性是“理赔返工循环分析” dashboard 和“返工率” KPI 的关键基础。它能直接量化返工的频率和影响，而返工正是造成效率低下、成本增加和 cycle time 延长的主要原因。为何重要直接标记低效的流程循环，从而方便地量化返工并有针对性地分析其根本原因。获取方式计算字段。这是通过分析每个案例的活动序列得出的。例如，如果“活动A”之后是“活动B”，然后再次出现“活动A”，则第二次出现的“A”即为返工。示例 truefalse
	案例持续时间 CaseDuration	从单一索赔的第一个 event 到最后一个 event 所经过的总时间。也称为周期时间。
描述此 metric 衡量理赔 case 的总端到端 duration，即从最初提交到最终结案的整个时间。它计算为给定 Claim ID 的最后一个 event 的 timestamp 与第一个 event 的 timestamp 之间的差值。这是流程绩效最重要的 KPI 之一，直接体现在“平均理赔周期” KPI 和“理赔端到端周期” dashboard 中。降低此值通常是流程改进项目的主要目标。为何重要衡量流程的整体端到端效率，是客户体验的关键指标。获取方式计算字段：对于每个'ClaimId'，最后一个事件的时间戳减去第一个事件的时间戳。这由流程挖掘工具计算。示例 30天5小时15天10小时90天2小时
	活动时长 ActivityDuration	从单个活动开始到结束所经过的时间。也称为处理时间。
描述此 metric 计算单个流程步骤的 duration，代表了投入到该步骤的“活动”工作时间。它通常计算为 activity 的 End Time 与 Start Time 之间的差值。这是瓶颈分析的一项基本 metric。“流程步骤耗时明细” dashboard 依赖此计算结果来显示哪些具体 activities 耗时最多，从而有助于将改进工作集中在能够产生最大影响的环节。为何重要量化每个步骤的实际工作时间，有助于区分活跃的处理瓶颈与空闲等待时间。获取方式计算字段：'EndTime' 减去 'EventTime' ('StartTime')。此计算在流程挖掘工具中或数据转换期间执行。示例 2小时15分钟1天4小时30分钟
	赔付金额 SettlementAmount	在理赔结案时，支付给索赔人的最终金额。
描述此属性记录了理赔结案并完成结算时，实际支付给索赔人的金额。由于评估、免赔额和保单限额等因素，此金额可能与最初的索赔金额有所不同。分析结算金额，特别是将其与最初索赔金额进行比较，有助于深入了解损失评估的准确性以及结算谈判的结果。这是理解理赔总成本的一项关键财务 metric。为何重要代表索赔的最终财务影响，这对于财务分析、准备金管理和评估初始损失估算的准确性至关重要。获取方式这将是 Financial Services Cloud 中“索赔 (Claim)”对象或相关“支付 (Payment)”对象上的一个自定义货币字段。示例 1450.0022500.000.00

必填推荐可选

理赔处理活动

这些是您的 event log 中需要捕获的关键流程步骤和里程碑，以便准确发现理赔流程。

6 推荐 9 可选

	活动	描述
	付款已发出	标志着向理赔申请人实际支付款项。这是一个关键的财务事件，通常在与理赔相关的支付记录被标记为“已支付”或“已发出”时捕获。
为何重要此活动是衡量索赔履行流程收尾阶段的关键里程碑。分析从批准到支付的时间有助于优化财务运营。获取方式从相关“理赔付款”自定义对象的状态变更推断。状态变更为“已支付”或“已发送”的时间戳将表示此事件。捕获相关“索赔支付 (Claim Payment)”对象上的状态变更 timestamp。事件类型 inferred
	初步审查已执行	表示指定理赔员完成对索赔详情的首次全面审查。这通常从“索赔”对象的状态变化中推断出来，例如从“新建”变为“审核中”或“初步评估完成”。
为何重要此 milestone 标志着初始等待期的结束以及正式处理的开始。达到此步骤所需的时间是衡量理赔员工作量和受理效率的关键指标。获取方式通过“理赔”对象“状态”字段变更的时间戳推断得出，该变更通过字段历史跟踪捕获。捕获 'Status' 字段变为“审核中”或类似状态的 timestamp。事件类型 inferred
	理赔决定已下达	表示批准或拒绝索赔的官方决定。这是一个关键里程碑，通常从状态变为“已批准”或“已拒绝”等最终决定状态来推断。
为何重要这是一个决定后续流程路径的关键决策点。分析决策时间是衡量理赔员效率和 SLA 合规性的关键 KPI。获取方式通过“理赔”对象“状态”字段变为决策状态（例如“已批准”、“已拒绝”）的时间戳推断得出，该变更通过字段历史跟踪捕获。捕获 'Status' 变为“已批准”或“已拒绝”的 timestamp。事件类型 inferred
	理赔提交	标志着当新理赔首次录入 Salesforce 时，理赔流程的启动。此事件通常通过创建新的“理赔”对象记录来捕获。
为何重要这是流程的主要 start event。分析从提交到下一步的时间，有助于识别初始受理延迟，并为衡量整体 cycle time 设定 baseline。获取方式来自“理赔”标准对象的“CreatedDate”时间戳。这为每个理赔案件提供了精确可靠的起点。捕获 “索赔”对象的记录创建时间戳。事件类型 explicit
	理赔结案	标志着在所有活动（包括支付）完成后，系统内理赔的最终成功结案。这通过“理赔”对象状态最终变更为“已结案”来捕获。
为何重要这是流程的主要成功 end event。它对于计算端到端 cycle time 和衡量整体流程 throughput 至关重要。获取方式从“理赔”对象“Status”字段的字段历史跟踪推断，捕捉变更为“已结案”的时间戳。捕获 'Status' 字段变为“已关闭”的 timestamp。事件类型 inferred
	请求补充信息	表示理赔员确定需要向投保人或第三方索取更多信息的时点。这可以通过状态变为“待客户信息”或创建相关的“任务”或“电子邮件”记录来推断。
为何重要这是识别返工循环的关键 activity。此 event 频繁发生，表明初始 data 收集存在问题，从而导致流程延迟和 cycle time 增加。获取方式从“理赔”对象“Status”字段变更为“Pending Information”状态推断。或者，从特定类型的关联任务或电子邮件记录的创建日期推断。捕获 'Status' 变为“待获取信息”或相关沟通记录创建的 timestamp。事件类型 inferred
	已提供赔付方案	表明已正式向索赔人提供了赔付金额。这可以通过状态变更为“已提供赔付”或创建沟通记录来捕捉。
为何重要此活动启动了最终的协商或确认阶段。可以分析索赔人回应所需的时间，以改进沟通策略并缩短流程的最后阶段。获取方式从“理赔”对象“Status”字段的变更推断。也可以从代表要约函的关联“EmailMessage”或“Document”记录的创建日期捕捉。捕获 'Status' 变为“已提供和解方案”的 timestamp。事件类型 inferred
	损失已评估	表明损失的财务影响已评估并记录。此事件可以从“理赔”对象上的“Loss Estimate”或“Settlement Amount”字段首次被填充值时推断出来。
为何重要此活动是一个关键的财务里程碑。追踪这项活动发生的时间有助于了解财务评估中的延误，这可能在做出最终决定前形成瓶颈。获取方式从“理赔”对象上货币字段（例如“Loss_Estimate__c”）的字段历史跟踪推断，使用从空值或零值首次更新的时间戳。捕获财务评估字段首次填充的 timestamp。事件类型 inferred
	支付已授权	表示赔付金额已获得内部批准并准予支付。这可能是一个来自相关“支付请求”对象的明确事件，或是一个推断出的状态变更，例如“已批准付款”。
为何重要这是一个关键的内部控制点。决策与支付授权之间的延迟可能预示着财务审批 workflow 中存在瓶颈。获取方式通过“理赔”对象“状态”字段变更的时间戳推断得出。更准确地说，它是相关“理赔款”或类似自定义对象的“创建日期”。捕获 “索赔支付”对象的记录创建时间戳。事件类型 explicit
	收到补充信息	标志着收到所请求的信息，允许理赔处理恢复。这通常通过“理赔”对象状态从“待定”状态变回“审核中”等活跃状态来推断。
为何重要 “信息请求”与“信息接收”之间的时间往往是一个重要的瓶颈。分析此持续时间有助于理解外部依赖性以及沟通的有效性。获取方式通过“理赔”对象“状态”字段的字段历史跟踪推断得出，捕获其从“待补充信息”变为活跃状态的时间戳。捕获 'Status' 字段从待处理状态改变的 timestamp。事件类型 inferred
	理赔指派	表明理赔案件已分配给特定的理赔员或团队进行处理。这是通过跟踪“理赔”对象上的“OwnerId”字段何时被填充或从队列变更为用户来捕捉的。
为何重要追踪任务分配对于分析资源 workload，并在理赔员开始工作前识别延迟至关重要。这有助于衡量理赔在队列中等待被主动处理的时间。获取方式来自“理赔”对象“OwnerId”字段的字段历史跟踪。从队列分配给特定用户的时间戳标志着此事件。捕获 'OwnerId' 字段从队列变为用户的 timestamp。事件类型 inferred
	理赔登记	表示索赔在初始数据录入后，在系统中得到正式确认和注册。这通常从“索赔”对象的状态变化中推断出来，例如从“草稿”变为“新建”或“已提交”。
为何重要此活动确认索赔已正式进入处理队列。提交与注册之间的时间可以揭示出初始 data 验证或接收团队中的积压。获取方式从“理赔”对象“Status”字段的字段历史跟踪推断，捕捉变更为注册状态（例如“New”、“Open”）的时间戳。捕获 'Status' 字段变为“新建”或“已登记”的 timestamp。事件类型 inferred
	理赔驳回	代表被拒绝索赔的最终结果。这是一个结束事件，当“索赔”对象的状态更新为“已拒绝”时捕获。
为何重要这是流程的一个终结状态，有别于成功的结案。分析被拒理赔及其原因，可以为改进承保或初步筛选流程提供宝贵见解。获取方式通过“理赔”对象“状态”字段变为“已拒绝”的时间戳推断得出。“拒绝原因”属性可从相应字段中获取。捕获 'Status' 字段变为“已拒绝”的 timestamp。事件类型 inferred
	调查已完成	表示索赔证据收集和分析阶段的结束。这通常从状态从“调查进行中”变为“待定决策”或类似状态来推断。
为何重要此 milestone 标志着调查 sub-process 的结束。它使得调查 cycle time 能够精确衡量，从而有助于优化这个关键阶段。获取方式从“理赔”对象“Status”字段的字段历史跟踪推断，捕捉从调查状态变更的时间戳。捕获 'Status' 字段从“调查中”变更的 timestamp。事件类型 inferred
	调查已开始	表明理赔案件详细调查阶段的正式开始。此事件是从“理赔”对象状态变更为“调查进行中”等状态时推断出来的。
为何重要此活动定义了一个关键且通常耗时较长的子流程的开始。衡量调查周期时间对于识别证据收集和分析中的瓶颈至关重要。获取方式通过“理赔”对象“状态”字段变更的时间戳推断得出，该变更通过字段历史跟踪捕获。捕获 'Status' 字段变为“调查中”的 timestamp。事件类型 inferred

推荐可选

提取指南

如何从 Salesforce 金融服务云获取您的数据

步骤

前提条件设置：确保您已安装 Python 3.6+。使用 pip 安装所需库：pip install simple-salesforce pandas。
Salesforce API 访问：确认您拥有已启用 API 访问权限的 Salesforce 用户账户。您将需要您的用户名、密码和安全令牌。强烈建议使用专用的仅限 API 用户以提高安全性。
准备 Python 脚本：创建一个新的 Python 文件（例如 extract_claims_log.py），并将 query 部分提供的完整脚本复制到此文件中。
配置脚本参数：打开脚本并修改顶部的占位符变量。这包括您的 Salesforce 凭据（SF_USERNAME、SF_PASSWORD、SF_TOKEN）、数据抽取日期范围（START_DATE、END_DATE），以及您特定 Salesforce 对象和字段的 API 名称（例如 CLAIM_OBJECT_API_NAME、STATUS_FIELD_API_NAME）。
定义活动映射：审查脚本中的 STATUS_TO_ACTIVITY_MAP dictionary。这对于将您的特定 Salesforce 状态值转换为流程挖掘所需的标准化活动名称至关重要。调整键（您的 Salesforce 状态）以匹配您的系统配置。
执行脚本：从您的终端运行脚本，使用命令：python extract_claims_log.py。脚本将连接到 Salesforce，执行必要的 SOQL 查询，并开始处理 data。
监控执行：脚本包含打印语句以显示进度，例如获取的理赔数量和生成的 event 数量。对于大量 data，这可能需要几分钟。
审查输出文件：脚本成功完成后，将在同一目录下生成一个名为 claims_event_log.csv 的 CSV 文件。
数据验证：在电子表格程序中打开 CSV 文件。执行 validationSteps 部分中概述的检查，以确保 data 在上传前完整且准确。
准备上传：生成的 CSV 文件格式正确，可直接上传到流程挖掘工具。确保列标题（ClaimId、ActivityName、EventTime 等）与目标系统要求完全一致。

配置

Salesforce Connected App：在生产环境中，建议使用带有 OAuth 2.0 的 Salesforce Connected App 进行身份验证，而非用户名/密码。可调整脚本以采用此方法，从而增强安全性。
API 用户权限：执行数据抽取的 Salesforce 用户必须至少拥有对脚本中指定的所有对象和字段的“读取”访问权限，包括主要理赔对象（例如 Claim__c）、其历史对象（Claim__History）以及任何相关对象（例如 User）。
日期范围（START_DATE, END_DATE）：设置特定且合理的日期范围以控制数据量。通常，初步分析会抽取 3-6 个月的数据。避免范围过宽，以防触及 API 限制并导致耗时过久。
对象和字段映射：脚本使用 CLAIM_OBJECT_API_NAME、STATUS_FIELD_API_NAME 等占位符。您必须将这些占位符映射到您的 Salesforce Financial Services Cloud 实例中使用的实际 API 名称。请使用 Salesforce“设置”中的“Object Manager”查找正确的 API 名称。
API 版本：simple-salesforce 库允许指定 API 版本。脚本默认使用最新版本，但如果您的集成有此要求，您可以将其设置为特定版本（例如 sf = Salesforce(..., version='58.0')）。
批量处理：对于非常大的数据集（数百万条记录），可能需要修改脚本，分批处理理赔以管理内存使用并避免 API 超时。

a 查询示例 python

`python
import pandas as pd
from simple_salesforce import Salesforce
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Salesforce Credentials (use environment variables or a secure vault in production)
SF_USERNAME = class="hl-string">'[your_salesforce_username]'
SF_PASSWORD = class="hl-string">'[your_salesforce_password]'
SF_TOKEN = class="hl-string">'[your_salesforce_security_token]'

class=class="hl-string">"hl-comment"># Date Range for Extraction (ISO 8601 format)
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'

class=class="hl-string">"hl-comment"># Salesforce Object & Field API Names (REPLACE with your FSC configuration)
CLAIM_OBJECT_API_NAME = class="hl-string">'Claim__c' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'Case', class="hl-string">'Claim__c'
CLAIM_ID_FIELD = class="hl-string">'Name' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'CaseNumber', class="hl-string">'Name'
STATUS_FIELD_API_NAME = class="hl-string">'Status__c' class=class="hl-string">"hl-comment"># e.g., class="hl-string">'Status', class="hl-string">'ClaimStatus__c'
OWNER_ID_FIELD = class="hl-string">'OwnerId'
CREATED_DATE_FIELD = class="hl-string">'CreatedDate'
LOSS_ESTIMATE_FIELD = class="hl-string">'Loss_Estimate__c' class=class="hl-string">"hl-comment"># Field for class="hl-string">'Loss Assessed' event
CLAIM_TYPE_FIELD = class="hl-string">'Claim_Type__c'
SUBMISSION_CHANNEL_FIELD = class="hl-string">'Submission_Channel__c'
TOTAL_CLAIM_AMOUNT_FIELD = class="hl-string">'Total_Claim_Amount__c'

class=class="hl-string">"hl-comment"># Map your Salesforce status values to standardized Activity Names
class=class="hl-string">"hl-comment"># CRITICAL: This mapping must be configured for your specific Salesforce setup
STATUS_TO_ACTIVITY_MAP = {
    class="hl-string">'New': class="hl-string">'Claim Registered',
    class="hl-string">'Under Review': class="hl-string">'Initial Review Performed',
    class="hl-string">'Pending Customer Information': class="hl-string">'Additional Information Requested',
    class=class="hl-string">"hl-comment"># Use a generic class="hl-string">'Under Review' for info received, as SF history doesn't track the *reason* for a status change
    class=class="hl-string">"hl-comment"># The sequence will show class="hl-string">'Pending' -> class="hl-string">'Under Review', implying receipt of information.
    class="hl-string">'Investigation in Progress': class="hl-string">'Investigation Started',
    class="hl-string">'Pending Decision': class="hl-string">'Investigation Completed',
    class="hl-string">'Approved': class="hl-string">'Claim Decision Made',
    class="hl-string">'Settlement Offered': class="hl-string">'Settlement Offered',
    class="hl-string">'Approved for Payment': class="hl-string">'Payment Authorized',
    class="hl-string">'Paid': class="hl-string">'Payment Issued',
    class="hl-string">'Rejected': class="hl-string">'Claim Rejected',
    class="hl-string">'Denied': class="hl-string">'Claim Rejected',
    class="hl-string">'Closed': class="hl-string">'Claim Closed'
}

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Connecting to Salesforce...")
    sf = Salesforce(username=SF_USERNAME, password=SF_PASSWORD, security_token=SF_TOKEN)
    print(class="hl-string">"Connection successful.")

    class=class="hl-string">"hl-comment"># 1. Fetch all relevant claims to get base attributes and created date
    print(fclass="hl-string">"Fetching claims created between {START_DATE} and {END_DATE}...")
    claim_query = fclass="hl-string">"""
        SELECT 
            Id, {CLAIM_ID_FIELD}, {CREATED_DATE_FIELD}, {OWNER_ID_FIELD}, Owner.Name,
            {CLAIM_TYPE_FIELD}, {DEPARTMENT_FIELD}, {SUBMISSION_CHANNEL_FIELD}, {TOTAL_CLAIM_AMOUNT_FIELD}, {STATUS_FIELD_API_NAME}
        FROM {CLAIM_OBJECT_API_NAME}
        WHERE {CREATED_DATE_FIELD} >= {START_DATE} AND {CREATED_DATE_FIELD} <= {END_DATE}
    """
    claim_results = sf.query_all(claim_query)
    claims_df = pd.DataFrame(claim_results[class="hl-string">'records']).drop(columns=[class="hl-string">'attributes'])
    if claims_df.empty:
        print(class="hl-string">"No claims found for the specified date range. Exiting.")
        return

    class=class="hl-string">"hl-comment"># Create a lookup dictionary for claim attributes
    class=class="hl-string">"hl-comment"># Handle nested Owner.Name structure
    if class="hl-string">'Owner' in claims_df.columns:
        claims_df[class="hl-string">'AssignedAdjuster'] = claims_df[class="hl-string">'Owner'].apply(lambda x: x[class="hl-string">'Name'] if x else None)
        claims_df = claims_df.drop(columns=[class="hl-string">'Owner'])
    claims_lookup = claims_df.set_index(class="hl-string">'Id').to_dict(class="hl-string">'index')
    claim_ids = tuple(claims_df[class="hl-string">'Id'].unique())

    print(fclass="hl-string">"Found {len(claim_ids)} claims. Now fetching history...")

    class=class="hl-string">"hl-comment"># 2. Fetch all field history for the identified claims
    history_query = fclass="hl-string">"""
        SELECT ParentId, Field, OldValue, NewValue, CreatedDate
        FROM {CLAIM_OBJECT_API_NAME}History
        WHERE ParentId IN {claim_ids}
        ORDER BY CreatedDate ASC
    """
    history_results = sf.query_all(history_query)
    history_df = pd.DataFrame(history_results[class="hl-string">'records']).drop(columns=[class="hl-string">'attributes'])

    class=class="hl-string">"hl-comment"># 3. Generate event log from claims and history data
    event_log = []
    extraction_timestamp = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for claim_id, claim_data in claims_lookup.items():
        class=class="hl-string">"hl-comment"># Event: Claim Submitted
        event_log.append({
            class="hl-string">'ClaimId': claim_data.get(CLAIM_ID_FIELD),
            class="hl-string">'ActivityName': class="hl-string">'Claim Submitted',
            class="hl-string">'EventTime': claim_data.get(CREATED_DATE_FIELD),
            class="hl-string">'AssignedAdjuster': claim_data.get(class="hl-string">'AssignedAdjuster'),
            class="hl-string">'ClaimStatus': class="hl-string">'Submitted', class=class="hl-string">"hl-comment"># Initial status at creation
            class="hl-string">'ClaimType': claim_data.get(CLAIM_TYPE_FIELD),
            class="hl-string">'SubmissionChannel': claim_data.get(SUBMISSION_CHANNEL_FIELD),
            class="hl-string">'TotalClaimAmount': claim_data.get(TOTAL_CLAIM_AMOUNT_FIELD)
        })
        
        class=class="hl-string">"hl-comment"># Filter history for the current claim
        claim_history = history_df[history_df[class="hl-string">'ParentId'] == claim_id]

        for _, row in claim_history.iterrows():
            activity_name = None
            
            class=class="hl-string">"hl-comment"># Map status changes to activities
            if row[class="hl-string">'Field'] == STATUS_FIELD_API_NAME:
                activity_name = STATUS_TO_ACTIVITY_MAP.get(row[class="hl-string">'NewValue'])
                class=class="hl-string">"hl-comment"># Special handling for class="hl-string">'Additional Information Received'
                if activity_name == class="hl-string">'Initial Review Performed' and row[class="hl-string">'OldValue'] == class="hl-string">'Pending Customer Information':
                    activity_name = class="hl-string">'Additional Information Received'

            class=class="hl-string">"hl-comment"># Event: Claim Assigned
            elif row[class="hl-string">'Field'] == class="hl-string">'Owner':
                activity_name = class="hl-string">'Claim Assigned'
            
            class=class="hl-string">"hl-comment"># Event: Loss Assessed
            elif row[class="hl-string">'Field'] == LOSS_ESTIMATE_FIELD and row[class="hl-string">'OldValue'] is None and row[class="hl-string">'NewValue'] is not None:
                activity_name = class="hl-string">'Loss Assessed'

            if activity_name:
                event_log.append({
                    class="hl-string">'ClaimId': claim_data.get(CLAIM_ID_FIELD),
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': row[class="hl-string">'CreatedDate'],
                    class="hl-string">'AssignedAdjuster': claims_lookup.get(claim_id, {}).get(class="hl-string">'AssignedAdjuster'),
                    class="hl-string">'ClaimStatus': row[class="hl-string">'NewValue'] if row[class="hl-string">'Field'] == STATUS_FIELD_API_NAME else claims_lookup.get(claim_id, {}).get(STATUS_FIELD_API_NAME),
                    class="hl-string">'ClaimType': claims_lookup.get(claim_id, {}).get(CLAIM_TYPE_FIELD),
                    class="hl-string">'SubmissionChannel': claims_lookup.get(claim_id, {}).get(SUBMISSION_CHANNEL_FIELD),
                    class="hl-string">'TotalClaimAmount': claims_lookup.get(claim_id, {}).get(TOTAL_CLAIM_AMOUNT_FIELD)
                })
    
    if not event_log:
        print(class="hl-string">"No events generated. Check history tracking and status mappings. Exiting.")
        return

    class=class="hl-string">"hl-comment"># 4. Final Transformation and Export
    final_df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Add remaining required columns
    final_df[class="hl-string">'SourceSystem'] = class="hl-string">'SalesforceFSC'
    final_df[class="hl-string">'LastDataUpdate'] = extraction_timestamp
    final_df[class="hl-string">'EndTime'] = final_df[class="hl-string">'EventTime'] class=class="hl-string">"hl-comment"># Set EndTime equal to EventTime for point-in-time events
    final_df[class="hl-string">'Department'] = None class=class="hl-string">"hl-comment"># Placeholder - populate if available

    class=class="hl-string">"hl-comment"># Reorder columns to a standard event log format
    column_order = [
        class="hl-string">'ClaimId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AssignedAdjuster', class="hl-string">'ClaimStatus', class="hl-string">'ClaimType', class="hl-string">'Department',
        class="hl-string">'SubmissionChannel', class="hl-string">'TotalClaimAmount'
    ]
    final_df = final_df[[col for col in column_order if col in final_df.columns]]
    
    class=class="hl-string">"hl-comment"># Sort by case and time
    final_df = final_df.sort_values(by=[class="hl-string">'ClaimId', class="hl-string">'EventTime']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Export to CSV
    output_filename = class="hl-string">'claims_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
    print(fclass="hl-string">"Successfully generated event log with {len(final_df)} events.")
    print(fclass="hl-string">"File saved as: {output_filename}")

if __name__ == class="hl-string">'__main__':
    class=class="hl-string">"hl-comment"># Added placeholders for fields not explicitly requested but common and needed for the script logic
    DEPARTMENT_FIELD = class="hl-string">'[Your_Department_Field__c]'
    main()
`

数据模板：理赔处理

您的理赔流程数据模板

理赔处理属性

理赔处理活动

提取指南

使用 simple-salesforce 和 pandas 进行 Python 脚本提取

步骤

配置

a 查询示例 python

准备好开始了吗？

终结理赔积压：立即实现更快的处理速度