使用 Power Platform 自動化服務訂單生命週期與服務服務等級治理

Power Platform 可用於打造自動化服務訂單端到端生命週期的解決方案。 此方法簡化了服務訂單請求的建立，管理跨階段的核准工作流程，強制執行基於 SLA 的生命週期管理，並處理終止流程。 它也提供一個集中系統，讓法律與合約團隊管理服務訂單合約及相關簽署文件。

提示

本文提供一個範例情境及一個通用範例架構，說明如何透過 Power Apps、Power Automate、Dataverse 及 Microsoft 365 設計自動化服務請求生命週期、核准、SLA 治理及終止服務的解決方案。

架構圖

Power Platform 架構圖，顯示使用者、安全性、Dataverse、模型驅動應用程式介面、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 表單。 在此表單中，使用者只能選擇自己建立的已完成的服務訂單請求。

終止工作流程

當服務命令與服務協議請求需要明確終止時，會產生終止請求。 終止申請採用類似流程，取得商業負責團體及主要負責人的批准。

使用者只能針對他們核准並建立的服務協議或服務命令提出終止請求。

任何獲核准的終止要求到達終止日期時，後端 Power Automate 流程會每日執行以進行檢查，而且：

  • 如果請求與SLA相關，則終止與終止請求相關聯的SLA。

  • 若請求是服務命令，則終止所有與服務訂單相關的SLA，並終止服務訂單。

使用案例細節

本節總結了塑造服務訂單解決方案的商業背景與目標，包括遷移至 Power Platform 的決定。

商務背景

此計畫始於一個組織著手將其服務訂單管理流程從 Angular–Camunda 平台遷移至 Microsoft Power Platform。

這個舊有解決方案基於 Angular、Camunda 工作流程引擎和 PostgreSQL，產生了高昂的授權成本，需要專門的技術團隊來處理變更請求，且即使是微小的改進也需長時間處理。 解決方案的複雜性及其維護負擔促使組織尋求現代化、具成本效益且易於維護的替代方案。

目標與驅動因素

新解決方案的主要驅動因素：

  • 善用現有的 Power Platform 執照與基礎設施 ，消除額外的授權成本。

  • 減少對專業技術支援的依賴，降低營運成本。

  • 透過使用低程式碼功能並減少自訂開發，簡化變更管理。

  • 在一個月內交付精簡且可維護的 Power Platform 解決方案，並符合客戶緊迫的時程。

  • 確保現有流程及底層資料的無縫遷移。

  • 透過互動且直覺的介面提升使用者體驗。

元件

團隊已設計並建置一個由主要現成可用 (OOTB) 功能提供支援的 Power Apps 模型導向應用程式，在滿足所有功能需求的同時，盡量減少自訂。

用戶介面

模型驅動應用程式 作為使用者的主要使用者介面。

自訂頁面 透過確保互動式介面行為及應用程式從現有平台遷移時對終端使用者的變動最小，現代化使用者體驗。

命令列 自訂功能透過不同階段管理商業規則與核准流程。

業務流程流程 （BPF）幫助使用者視覺化現有階段。

PDF 產生

先前系統的 PDF 匯出功能極為複雜，即使是輕微的範本更新也需頻繁技術介入。

新解決方案使用：

  • OOTB 實體文件範本用於Word/PDF 產生。

  • 管理員控制的範本修改，消除對技術團隊的依賴。

此方法大幅縮短處理時間，並免除開發驅動的範本更新需求。

工作流程與核准

業務流程 協調請求路由、核准及多階段進度追蹤。

Power Automate 流程 在每個審核階段完成後執行各種動作，例如向Outlook與 Teams 發送通知、指派任務，並在最終階段自動產生 PDF。

生命週期與終止管理

Power Automate 流程 每天執行，以檢查是否有當天終止的 SLA 與服務訂單。

任務提醒

Power Automate flows 會在截止日期過後，向被指派任務的使用者發送提醒。

數據源

Dataverse 用來管理與儲存應用程式資料，並維護稽核日誌歷史。

SharePoint作為文件儲存庫及文件版本控制。

報告

Power Apps 模型驅動的應用程式內建報告顯示圖表，並提供應用資料的洞見。

考慮事項

這些考慮因素體現了 Power Platform Well-Architected 的支柱，這是一套提高工作負載品質的指導原則。 更多資訊請參見 Microsoft Power Platform Well-Architected。

可靠性

  • 建立明確的期望：

    • 回應時間
    • 核准時程
    • 每日工作窗口（SLA 到期、終止工作）

  • 實施以任務為基礎的韌性。 例如，如果 Power Automate 步驟失敗：

    • 在相關動作完成前，將任務保留在 Dataverse 中。

    • 讓使用者在任何階段重新嘗試提交或核准。

    • 只有在工作流程中所有步驟都完成後，才會更新請求狀態。

    • 如果階段更新失敗，請在業務流程中顯示錯誤。

  • 利用重試邏輯處理每日工作失敗，並根據動態篩選擷取資料。

  • 使用短時間且無狀態的使用者操作，以降低工作流程卡住的風險。

  • 使用日誌來保持請求資料的可靠性並支持可追溯性。

安全性

  • 使用對應至 Dataverse 負責人團隊的 Microsoft Entra ID 安全性群組來控制對模型導向應用程式的存取。

  • 明確定義商業責任人、主要負責人、請求者及管理員的安全角色，以保障資料存取的安全。

  • 依照組織政策邀請訪客使用 Microsoft Entra ID，並在核准後才將他們加入安全群組。 對經核准的外部使用者使用相同的安全群組。

  • 使用 Dataverse 的欄位層級與列層級安全性。

  • 透過內建與 Dataverse 及模型驅動應用程式的整合，授予 SharePoint 權限。

  • 將應用程式部署在 受管理環境中 ，並為其定義特定的資料政策。

  • 使用 Dataverse 的稽核記錄來偵測資料異常。

  • 當請求達到特定階段後，將資料設為唯讀。

  • 實施歸檔政策，確保管理員能完全掌控已歸檔的資料，使用者只能存取每次請求產生的 PDF 文件。

卓越營運

  • 制定環境策略以確保營運卓越。 建立開發、測試及生產環境，並在適當時將其配置為 受管理環境 。

  • 實施解決方案策略：

    • 在開發環境中使用非管理解決方案，在其他環境中使用受管理解決方案。

    • 設計解決方案細分以區分使用者介面元件、流程與核心元件。

  • 在離開開發環境前，先實施程式碼審查。

  • 在低程式碼結構上打造一個模型驅動的應用程式，以加快功能增強與錯誤修正。

效能效率

  • 辨識舊應用程式中的交易量模式，並與業務商就收集的量數據達成共識。

  • 將長時間執行的活動 (例如 SLA 到期和終止執行) 委派給不依賴於使用者互動的預定流程。

  • 使用批次 API 來進行批量 CRUD 操作，以避免 限速限制。

體驗最佳化

  • 建立自訂頁面來強化登陸頁面。

  • 發送格式良好的電子郵件，讓使用者能輕鬆辨識。

  • 在電子郵件中加入深度連結，讓使用者能直接前往請求。

  • 及時發送提醒，幫助用戶按時完成任務。

  • 新增快速連結到 我的任務 和管理區塊。

  • 新增自訂按鈕，讓使用者選擇以識別應採取的行動。

  • 每次按鈕選擇後，通知使用者成功或失敗。

  • 當請求達到特定階段時，隱藏不必要的資料。

  • 將資料歸檔，讓使用者只能看到使用中的項目。

貢獻者們

本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。

主要作者：

  • 上次更新時間：