使用 Power Platform 自动执行服务订单生命周期和 SLA 治理

Power Platform 可用于构建可自动执行服务订单端到端生命周期的解决方案。 此方法简化了服务订单请求的创建、跨多个阶段管理审批工作流、强制实施基于 SLA 的生命周期管理以及处理终止过程。 它还为法律和合同团队提供了一个集中式系统，用于管理服务订单合同和相关签署的文档。

提示

本文提供了一个示例方案和通用示例体系结构，演示如何使用 Power Apps、Power Automate、Dataverse 和 Microsoft 365 来设计自动化服务请求生命周期、审批、SLA 治理和终止的解决方案。

体系结构示意图

Power Platform 体系结构的图表显示用户、安全性、Dataverse、模型驱动应用 UI、Power Automate 和 Microsoft 365 集成。

Workflow

工作流由三个主要流程组成：服务订单工作流、SLA 工作流和终止工作流。 每个工作流都有不同的阶段和审批流程。

服务订单工作流

用户通过在模型驱动应用中填写表单来启动服务订单请求过程。 其他用户（如商业负责任的组用户和主要负责用户）在不同阶段参与审批过程。

工作流如下所示：

  1. 用户访问主页，这是嵌入在模型驱动应用中的自定义页面。 自定义页面包含指向以下链接的快速链接：

    • 访问现有服务订单、服务级别协议（SLA）或终止请求
    • 为服务订单、SLA 或终止创建新请求
    • 查看分配的任务
    • 对管理员组成员可见的管理员按钮

  2. 用户从主页中选择 “新建服务订单 ”。 此时会显示一个新的服务订单窗体，其中包含用于输入服务订单详细信息的选项卡。 用户可以使用内置SharePoint子网格选项将文档附加到新创建的服务订单。

  3. 若要创建服务订单请求，用户选择页面顶部的 “发送请求 ”自定义按钮。 将执行以下操作：

    1. 使用新的服务订单 ID 创建新的服务订单。

    2. 请求的状态更新为 服务订单已请求。

    3. 在任务表中创建了一个新任务，并将其分配给商业责任组的负责人团队。

    4. 用户无法再编辑请求。

    5. 业务流程将更新到下一阶段。

    当用户选择自定义按钮时，脚本将运行以更新请求状态并触发执行上述所有操作的Power Automate流。 模型驱动应用窗体上的脚本会检查请求状态和分配的用户。 除商业负责组外，这些字段对其他所有人都是只读的。 此条件适用于各个阶段提供的所有自定义按钮。

商业责任用户分配或拒绝请求，如下所示：

  1. 商业负责任的用户登录并选择“ 我的任务”下分配的任务。

  2. 商业负责任的用户通过选择相应的自定义按钮来评审请求，然后批准或拒绝该请求：

    • 分配主要责任人
    • 拒绝请求

  3. 拒绝时，请求将被拒绝，并向服务订单请求者发送通知。

  4. 当用户选择 “分配主要责任”时，请求将移动到下一阶段。

    1. 请求状态将更新为 等待 PR 审批。

    2. 业务流程阶段更新。

    3. 为主要责任用户创建新任务。 分配给商业责任用户的上一个任务已完成。

    4. 通知将发送到主要负责任的用户。

主要负责任的用户批准、拒绝或请求更改，如下所示：

  1. 主要负责的用户登录并选择“ 我的任务”下分配的任务。

  2. 主要负责用户选择 批准、 拒绝或 发送修订。 当请求的状态为 “等待 PR 审批”时，这些自定义按钮仅对被分配PR的用户可见。

    • 批准：

      1. 请求状态标记为已批准。 此状态更改是通过在自定义按钮上编写的自定义脚本实现的。

      2. 通知将发送到商业责任组和服务订单请求者。

      3. 请求状态将更新为 待最终签署过程。

      4. 任务被分配给商业责任小组。

      5. 业务流程更新至下一阶段。

      6. 主要负责用户的任务已完成。

    • 拒绝：

      1. 请求标记为已拒绝。

      2. 业务流程已更新为“已拒绝”阶段。

      3. 通知将发送到服务订单请求者和商业责任组。

    • 提交修订：

      1. 请求将发送回服务订单请求者以进行修改。

      2. 请求状态将更新为 “正在处理”阶段的服务订单请求 。

      3. 业务流程将更新到初始阶段。

      4. 向服务订单请求者发送电子邮件通知，其中包含指向服务订单请求的链接。

    当主要责任用户拒绝或批准请求时，将导出 PDF 文档并将其保存到服务订单SharePoint 库。 PDF 是使用 Dataverse 的文档模板功能生成的，用户通过使用 XML 实体属性在 Word 中创建模板。 Power Automate流调用 PDF 文档模板 API 来生成 PDF 版本并导出服务请求的所有数据。 文档模板 ID 和服务订单全局唯一标识符（GUID）将传递给 Power Automate 流。

