Power Platform を使用して、サービス注文のエンドツーエンドのライフサイクルを自動化するソリューションを構築できます。 このアプローチにより、サービス注文要求の作成が効率化され、複数のステージにわたる承認ワークフローが管理され、SLA ベースのライフサイクル管理が適用され、終了プロセスが処理されます。 また、法務チームと契約チームがサービス注文契約と関連する署名済みドキュメントを管理するための一元化されたシステムも提供します。
ヒント
この記事では、Power Apps、Power Automate、Dataverse、およびMicrosoft 365を使用してサービス要求のライフサイクル、承認、SLA ガバナンス、終了を自動化するソリューションを設計する方法を示す、シナリオの例と一般化されたアーキテクチャの例を示します。
アーキテクチャ ダイアグラム
Workflow
ワークフローは、サービス注文ワークフロー、SLA ワークフロー、終了ワークフローの 3 つの主要なプロセスで構成されます。 各ワークフローには、異なるステージと承認プロセスがあります。
サービス注文ワークフロー
ユーザーは、モデル駆動型アプリでフォームに入力することで、サービス注文要求プロセスを開始します。 商用責任のあるグループ ユーザーや主要な責任を持つユーザーなど、他のユーザーは、さまざまな段階で承認プロセスに関与します。
ワークフローは次のとおりです。
ユーザーはホーム ページにアクセスします。ホーム ページは、モデル駆動型アプリに埋め込まれたカスタム ページです。 カスタム ページには、次のクイック リンクがあります。
- 既存のサービス注文、サービス レベル アグリーメント (SLA)、または終了要求にアクセスする
- サービス注文、SLA、または終了の新しい要求を作成する
- 割り当てられたタスクを表示する
- 管理者グループ メンバーに表示される [管理者] ボタン
ユーザーがホーム ページから [新しいサービス注文] を選択します。 新しいサービス注文フォームが表示され、サービス注文の詳細を入力するためのタブが表示されます。 ユーザーは、組み込みの SharePoint サブグリッド オプションを使用して、新しく作成されたサービス注文にドキュメントを添付できます。
サービス注文要求を作成するために、ユーザーはページの上部にある [ 要求の送信 ] カスタム ボタンを選択します。 次のアクションが実行されます。
新しいサービス注文 ID を使用して、新しいサービス注文が作成されます。
リクエストのステータスがService Order Requestedに更新されます。
新しいタスクがタスク テーブルに作成され、商用責任グループの所有者チームに割り当てられます。
ユーザーは要求を編集できなくなります。
業務プロセス フローが次のステージに更新されます。
ユーザーがカスタム ボタンを選択すると、スクリプトが実行され、要求の状態が更新され、上記のすべてのアクションを実行するPower Automate フローがトリガーされます。 モデル駆動型アプリ フォームのスクリプトは、要求の状態と割り当てられたユーザーを確認します。 フィールドは、商用責任グループ以外のユーザーに対しては読み取り専用になります。 この条件は、さまざまな段階で使用できるすべてのカスタム ボタンに適用されます。
商用責任のあるユーザーは、次のように要求を割り当てるか拒否します。
商用責任ユーザーがサインインし、[ マイ タスク] で割り当てられたタスクを選択します。
商用責任のあるユーザーが要求を確認し、対応するカスタム ボタンを選択して要求を承認または拒否します。
- プライマリ責任者の割り当て
- 要求を拒否する
拒否すると、要求は拒否され、サービス注文要求者に通知が送信されます。
ユーザーが [ プライマリ責任者の割り当て] を選択すると、要求は次のステージに移動します。
要求の状態が PR 承認の保留中に更新されます。
業務プロセス フロー ステージが更新されます。
プライマリ責任ユーザーに対して新しいタスクが作成されます。 商用責任ユーザーに割り当てられた前のタスクが完了しました。
プライマリ責任ユーザーに通知が送信されます。
主な責任を持つユーザーは、次のように変更を承認、拒否、または要求します。
プライマリ責任ユーザーがサインインし、[ マイ タスク] で割り当てられたタスクを選択します。
主な責任を持つユーザーは、修正の 承認、 却下、または 送信を選択します。 これらのカスタム ボタンは、要求に PR 承認の保留中の状態がある場合に、要求に PR が割り当てられているユーザーにのみ表示されます。
承認:
要求の状態は承認済みとしてマークされます。 この状態の変更は、カスタム ボタンに書き込まれたカスタム スクリプトによって実装されます。
商用責任グループとサービス注文要求者に通知が送信されます。
リクエストのステータスが保留中の最終署名プロセスに更新されます。
タスクは、商用責任グループに割り当てられます。
業務プロセス フローが次のステージに更新されます。
主要な責任を持つユーザーのタスクが完了しました。
拒否:
要求は拒否済みとしてマークされます。
ビジネス プロセスが [拒否済み] ステージに更新されます。
サービス注文要求者と商用責任グループに通知が送信されます。
修正の送信:
要求は、変更のためにサービス注文要求者に送り返されます。
要求の状態は、 進行中のサービス注文要求ステージに 更新されます。
業務プロセス フローが初期段階に更新されます。
サービス注文要求へのリンクを含む電子メール通知がサービス注文要求者に送信されます。
主要な責任を持つユーザーが要求を拒否または承認すると、PDF ドキュメントがエクスポートされ、サービス注文SharePoint ライブラリに保存されます。 PDF は Dataverse のドキュメント テンプレート機能を使用して生成されます。ここで、ユーザーは XML エンティティ属性を使用してWordでテンプレートを作成します。 Power Automate フローは、PDF ドキュメント テンプレート API を呼び出して PDF バージョンを生成し、サービス要求のすべてのデータをエクスポートします。 ドキュメント テンプレート ID とサービス注文グローバル一意識別子 (GUID) は、Power Automate フローに渡されます。
最終的な署名ステージでは、商用責任のあるユーザーがドキュメントに署名し、要求を完了します。 ユーザーは、ドキュメント署名プロセスに関連するタブのみを表示できます。 その他のタブはすべて非表示になります。 この機能は、フォームで XRM API と JavaScript を使用して実装されます。
最初のタブで、商用の担当ユーザーに [ 署名されたドキュメントのアップロード ] ボタンが表示されます。
ユーザーがボタンを選択すると、アプリは次のタブを強調表示します。このタブには、SharePointドキュメント サブグリッドと、前の手順で生成された PDF ドキュメントが含まれます。
商用責任のあるユーザーは、PDF ドキュメントをダウンロードし、手動で署名して、ドキュメント ライブラリ タブにアップロードします。
上部の [署名プロセスの完了 ] カスタム ボタンが使用可能になります。
商用責任ユーザーがボタンを選択すると、要求は読み取り専用になります。
要求が完了すると、ユーザー、商用責任グループ、および主要な責任のあるユーザーに通知が送信されます。 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 Workflow Engine、PostgreSQL を基に構築された従来のソリューションでは、高いライセンス コストが発生し、変更要求に専用の技術チームが必要になり、わずかな機能強化でも長いターンアラウンド時間が発生しました。 ソリューションの複雑さとメンテナンスのオーバーヘッドにより、組織は最新のコスト効率が高く、保守が容易な代替手段を追求しました。
目標と推進要因
新しいソリューションの主な要因:
既存の Power Platform ライセンスとインフラストラクチャを活用 して、追加のライセンス コストを排除します。
特殊なテクニカル サポートへの依存を減らし、運用コストを削減します。
ローコード機能を使用し、カスタム開発を最小限に抑えることで、変更管理を合理化します。
お客様の積極的なタイムラインを満たして、1 か月以内に無駄のない保守可能な Power Platform ソリューションを提供します。
既存のプロセスと基になるデータのシームレスな移行を確保します。
対話型の直感的なインターフェイスを使用して、ユーザー エクスペリエンスを向上させます。
コンポーネント
チームは、重要な既成機能（OOTB）のサポートを受けて、カスタマイズを最小限に抑えながらもすべての機能要件を満たすために、Power Appsモデル駆動型アプリを設計し、実装しました。
ユーザーインターフェース
モデル駆動型アプリ は、ユーザーのプライマリ ユーザー インターフェイスとして機能します。
カスタム ページ では、アプリケーションが既存のプラットフォームから移行する際に、対話型の UI 動作とエンド ユーザーの変更を最小限に抑えることで、ユーザー エクスペリエンスが最新化されます。
コマンド バー のカスタマイズでは、さまざまな段階でビジネス ルールと承認プロセスが管理されます。
ビジネス プロセス フロー (BPF) は、ユーザーが既存のステージを視覚化するのに役立ちます。
PDF の生成
以前のシステムの PDF エクスポート機能は非常に複雑であり、テンプレートのマイナー更新でも頻繁に技術的な介入が必要でした。
新しいソリューションでは、次のものが使用されます。
Word/PDF 生成用の OOTB エンティティ ドキュメント テンプレート。
管理者が制御するテンプレートの変更。技術チームへの依存関係を排除します。
このアプローチにより、ターンアラウンド時間が大幅に短縮され、開発主導のテンプレート更新が不要になります。
ワークフローと承認
業務プロセス フロー は、要求のルーティング、承認、および多段階の進行状況の追跡を調整します。
Power Automate フローは、各承認ステージの完了時に、Outlookと Teams への通知の送信、タスクの割り当て、最終段階での自動 PDF の生成など、さまざまなアクションを実行します。
ライフサイクルと終了の管理
Power Automate フローは毎日実行され、その日に期限が切れるSLAおよびサービス オーダーを確認します。
タスクのリマインダー
Power Automate フローは、期限が過ぎるとタスクが割り当てられているユーザーにアラームを送信します。
データ ソース
Dataverse を使用して、アプリケーション データを管理および格納し、監査ログ履歴を維持します。
SharePoint ドキュメント リポジトリおよびドキュメントのバージョン管理用。
レポーティング
Power Appsモデル駆動型アプリケーションの組み込みのレポート表示グラフと、アプリケーション データに関する分析情報を提供します。
考慮事項
これらの考慮事項は、ワークロードの品質を向上させる一連の基本原則である Power Platform Well-Architected の柱を実行します。 詳細については、Microsoft Power Platform Well-Architected を参照してください。
Reliability
以下に対する明確な期待を確立します。
- 応答時間
- 承認タイムライン
- 毎日のジョブ ウィンドウ (SLA の有効期限、終了ジョブ)
タスク ベースの回復性を実装します。 たとえば、Power Automateステップが失敗した場合は、次のようになります。
関連するアクションが完了するまで、タスクを Dataverse に保持します。
ユーザーが任意の段階で申請または承認を再試行できるようにします。
ワークフローのすべてのステップが実行された後にのみ、要求の状態を更新します。
ステージの更新が失敗した場合は、業務プロセス フローでエラーを表示します。
再試行ロジックを使用して毎日のジョブの失敗を処理し、動的フィルターに基づいてデータを取得します。
有効期間が短くステートレスなユーザー アクションを使用して、ワークフローがスタックする可能性を減らします。
ログ記録を使用して、要求データの信頼性を維持し、追跡可能性をサポートします。
セキュリティ
Dataverse 所有者チームにマップされた Microsoft Entra ID セキュリティ グループ を使用して、モデル駆動型アプリへのアクセスを制御します。
データ アクセスをセキュリティで保護するために、商用責任、プライマリ責任者、リクエスター、管理者のセキュリティ ロールを明確に定義します。
ゲスト ユーザーを組織のポリシーに従ってMicrosoft Entra IDに招待し、承認後にのみセキュリティ グループに追加します。 承認された外部ユーザーにも同じセキュリティ グループを使用します。
Dataverse フィールド レベルと行レベルのセキュリティを使用します。
Dataverse およびモデル駆動型アプリケーションとの組み込みの統合により、SharePointアクセス許可を付与します。
マネージド環境にアプリケーションをデプロイし、それに対する特定のデータ ポリシーを定義します。
Dataverse 監査ログを使用して、データの異常を検出します。
要求が特定のステージに達した後、データを読み取り専用にします。
アーカイブ ポリシーを実装して、管理者がアーカイブされたデータを完全に制御できるようにし、ユーザーは要求ごとに生成された PDF ドキュメントにのみアクセスできるようにします。
オペレーショナル エクセレンス
オペレーショナル エクセレンスを確保するための環境戦略を定義します。 開発、テスト、運用環境を設定し、必要に応じて マネージド環境 として構成します。
ソリューション戦略を実装します。
開発環境ではアンマネージド ソリューションを使用し、他の環境ではマネージド ソリューションを使用します。
UI コンポーネント、プロセス、およびコア コンポーネントをセグメント化するソリューションのセグメント化を設計します。
開発環境から移行する前にコード レビューを実装します。
より迅速な機能強化とバグ修正のために、低コードのコンストラクトでモデル駆動型アプリを構築します。
パフォーマンス効率
古いアプリケーションからのトランザクション ボリューム パターンを特定し、収集されたボリューム データに関するビジネスに同意します。
SLA の有効期限や終了の実行などの実行時間の長いアクティビティを、ユーザーの操作に依存しないスケジュールされたフローに委任します。
調整の制限を回避するには、一括 CRUD 操作にバッチ API を使用します。
エクスペリエンスの最適化
ランディング ページを強化するためのカスタム ページを作成します。
ユーザーが簡単に識別できるように、適切な形式の電子メールを送信します。
ユーザーが直接要求に移動できるように、電子メールにディープ リンクを含めます。
ユーザーが時間に応じてタスクを完了できるように、タイムリーなリマインダーを送信します。
マイ タスクと管理者セクションへのクイック リンクを追加します。
ユーザーが選択できるカスタム ボタンを追加して、実行するアクションを識別します。
各ボタンを選択した後に、成功または失敗をユーザーに通知します。
要求が特定のステージに達したときに不要なデータを非表示にします。
ユーザーにアクティブなアイテムのみが表示されるようにデータをアーカイブします。
関連するリソース
- Power Apps におけるモデル駆動型アプリとは何ですか？
- モデル駆動型アプリにカスタム ページを追加する
- ビジネス プロセス フローの概要
- Power Automate のドキュメント
- Dataverseドキュメント
- グループ チームを管理する
- ExcelテンプレートとWordテンプレートを使用します
- マネージド環境の概要
貢献者
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主要な著者: