--- schema_version: "1" id: 8227ea1359bb55f14595dbc3c53e62a9742d59ee1a0065d27cbdf77567cee330 title: Field Service 的架构模式：大规模优化承包商共享和可见性 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/fundamentals/guides/field-service-contractor-sharing-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/fundamentals/guide/field-service-contractor-sharing-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 316c2c27e5d008c98ebb4e86859afaa2df6192035594b8390d81ed7663eec1d8 products: - 基本知识 - Architect Site Content Repo updated_at: 2026-07-01T00:00:00Z --- ## 执行摘要 在大规模 Salesforce Field Service (SFS) 环境中，管理外部承包商网络需要在平台安全性和计划性能之间保持微妙的平衡。本指南比较了两种主要的架构模式：传统的**基于区域**的模式和新的基于**客户的共享**模式，用于管理外部承包商的访问和管理。在本文中，我们将深入审查这两种情况，以帮助组织选择最能支持其业务目标的基础结构，并了解每种选择的权衡。 此模式选择会影响计划效率、资源利用率和调度人员的效率。通过选择正确的方法，公司可确保内部员工和外部合作伙伴的无缝体验，同时保持其解决方案的长期可扩展性。 除了眼前的运营收益之外，这一基本选择决定了组织对自主服务的准备程度。基于客户的共享模式提供了 Agentforce 所需的统一数据可见性，特别是适用于 Field Service 的计划客服人员，以便执行整体评估，而不受人工数据孤岛的限制。基于客户的共享还使 Data Cloud 能够更有效地聚合承包商绩效指标，允许无缝竞争基准测试，同时保持多供应商环境中所需的严格数据隔离。 ### 外卖 - **根据竞争重叠选择您的模式。**如果外部承包商与共享区域的内部或其他外部资源竞争，基于客户的共享可能是架构正确的选择。基于区域的共享仅在合同工获得专属、不重叠的服务区域/工作时适用。 - **避免区域扩展。**创建专用承包商区域以在不必要时实现数据隔离会引入层次结构臃肿，从而降低计划效率和性能，并显著增加大规模管理开销。基于客户的共享消除了这一问题模式。 - **为 AI 驱动的计划奠定基础。**当 Field Service 的计划客服人员和优化引擎具有完全的资源池可见性时，它们将有更好的性能。基于区域的共享孤立结构防止了这种情况；基于客户的共享是所需的架构基础。 ## 简介 - 承包商网络的演变 在过去十年中，现场服务的承包商网络已经从内部团队的临时扩展发展到包括电信、公用事业、家庭服务等在内的各个行业的战略性、精心构建的生态系统。现在，许多现场操作依赖于合同工和全职员工，需要明确的访问、可见性和调度规则。 随着组织在 Salesforce Field Service 上的扩展，他们设计和管理这些外部资源的方式（无论是通过区域样式模式、以客户为中心的共享还是混合方式）直接决定了他们可以如何在混合的员工中安全高效地安排工作。 ## 受众 本指南面向负责 Salesforce Field Service 实施的设计、性能和可扩展性的技术和战略利益相关者： - **解决方案和技术架构师：**评估不同共享模式对计划和优化效率的影响。 - **Field Service 运营领导：**了解不同合同工角色之间的权衡，例如命名合同工、合同工公司和临时工。 - **Salesforce 管理员：**深入了解如何使用服务区域和平台共享表来管理复杂的安全要求。 ## 定义 SFS 承包商 范围中的合同工角色直接决定了适当的共享架构。每个类别对如何构建记录级访问权限、优化器如何感知资源可用性以及解决方案如何扩展都有不同的含义： - **命名承包商：**待遇与内部员工相似的单个外部资源。命名承包商需要专用用户许可证。共享模式反映了内部技术人员的访问模式，使其成为支持的复杂性最低的合同工角色。 - **承包商公司：**管理自有员工的第三方实体。在 SFS 中，承包商公司表示为基于工作量的资源，母公司在其中将工作安排和分配到公司，而不是特定个人。 - **临时工：**临时跨多个区域操作的用户。架构最复杂的角色。瞬态、多区域关系意味着基于区域的共享边界被打破，因此可见性是在记录级别动态管理的，而不是通过静态地理分配。 ## 了解承包商的复杂性 ### 为什么承包商管理很复杂 这些模式很复杂，因为母公司和承包商的目标在技术上常常不一致。 1. **不同目标：**母公司主要关注客户满意度和合同工作/协议（例如，资源首选项、快速及时的服务，以及如何在合同工之间分配工作和时间）。相比之下，承包商通常专注于最大化分配的工作，同时最小化出行时间和运营成本。 2. **竞争：**与内部员工不同，不同的承包商公司往往是直接竞争对手。虽然母公司需要区域的整体视图（透明度），但承包商需要彼此严格隔离（隔离）。 3. **品牌完整性：**对于最终客户，员工代表您的品牌，这通常需要母公司查看实时状态更新。然而，承包商通常在一个封闭的系统（即“黑匣子”）中保卫他们的内部运营。 4. **可见性和安全性：**虽然共享服务区域通常意味着所有已分配资源的普遍可见性，但多承包商环境需要更细致的安全模式。为了保持竞争完整性和数据隐私，必须防止承包商访问彼此的专有名称、时间表或资源信息。 ### 核心趋势 - 透明度和隔离 | 角色 | 要求 | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **本组织** | 需要对所有技术人员（包括外部（合同工）和内部技术人员）的可见性，并希望计划和优化引擎将它们结合起来进行完全的区域优化。 | | **承包商** | 作为封闭系统或“黑匣子”运行，以保护专有运营，并需要严格隔离在同一地区运营的竞争对手或组织的内部技术人员。 | | **挑战** | 设计一个系统，为组织提供效率和透明度，同时保持合作伙伴所需的可见性和访问权限。 | ### 承包商复杂性矩阵 Salesforce Field Service 中的合同工设计跨越三种不同的运营模型，每种模型都影响资源可见性、派遣所有权和许可： 1. 外部容量分配 2. 合作伙伴自计划 3. 内部领导的派遣 **外部容量分配（平台外容量）：**承包商在外部管理员工，并提供定义的能力（例如 10 个可用小时），而不是单个技术人员的计划。出于计划目的，此容量被视为小时或工作项目的存储桶。 **合作伙伴自计划：**合同工经理通过体验站点登录 Salesforce，以安排自己的团队。他们需要与其他合作伙伴严格隔离。 **内部领导派遣：**内部调度人员直接安排合同工技术人员。承包商使用 Field Service 移动应用程序执行。 :::warning 内部调度人员需要完整的 SFS 许可证。此模型中的合同工技术人员仅需要 Field Service Mobile 许可证（或具有移动访问权限的社区许可证）。 ::: | 维度 | 外部容量分配 | 合作伙伴自计划 | 内部领导的派遣 | | ----------------------- | ---------------------------- | -------------------------- | -------------------------------------------------------- | | **资源可见性** | 仅容量 | 合作伙伴拥有 | 完整内部 | | **谁派遣** | 承包商（外部） | 承包商（在 Salesforce 中） | 内部调度人员 | | **Salesforce 许可证** | 最小值 | Experience Cloud | 完整 SFS（调度人员）；社区（合同工技术人员） | ### 范围中的模式 | 模式名称 | 描述 | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **基于区域的共享** | 承包商被分配到专用的隔离服务区域。记录可见性由区域成员关系控制。每个承包商公司或小组都在硬性地理边界内运营。 | | **基于客户的共享** | 承包商在标准地理区域结构中与内部/其他外部资源并肩运营。记录级可见性由共享规则控制，启用统一资源池。 | ## 共享和可见性 - 基于区域的共享 在此模式中，**服务区域**充当主要安全边界。每个承包商公司都被分配到自己唯一的“子”区域。 ![基于区域的共享层次结构，显示具有三个子区域的父区域，每个子区域分配给具有各自资源的不同承包商公司](https://architect.salesforce.com/ns-assets/territory-based-sharing-hierarchy.png) ### 常见用例 - 小规模合作伙伴网络 - 地理区域严格不重叠的合作伙伴 - 承包商工作与内部资源工作根本不同的情况，消除了竞争（例如，外部承包商仅处理“A 型安装”，而内部资源处理所有其他工作类型） ### 优势 - **简化配置：**使用标准用户区域设置和自动化。 - **清除数据存储：**确保通过标准服务区域对象轻松查看数据并简化安全管理。 ### 缺点和技术债务 - **优化效率：**该引擎无法评估跨区域边界的资源，从而阻止了优化计划和高效路由。 - **区域蔓延：**为很少的资源创建大量区域会导致计划开销。 - **甘特图性能：**大型层次结构（1K 以上区域）会导致严重的性能瓶颈以及达到平台限制的风险。 ## 共享和可见性 - 基于客户的共享 本指南介绍了一种新的解决方案方法：基于**客户的共享**(通过 Salesforce 的本地基于条件的共享规则实施，该平台机制用于根据字段值授予记录访问权限 ) 。基于客户的共享将**可见性**与**地理位置**分离。区域仍然很大并且连续，而可视性是通过基于客户关系的平台共享表来管理的。实际上，基于条件的共享规则会评估记录中的字段（例如`ServiceResource.Company`），并自动与适当的小组共享该记录。基于条件的共享是一个引擎，它使基于客户的共享在没有记录级别的自定义代码的情况下工作。 ![基于客户的共享模式，显示单个父区域，其中包含在同一区域运营的不同承包商(A、B、C)的多个服务资源，并通过共享规则管理可见性](https://architect.salesforce.com/ns-assets/account-based-sharing-model.png) ### 常见用例 - 很大一部分劳动力由外部资源组成的大规模生态系统 - 多个承包商使用相同邮政编码的城市地区 - 内部和外部资源都能够执行相同工作的场景（例如，“类型 A 安装”），但业务规则规定了资源选择的特定逻辑（例如，在某些情况下，内部资源首选项） ### 优势 - **最大利用率和投资回报率：**该引擎评估整个区域池，为每个作业找到“最佳”资源 - **可扩展性：**支持大量承包商/外部资源，而不增加区域计数 - **综合管理：**内部员工管理一个视图，而不是数百个孤立的文件夹（子区域） ### 缺点和技术债务 - **发展努力：**需要自定义自动化（流或 Apex）来管理共享表 - **成员共享：**需要明确共享服务区域成员 (STM) 记录 :::tip **可扩展性影响** 在没有统一区域池的情况下管理大量承包商合作伙伴的组织通常面临覆盖范围缺口，其中最近的技术人员对计划逻辑不可见，因为每个合作伙伴都在一个地理和管理孤岛中管理。通过迁移到统一池（基于客户的共享），组织可以通过整体计划减少 20% 以上的出差时间，并通过在整个资源池中确定最近的可用技术人员来加快服务时间。 ::: ## 基于工作量的资源 对于外部员工(外部容量分配维度 ) , 架构师可以使用基于[**容量的资源**](https://help.salesforce.com/s/articleView?id=service.fs_define_resource_capacity.htm&type=5)来表示承包商员工的"汇总 " 。 ### 何时使用容量与个人 - **容量：**当承包商管理自己的调度和路线时，请使用它。您主要关注的是他们可以完成的总工作量，而不是执行的具体人员。 - **个人：**当您需要详细了解技术人员的一天时，请使用此选项。基于个人的资源允许您像管理内部员工一样管理他们的确切位置、实时可用性和特定的工作分配。 ## 承包商共享模式选择 在设计 Field Service 承包商模式之前，使用此决策树来确定适当的共享架构。 **承包商共享模式选择决策树** ![在 Salesforce Field Service 中选择合同工共享模式的决策树流程图，从外部资源是否正在使用开始，通过资源类型和作业独占性进行分支，以推荐基于区域或基于客户的共享](https://architect.salesforce.com/ns-assets/decision-tree-contractor-sharing.png) 在 Salesforce Field Service 中选择承包商共享模式的_决策树。从是否正在使用外部资源开始，树通过资源类型和作业独占性来推荐基于区域的共享或基于客户的共享。_ ### 选择正确模式 | 基于区域的共享 | 基于客户的共享 | | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | 具有排他性、非竞争性工作分配的外部资源 | 与内部或其他外部资源竞争的命名外部资源 | | 与同一地理区域的其他外部合作伙伴没有重叠 | 在同一地理区域内运营的多个合作伙伴 | | 复杂性更低；实施和维护速度更快 | 复杂性更高；实施和维护记录级可见性需要额外的步骤 | ## 实施指导 - 基于客户的共享逻辑 此模式的核心是将`ServiceResource.AccountId`或`ServiceResource.Company`（承包商公司）关系转换为平台共享记录的自动化层。 ### 访问的三大支柱 要验证调度人员和服务资源在体验站点中的正确访问权限，需要通过以下方式控制访问权限： - **服务资源共享规则：**根据条件授予访问权限（客户/公司） - **服务区域共享规则：**根据条件（区域名称/ID）授予访问权限 ## 高级注意事项 - 移动工作人员体验 在使用基于客户的共享时，请确保考虑已分配技术人员的 **Field Service Mobile 体验**和记录可见性。 - **已分配资源共享：**标准 SFS 功能会自动授予已分配资源对服务预约及其父工作订单的访问权限。此设置为技术人员提供了执行任务所需的必要信息，而无需为分配的工作添加额外的自定义共享规则。 - **可见性风险：**在本机处理已分配工作时，请谨慎对待没有客户或区域关联的未分配或未来预约。如果组织范围的默认值 (OWD) 未严格管理，或者共享集过于宽泛，则未分配的预约可能对整合区域中的所有用户可见。 - **客户-区域关联：**确保所有服务预约都明确链接到客户和区域。这种链接允许在移动应用程序中进行干净的筛选，并验证区域池中未分配的工作不会发生数据泄露。 ## 实际业务场景 ### 场景 1 - 城市中心 - **要求：**10 个不同的承包商在伦敦提供光纤安装。 - **上下文：**在基于区域的共享方法中，伦敦将分为 10 个重叠的区域。调度人员很难看到附近的可用性，导致出行时间过长。 - **建议：****基于客户**的共享。实施统一的“大伦敦”服务区域，利用基于客户的共享来保持精细的数据安全性。基于客户的共享使合同工 A 的管理与各自的资源保持孤立，而 SFS Optimizer 保持所有内部和外部技术人员的跨职能可见性。这种完整的计划方法有助于更高效的路由逻辑，通过完整的计划（基于 SFS 客户部署的现场观察进行方向性估计），可以减少 20% 以上的出行，从而立即提高资源利用率并增强服务响应。 ### 场景 2 - 基于容量的可用性 - **要求：**供应商每天最多提供 40 个“时段”用于锅炉维修，但自行管理技术人员派遣。 - **上下文：**管理 40 个单个资源记录会增加不必要的开销。 - **建议：链接到供应商客户的基于工作量的资源**。一个资源记录代表供应商的总日工作量，保持甘特图干净，并避免管理单个承包商技术人员记录。 ### 场景 3 - 季节性容量扩展 - **要求：**一家公用事业公司在风暴季节雇用了 50 名当地小型承包商来处理浪涌维修。 - **上下文：**每个季节创建和删除 50 个区域是一项重大管理负担，并对计划和优化引擎的灵活性产生负面影响。 - **建议：****基于客户**的共享。创建永久“溢出”地理区域。在合同工入职时，只需创建客户，并将资源链接到该客户。自动化层会立即处理可见性，无需重新设计区域层次结构。 ### 场景 4 - 多供应商紧急承保范围 - **要求：**对于高优先级的气体泄漏，无论他们为哪个承包商工作，都必须派遣最近的技术人员。 - **上下文：**基于区域的共享会产生覆盖范围差距，因为最近的技术可能在不同的区域中，因此计划逻辑无法联系到。 - **建议：****基于客户**的共享。通过将供应商整合到一个大型区域中，该引擎根据在整个多供应商池中的出行情况执行完整的搜索，减少了关键安全事件的响应时间。 ### 场景 5 - 独家区域特许经营 - **要求：**专业的 HVAC 合作伙伴拥有 10 年的专属法定权利，可以为偏远地区或农村县提供服务。 - **上下文：**没有其他承包商在此地理位置运营，合作伙伴可以完全管理自己的计划和派遣。 - **建议：****基于区域的共享**。在这种情况下，专用服务区域是最有效的选择。由于与其他合作伙伴没有地理重叠，区域边界提供的隔离完全符合法律和业务要求，无需进一步共享自动化。 ## 实施指导 - 共享自动化层 基于客户的共享通过将记录级访问权限与调度人员用户及其服务资源记录之间共享的公用客户/公司标识符联系起来，将可见性与地理位置分开。平台的本地基于条件的共享引擎会评估此字段，并在不更改区域层次结构的情况下自动授予或撤销访问权限。 ### 所需的三个架构组件 所需的三个架构组件是： 1. 用户和服务资源对象上的通用标识符字段，将它们链接到承包商客户。 2. 每个合同工公司聚合所有调度人员用户的公用小组，因此共享规则统一适用。 3. 基于条件的共享规则，用于评估标识符并授予适当的公用小组对相关记录的访问权限。 ### 公用小组 使用公用小组聚合需要相同可见性的调度人员，而不是使用区域作为边界。调度人员通过基于区域的公共小组成员关系查看特定区域、工作订单和服务预约。 - **小组创建：**为每个承包商公司创建公用小组。 - **成员分配：**将相关合作伙伴社区用户（调度人员）添加到各自的承包商公用小组。 ### 基于条件的共享规则 利用基于条件的共享规则，授予公用小组对特定记录的访问权限。 - **服务资源共享条件：**服务资源共享规则通过将服务资源记录中的公司/客户标识符与相应的承包商公用小组匹配，强制执行每个承包商技术人员的可见性。 - 访问权限级别允许读/写，以允许调度人员计划和更新分配。 - **服务区域共享条件：**使用服务区域共享条件，以设置区域受限访问的逻辑。授予调度人员访问授权工作的广阔地理区域的权限。示例： - **条件：**ServiceTerritory.Name EQUALS "Atlanta"。 - **共享对象：**相关承包商公用小组（例如承包商 A、承包商 B、承包商 C）。 - **访问级别：**读/写 有关详细的实施指导，请参考 Salesforce 官方文档： - [基于条件的共享规则](https://help.salesforce.com/s/articleView?id=sf.security_sharing_rules_criteria.htm) - [公用小组](https://help.salesforce.com/s/articleView?id=sf.user_groups.htm) - [Apex 触发器用于自动共享记录管理](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers.htm) ### 实施结果 正确实施后，基于客户的共享可提供： - **统一可见性：**调度人员可以查看整个区域的所有相关资源，无需手动重新分配区域。 - **动态访问权限：**随着合同工分配的更改，共享规则会自动调整可见性，而无需管理员干预。 - **竞争隔离：**每个合同工只能看到自己的资源，维护数据隐私。 - **可扩展架构：**只需创建客户和公共小组，即可加入新合同工，共享规则会自动处理其余事项。 ## ROI 框架：衡量成功 | KPI 类别 | 度量 | 目标影响（基于客户的共享） | | -------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **运营效率** | 减少出行时间 | 通过迁移到统一池（基于客户的共享），组织通过完整的计划（根据 SFS 客户部署的现场观察进行方向估计）减少了 20% 以上的出差时间，并通过在整个资源池中确定最近的可用技术人员来加快服务时间。 | | **资源效率** | 技术人员利用率 | 通过优化真正最佳资源并减少出行，提高效率 | | **客户体验** | 响应时间/SLA 遵守情况 | 响应时间提高 25% 以上（根据 SFS 客户部署的现场观察进行方向性估计） | ## 战略推荐和长期价值 ### 面向未来：AI、自动化和可扩展性 随着现场服务组织从反应式模式转向主动式模式，他们对架构模式的选择为长期运营灵活性设置了“创新天花板”。 - **启用 AI 和机器学习：**基于客户的共享验证引擎对整个资源池的可见性，以找到最佳匹配，而不是受数据孤岛的限制。由于避免了低效的区域孤岛，Field Service 计划客服人员（Salesforce 中 AI 支持的计划助手）提供了更合理的出行模式和技术人员分配，而不受孤立的微型区域的限制。这种方法最大限度地优化了整个流程，直接提高了出行 KPI 和技术人员的准备程度。基于客户的共享通过让引擎了解整个资源池来支持 AI 驱动的计划，允许“真最佳”匹配，而不是受人为数据孤岛的限制。 - **架构可扩展性：**基于区域的共享通常遇到“性能墙”，因为它依赖于孤立的区域。随着承包商网络的增长，计划引擎的有效性被人为的边界抵消，使其无法达到相邻区域的可用容量。此外，当基于区域的共享需要新区域并为每个合作伙伴手动调整时，基于客户的共享会简化增长。组织通过简单地创建客户和关联的服务资源记录来加入数百个合同工合作伙伴，而保持核心地理区域结构不变和性能良好。 ### 最终决策矩阵：比较架构 | 决策驱动因素 | 基于区域的隔离 | 基于客户的共享（建议） | | ------------------------------------------ | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | **计划和优化效率** | 低（孤岛资源） | 高（聚合池） | | **运营绩效** | 低（涵盖相同地理区域的筒仓区域和资源） | 高（最大化利用率、最小化出行时间、加快响应/服务时间） | | **区域可扩展性** | 较差（“层次结构扩展”的风险） | 优秀（静态地理位置） | | **设置的复杂性** | 低（声明性/OOTB） | 中等（需要流/Apex） | | **合作伙伴数据安全**性 | 高（硬边界） | 高（平台共享规则） | | **内部管理** | 高（调度人员手动在视图之间切换） | 低（合并区域视图） | ### Brownfield 迁移：从基于区域的共享过渡到基于客户的共享 本指南主要侧重于全新实施。然而，许多组织已经在大规模地运行基于区域的共享，并承担着巨大的区域层次结构债务。在实时生产环境中，从基于区域的共享迁移到基于客户的共享会引入不同的架构风险，以便在任何迁移工作开始前进行评估。本节讨论现有系统迁移的三个重要方面：评估当前状态、确定迁移策略和管理迁移风险。 - **评估区域扩展：**在任何迁移计划前，量化当前区域层次结构。关键的诊断问题是：有多少区域只是为了强制承包商隔离与真正的地理边界？特定于承包商的子区域与运营父区域的比率是多少？任何区域是否在内部和外部资源之间共享，或是否完全孤立？这种审计区分了真正的地理结构和累积的隔离债务。在基于客户的共享下，专为合作伙伴可见性控制创建的区域是需要淘汰的有力候选区域。编码真正运营地理位置（计划区、SLA 区域、监管边界）的区域将被保留，并且不会与访问控制混淆。 - **混合迁移可行性：**对于大规模组织，从基于区域的共享完全切换到基于客户的共享很少可取；相反，混合过渡通过在基于客户的共享下引入新承包商来降低风险，同时在下一次续订窗口之前保持原有基于区域的共享队列。混合方法在架构上是可行的，前提是基于客户的共享自动化严格限于客户/公司标识符，允许没有该 ID 的资源保持基于区域的访问而不中断。将混合状态视为临时架构，而不是永久操作模型。 - **关键迁移风险：**现有系统迁移会引入三个关键的架构风险，需要主动缓解。首先，由新的基于标准的规则触发的共享表重建需要大量资源；在活动较少的时段计划切换，以防止调度人员因长时间运行的重新计算而导致可见性差异。第二，临时工作订单在迁移期间存在丢失可见性的风险；保留并行区域成员关系或预填充有效记录的共享，直到它们关闭。最后，在删除子区域移动资源池时，调整优化和计划策略。测试、进行基线运行并捕获度量，以确认地理边界仍然有效，并且确实实现了效率提高。 ## 一般性建议 考虑到可扩展性和优化 ROI,我们建议高增长的 Field Service 组织使用基于**客户的共享**方法,这些组织在重叠的地理区域管理多个竞争对手的合同工。虽然基于区域的共享提供了更简单的声明性设置，但基于客户的共享允许组织释放计划和优化引擎的全部潜力。通过将可见性与地理位置分离，组织可以保持与业务同步的区域设置，并提供以下结果： - **运营效率：**将资源聚合到一个池中，引擎可以为每项工作找到真正的“最佳”技术人员，从而减少出行时间和运营成本。 - **增强服务级别：**通过识别哪个合同资源最可用/最靠近，加快服务时间并直接提高客户满意度，全面计划可以减少服务延迟。 - **调度人员效率：**内部员工可以管理统一的区域视图，而不是在孤立的“子”区域之间切换。 基于区域的共享最适合高度孤立的承包商运营，这些承包商运营的地理区域/区域严格不重叠。 ## 实施核对清单：后续步骤和参与 选择架构模式是第一步。成功执行需要与 Salesforce 最佳实践和平台功能持续保持一致。 **后续步骤：** - **审核您的环境：**查看当前区域层次结构和外部资源利用率。确定仅为合作伙伴隔离创建的任何“承包商区域”—如果您的层次结构被这样的竖井弄得一团糟，请评估迁移到基于客户的共享的好处和努力。 - **Sandbox 验证：**在完整或部分 Sandbox 中构建基于客户的共享模式原型，并从所有角度测试端到端的可见性： - **内部用户（管理员、调度人员和内部技术人员）：**确认适当的访问权限。一些内部用户应该拥有全面的访问权限。 - **承包商经理用户：**验证可见性是否严格限于自己的员工。 - **承包商的技术人员（外部资源）：**请确认访问权限仅正确限制为分配的工作。 - _严格测试组织可见性对于防止竞争对手之间的数据泄露至关重要。_ - **绩效基准和投资回报率评估：**利用优化中心和 Field Service 智能仪表板，深入了解出行时间减少、资源利用率和响应时间改进，并为利益相关者提供证明架构转变合理性所需的数据。一旦转换开始，这种前后分析也可以在生产中重复。 - **试点阶段：**Sandbox 测试完成后，在内部和外部资源在地理上重叠的一两个区域启动分阶段试点，理想情况下，与 Sandbox 中测试的相同。在完全部署前，建议在更广泛的推出前，验证与小型受控用户组的共享逻辑。 - **解决方案的可扩展性：**请确认，管理共享表和服务区域成员 (STM) 记录所需的任何自定义自动化 (Flow 或 Apex) 都是为长期可持续性设计的。该解决方案应使用模块化设计模式（例如，触发框架），并确保构建的逻辑能够在平台调控器限制内无缝处理高用量资源分配。 ## 架构备注 在生产部署之前，本指南中的_所有模式都需要在 Sandbox 环境中进行验证。实施行为可能因组织配置、数据量和业务规则而异。_ ## 参考和进一步阅读 **平台文档（Salesforce 官方）：** - [Field Service 开发人员指南：](https://developer.salesforce.com/docs/atlas.en-us.field_service_dev.meta/field_service_dev/fsl_dev_introduction.htm)Field Service 数据对象、API 和自定义的核心参考 - [ServiceResource 对象引用：](https://developer.salesforce.com/docs/atlas.en-us.field_service_dev.meta/field_service_dev/sforce_api_objects_serviceresource.htm)SR 对象的 API 文档 - [ServiceTerritoryMember 对象引用：](https://developer.salesforce.com/docs/atlas.en-us.field_service_dev.meta/field_service_dev/sforce_api_objects_serviceterritorymember.htm)STM 对象的 API 文档 - [基于条件的共享规则：](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/security_sharing_rules_criteria.htm)实施基于客户的共享所基于的共享的共享规则的官方安全指南 - [Apex 触发器开发人员指南：](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers.htm)基于客户的共享所需的自定义自动化层的参考 - [Apex 触发器最佳实践：](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_bestpract.htm)Salesforce 推荐的可扩展触发器开发模式 **Salesforce 帮助文章** - [设置 Field Service 合同工的准则：](https://help.salesforce.com/s/articleView?id=service.fs_setting_up_contractors.htm&type=5)在 Salesforce Field Service 上配置承包商资源的指导 - [定义基于工作量的资源：](https://help.salesforce.com/s/articleView?id=service.fs_define_resource_capacity.htm&type=5)设置文章中引用的基于能力的资源的官方文档 - [Field Service 优化引擎的工作原理？](https://help.salesforce.com/s/articleView?id=service.fs_start_optimization.htm&type=5)Field Service 优化参考。优化运行指南，也与文章中提到的基于客户的共享优势和 ROI 相关。 - [设置优化中心](https://help.salesforce.com/s/articleView?id=service.pfs_optimization_hub_set_up.htm&language=en_US&type=5):后续步骤部分中引用的优化中心配置指南 - [Experience Cloud 概览：](https://help.salesforce.com/s/articleView?id=experience.networks_overview.htm&language=en_US&type=5)适用于基于客户的共享的合作伙伴社区设置（平台管理） **Salesforce Trailhead/学习** - [Field Service 基本信息：](https://trailhead.salesforce.com/content/learn/modules/field_service_basics)涵盖区域、资源和工作时间的基础模块 - [Field Service 计划：](https://trailhead.salesforce.com/content/learn/modules/field-service-lightning-scheduling-basics)支持本指南中优化讨论的计划概念 - [Field Service 优化：](https://trailhead.salesforce.com/content/learn/modules/field-service-lightning-optimization)深入了解优化设置和计划策略 - [Salesforce 安全性和谁可以看到什么：](https://trailhead.salesforce.com/content/learn/modules/data_security/data_security_sharing_rules)共享规则和数据安全基本知识 - [使用 Experience Cloud 构建合作伙伴入口网站：](https://trailhead.salesforce.com/content/learn/projects/communities_share_crm_data/create_portal_and_users)文章中引用的 Experience Cloud 合作伙伴设置实践指南 **行业和战略环境** - [Salesforce 服务状态报表，第 7 版：](https://www.salesforce.com/resources/research-reports/state-of-service/)最新版本调查了全球 6500 名服务专业人员，对与本文中的 ROI 参数直接相关的 Field Service、AI 采用和技术人员生产力趋势有专门的见解。 - [适用于 Field Service 的 Agentforce：](https://www.salesforce.com/news/stories/agentforce-for-field-service-announcement/)Salesforce 基于 AI 的现场服务平台，与第 13 节中的 AI 和面向未来的讨论直接相关。基于客户的共享统一资源池最大限度地提高了 Agentforce 的计划智能。 - [适用于 Field Service Management 的 Gartner 市场指南：](https://www.gartner.com/en/documents/6311147)最新的 Gartner 密克罗尼西亚市场形势分析（需要 Gartner 订阅）。 ## 关于作者 **莫爾·愛泼斯坦** _Salesforce Field Service 高级成功架构师_ Mor 拥有乔治亚理工学院的工业工程背景和工商管理硕士学位,是一位值得信赖的顾问,在疏通和加速关键任务 Field Service 实施方面有着公认的良好记录。她面向全球客户的经验,加上实践、数据驱动的问题解决,使她成为全球现场服务组织的去向资源。Mor 擅长指导客户完成计划和优化过程，帮助组织释放智能计划的全部潜力，以在效率和服务交付方面取得可衡量的收益。 **李·埃弗拉蒂** _Salesforce Field Service 高级成功架构师_ Lee 是一位经验丰富的技术架构师，拥有 10 多年的 Salesforce 交付和咨询经验，专门从事 Field Service 架构和移动解决方案设计。Lee 专注于将复杂的组织结构与本地 SFS 平台和移动应用程序相结合，以提高全球企业的最大运营投资回报率。Lee 秉承客户至上的思想和全面的平台 Knowledge,带来了一种咨询方法,为全球 Salesforce 客户提供持久的价值。