在最终签名阶段，商业负责任的用户对文档进行签名并完成请求。 用户只能查看与文档签名过程相关的选项卡。 所有其他选项卡都处于隐藏状态。 此功能是使用表单上的 XRM API 和 JavaScript 实现的。

  1. 在第一个选项卡上，商业负责任的用户会看到 “上传签名的文档 ”按钮。

  2. 当用户选择按钮时，应用会突出显示下一个选项卡，其中包含在上一步中生成的SharePoint文档子网格和 PDF 文档。

  3. 商业负责任的用户下载 PDF 文档，手动对其进行签名，并将其上传到文档库选项卡中。

  4. 顶部 的“完整签名过程 ”自定义按钮可用。

  5. 当商业负责任的用户选择该按钮时，请求将变为只读。

  6. 请求完成后，会向用户、商业责任组和主要负责用户发送通知。 Power Automate 流将业务流程流和分配的任务标记为已完成。

SLA 工作流

服务级别协议（SLA）工作流在服务订单请求获得批准后启动。 SLA 请求具有与服务订单请求类似的工作流，其中包含审批阶段和任务分配。

SLA 默认有效期为 18 个月，后端Power Automate作业每天运行，以检查 SLA 到期时间。 当 SLA 到期日期与当前日期匹配时，作业会将 SLA 和关联的服务订单标记为已终止，并更新这两个实体对应的电子邮件通知和业务流程阶段。

若要启动 SLA 工作流，用户选择“ 创建新 SLA”请求 以打开 “新建 SLA ”窗体。 在此窗体中，用户只能选择自己创建的已完成的服务订单请求。

终止工作流

当服务订单和 SLA 请求需要显式终止时，将创建终止请求。 终止请求通过类似的工作流从商业负责组和主要责任用户获得批准。

用户只能为他们批准和创建的 SLA 或服务订单提出终止请求。

当达到任何已批准终止请求的终止日期时，后端 Power Automate 流将每天运行以检查并：

  • 如果请求是关于 SLA 的，请终止与该请求相关的 SLA。

  • 如果请求用于服务订单，请终止与服务订单关联的所有 SLA 并终止服务订单。

用例详细信息

本部分总结了塑造服务订单解决方案的业务上下文和目标，包括决定迁移到 Power Platform。

业务上下文

当组织开始将服务订单管理流程从 Angular-Camunda 平台转移到Microsoft Power Platform时，该计划就开始了。

基于 Angular、Camunda 工作流引擎和 PostgreSQL 构建的旧解决方案会产生很高的许可成本，需要一个专门的技术团队来请求更改，甚至次要增强也经历了长时间的周转时间。 解决方案的复杂性及其维护开销促使组织追求现代、经济高效且易于维护的替代方法。

目标和驱动程序

新解决方案的关键驱动因素：

  • 利用现有的 Power Platform 许可证和基础结构 来消除额外的许可成本。

  • 减少对专业技术支持的依赖性，降低运营费用。

  • 使用低代码功能简化变更管理，并将自定义开发降到最低。

  • 在一个月内提供精简且可维护的 Power Platform 解决方案，满足客户的激进时间线。

  • 确保无缝迁移 现有过程和基础数据。

  • 使用交互式直观界面改善用户体验。

组件

该团队设计并实施了一个 Power Apps 模型驱动应用，利用关键的开箱即用（OOTB）功能支持，以确保在满足所有功能需求的同时尽量减少自定义。

用户界面

模型驱动应用 充当用户的主要用户界面。

自定义页面 通过确保交互式 UI 行为和应用程序从现有平台迁移时对最终用户的最小更改来现代化用户体验。

命令栏 自定义通过不同的阶段管理业务规则和审批过程。

业务流程 （BPF）可帮助用户可视化现有阶段。

PDF 生成

以前的系统的 PDF 导出功能非常复杂，即使是次要模板更新，也需要频繁的技术干预。

新解决方案使用：

  • OOTB 实体文档模板，用于Word/PDF 生成。

  • 管理控制的模板修改，消除了对技术团队的依赖。

此方法大大减少了周转时间，并消除了开发驱动的模板更新的需求。

工作流和审批

业务流程 协调请求路由、审批和多阶段进度跟踪。

Power Automate 流在每个审批阶段完成时执行各种操作，例如向 Outlook 和 Teams 发送通知、分配任务以及在最后阶段生成自动生成的 PDF。

生命周期和终止管理

Power Automate 流每天运行以检查在当天终止的 SLA 和服务订单。

任务提醒

Power Automate 流在截止日期过去时向被分配任务的用户发送提醒。

数据源

Dataverse 用于管理和存储应用程序数据并维护审核日志历史记录。

SharePoint作为文档存储库和文档版本控制。

正在报告

Power Apps 模型驱动应用程序的内置报告显示图表并提供应用程序数据的见解。

注意事项

这些注意事项实现了架构良好的 Power Platform 支柱，这是一组可提高工作负荷质量的指导原则。 有关详细信息，请参阅Microsoft Power Platform 架构最佳实践。

Reliability

  • 建立明确的预期：

    • 响应时间
    • 审批时间线
    • 每日作业窗口（SLA 到期、终止作业）

  • 实现基于任务的复原能力。 例如，如果 Power Automate 的某个步骤失败：

    • 将任务保留在 Dataverse 中，直到相关操作完成。

    • 让用户在任何阶段重试提交或审批。

    • 仅在执行工作流中的所有步骤后更新请求状态。

    • 如果阶段更新失败，则显示业务流程中的错误。

  • 使用重试逻辑处理日常任务失败，并根据动态过滤器获取数据。

  • 使用生存期较短的无状态用户操作来减少工作流停滞的可能性。

  • 使用日志记录使请求数据可靠并支持可跟踪性。

安全性

  • 使用映射到 Dataverse 负责人团队的 Microsoft Entra ID 安全组控制对模型驱动应用的访问。

  • 明确定义商业责任人、主要责任人、请求者和管理员的安全角色，以保护数据访问。

  • 按照组织策略邀请来宾用户进入 Microsoft Entra ID，仅在批准后将其添加到安全组。 对批准的外部用户使用相同的安全组。

  • 使用 Dataverse 字段级和行级安全性。

  • 通过与 Dataverse 和模型驱动应用程序的内置集成授予SharePoint权限。

  • 在 托管环境中 部署应用程序并为其定义特定的数据策略。

  • 使用 Dataverse 审核日志记录检测数据异常。

  • 在请求到达特定阶段后，使数据处于只读状态。

  • 实施存档策略，以确保管理员完全控制存档的数据，并且用户只能访问为每个请求生成的 PDF 文档。

卓越运营

  • 定义环境策略以确保卓越运营。 设置开发、测试和生产环境，并在适当情况下将其配置为 托管环境 。

  • 实现解决方案策略：

    • 在开发环境中使用非托管解决方案，在其他环境中使用托管解决方案。

    • 设计解决方案分段以细分 UI 组件、流程和核心组件。

  • 在从开发环境迁移之前实现代码评审。

  • 在低代码构造上构建模型驱动应用，以加快增强功能和 bug 修复。

性能效率

  • 识别旧应用程序中的事务量模式，并就收集的量数据与业务达成一致。

  • 将长时间运行的活动（如 SLA 到期和终止执行）委托给不依赖于用户交互的计划流。

  • 对批量 CRUD 操作使用批处理 API 以避免 速率限制。

体验优化

  • 创建自定义页面以增强登陆页面。

  • 发送格式正确的电子邮件，以便用户可以轻松识别它们。

  • 在电子邮件中包含深层链接，以便用户可以直接转到请求。

  • 发送及时提醒，帮助用户按时完成任务。

  • 添加“ 我的任务 ”和“管理员”部分的快速链接。

  • 添加用户可以选择的自定义按钮来标识要执行的操作。

  • 在每个按钮选择后通知用户成功或失败。

  • 当请求到达特定阶段时隐藏不必要的数据。

  • 存档数据，以便用户仅看到活动项。

供稿人

Microsoft维护本文。 以下贡献者撰写了本文。

主要作者：

  • Last updated on