
説明
グラフィカル ユーザー インターフェイス、アプリケーション、自動生成される Word の説明

ボックス 1: Power Apps Web スタジオ
シナリオ: インターネットに問題がある場合でも、チェックイン ソリューションは機能し続ける必要があります。セルフサービス キオスクが利用できない場合、スタッフは通信ソリューション内からチェックイン ソリューションを使用できる必要があります。
PowerApps Studio は、アプリの編集に使用されるブラウザ アプリケーションです。PowerApps Studio には、画面の中央にドラッグ アンド ドロップ キャンバスがあり、左側に画面またはオブジェクト リスト ペインが含まれています。選択した画面またはコントロールのプロパティ、ルール、および詳細プロパティが右側のペインに表示されます。
ボックス 2: タブ内
[PowerApps] タブを使用して Power Apps キャンバス アプリを Teams のチャネルに追加することで、Teams エクスペリエンスをカスタマイズできます。
トピック 2、アダタム株式会社
これはケーススタディです。ケーススタディは個別に時間が設定されるわけではありません。各ケースを完了したいだけ試験時間を費やすことができます。ただし、この試験には追加のケーススタディやセクションが存在する場合があります。この試験に含まれるすべての質問を指定された時間内に完了できるように時間を管理する必要があります。
ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれる場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
背景
ADatum Corporation は、保険会社、法律事務所、その他の公共部門の組織が使用する検証および調査サービスを提供しています。サービスには、個人の経歴、資格、オンサイト訪問を必要とする特定のシナリオの確認が含まれます。
ADatum Corporation が実行する徹底した作業により、重要な情報の欠落が最小限に抑えられた非常に正確な症例が得られます。これらの高品質の結果により、ADatum Corporation は業界で最高の企業の 1 つであることを急速に証明しています。ここ数カ月でビジネスは大幅に増加しており、新規ビジネスのほとんどは著名な企業や個人からのものです。
経営陣は、クライアントが最も正確な結果を確実に得られるように、新しい資格検証 (QV) ロールを作成することを決定しました。この役割は、完了した作業を検査して、漏れがないことを確認します。
現在の環境
データのストレージと保持
サービスのためにクライアントから送信されたすべての情報は、モデル駆動型アプリをインターフェイスとして使用して Microsoft Dataverse に保存されます。
クライアントは Web サイトにデータを入力し、サービス アカウントを使用して Dataverse データベースにレコードを作成します。
現在、チーム メンバーはすべてのサービス リクエスト レコードに完全にアクセスできます。
サービスリクエスト
サービス リクエスト テーブルには、検証の対象となる個人または組織に関するヘッダー情報が含まれています。
新しいサービス リクエスト レコードはキューに割り当てられます。検証を実行するすべての潜在的なユーザーは、これらのレコードにアクセスできます。
サービス リクエストは、すべての資格が検証されることを保証する 1 人のユーザーに割り当てられます。この 1 人のユーザーだけが、自分自身のサービス リクエストに関連する資格レコードを処理できます。
検証サービスを実行する際に必要なタスクの多くは、現在手動プロセスを使用して行われています。
需要に対応するために、ADatum Corporation は、Power Automate フローを使用して置き換えることができるいくつかのプロセスを特定し、新しいスタッフの雇用を減らし、コストを抑えます。
資格確認
資格テーブルには、個々の学校の学位、専門資格、および確認が必要なその他の資格に関する詳細が含まれています。
サービス リクエストには、1 つ以上の資格レコードを関連付けることができます。
レコードのステータスは、最初のチーム メンバーが終了するまで検証が保留され、その時点でメンバーはステータスを [完了] に変更します。
サービス リクエストに関連するすべての認定記録が手動または自動プロセスによって検証されると、その結果が ADatum Corporation のクライアントに提供されます。
まれに結果に疑問が生じた場合には、以前に行われた作業とは別に、新しいサービス リクエストが作成され、検証されます。
サービス リクエストを完了するには、ユーザーは次のアクションを実行します。
サービス リクエストのすべての資格がチェックされた後、Microsoft Outlook を使用してテンプレート化された電子メールをクライアントに送信します。
サービス リクエストのステータスを完了に変更します。現在、サービス リクエストには、すべての資格レコードがいつ処理されるかが示されていません。
Microsoft Power プラットフォーム環境
次の環境が存在します: 開発、テスト、ユーザー受け入れテスト (UAT)、および運用。
マネージド ソリューションは、カスタマイズを開発環境から他の上位レベルの環境に移動するために使用されます。これらのソリューションはパワー ユーザーによって作成および保守され、準備ができたら導入のために社内 IT に提供されます。
Verification Process Automation と Onsite Visit という 2 つのマネージド ソリューションは、いくつかのコンポーネントを共有しています。
Power Platform コンポーネントに対するすべてのカスタマイズは、トレーニングを受け、対象分野の専門家として認定された数名のパワー ユーザーによって実行されます。
パワー ユーザーには、開発環境におけるシステム管理者のセキュリティ ロールが付与されています。
正式なコードレビュープロセスがないため、企業ポリシーによりパワーユーザーがコードを書くことが禁止されています。
スタッフ不足のため、社内 IT 部門はこのプロジェクトに開発リソースを供給できません。
これは、このプロジェクト用に作成されたカスタマイズと自動化は、パワー ユーザーが実装できるようにローコード/ノーコードでなければならないことを意味します。
パワー ユーザーが作成したカスタマイズは、社内 IT によって展開されます。
要件
プロセスの自動化
アダタム株式会社では、完成した作品を検証し、作品の品質を維持するためのQV部門を新設する予定です。専門資格を検証するための新しいプロセスでは、以下を自動化する必要があります。
データを入力し、当局の Web サイトに移動します。同社は常にユーザー エクスペリエンスを向上させているため、権威ある Web サイトの UI は頻繁に変更されます。
ページのコンテンツで指定された値を検索して、有効性を判断します。
Dataverse の対応する資格レコードを更新します。
サービス リクエストを完了するための新しいプロセスでは、以下を自動化する必要があります。
すべての資格レコードに対する作業が完了したら、サービス リクエスト レコードのステータスを完了に設定します。
サービス リクエストが完了したら、結果を記載した電子メールをクライアントに送信します。電子メールには、検証に応じて各資格を有効または無効として記載する必要があります。
資格確認
関連するすべての資格レコードが完了ステータスに設定されるまで、サービス リクエストの結果はクライアントにリリースされません。
幅広いユーザーが行った作業をチェックするには、資格記録の 10% を二重チェックする必要があります。
資格レコードは自動的にキューに割り当てられる必要があります。
レコードが確実に再チェックされるように、資格レコードには「割り当て済み」という名前の新しいステータス フィールドでフラグを立てる必要があります。
QV チーム メンバーのみがステータスを「割り当て済み」から「進行中」、そして「完了」に変更できるようにしてください。
作業を実行した QV チーム メンバーの名前と完了日を記録します。
ガバナンスとセキュリティ
検証プロセスに必要なすべてのコンポーネントを新しいソリューションに含める必要があります。
企業のセキュリティでは、サービス アカウントを使用して非開発環境への展開を自動化する必要があります。
ユーザーのセキュリティとデータ アクセスも、開発環境におけるパワー ユーザーの昇格されたアクセスを除き、環境間で一貫している必要があります。
Onsite Visit 管理ソリューションには、Verification Process Automation 管理ソリューションにはないテーブルがあります。このテーブルは、他の共有コンポーネントを使用せずに、運用開始日より前にアップグレードする必要があります。
営業担当副社長は、最初の製品に含まれるセキュリティ ポリシーを潜在的な顧客にデモンストレーションするためのテスト環境を必要とします。
問題
必要以上の従業員が個々の顧客情報にアクセスでき、サービス リクエストの完了後も引き続きアクセスできます。
ユーザーが休暇に入ると、未処理のサービス リクエスト レコードはすべて代替従業員に割り当てられます。代替従業員は、サービス要求に関連するすべての資格を確認することはできません。
現在、企業のセキュリティ ポリシーにより、すべての環境で同じセキュリティ ロールが必要とされているため、開発環境の外で新しい QV 機能をテストすることはできません。
内部 IT は、サービス リクエストを完了するためのフローに関連する依存関係が欠落しているため、テスト環境へのソリューションのインポートが失敗したと報告しています。