シナリオ: 見積依頼は現在、販売ログ ワークブックに保存されています。ワークブックには次の情報が含まれています。
* 受注、失注、入札なし、およびキャンセルの値を持つ見積依頼 (RFQ) のステータス 営業担当者は、販売が終了し、顧客の注文書を受け取ったときに、販売ログの RFQ のステータスを落札に設定しないことがよくあります。
コードを記述したりプラグインを作成したりすることなく、ビジネス ルールと推奨事項を作成して、ロジックと検証を適用できます。ビジネス ルールは、急速に変化する一般的に使用されるルールを実装および維持するためのシンプルなインターフェイスを提供します。
エンティティに定義されたビジネス ルールは、エンティティがアプリで使用されている場合、キャンバス アプリとモデル駆動型アプリの両方に適用されます。
参照：
https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-create-business-rule ソリューションの作成 テストレット 3 これはケース スタディです。ケーススタディの時間は個別に設定されていません。各ケースを完了したいだけの試験時間を使用できます。ただし、この試験には追加のケース スタディやセクションがある場合があります。指定された時間内にこの試験に含まれるすべての問題を完了できるように、時間を管理する必要があります。
ケース スタディに含まれる質問に答えるには、ケース スタディで提供されている情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する資料やその他のリソースが含まれている場合があります。このケース スタディでは、各質問は他の質問とは無関係です。
このケース スタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認して変更を加えることができます。新しいセクションを開始すると、このセクションに戻ることはできません。
ケーススタディを開始するには
このケース スタディの最初の質問を表示するには、[次へ] ボタンをクリックします。質問に答える前に、左ペインのボタンを使用してケース スタディの内容を調べます。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題ステートメントなどの情報が表示されます。質問に答える準備ができたら、[質問] ボタンをクリックして質問に戻ります。
バックグラウンド
現在の環境
営業担当者は、毎週のステータス レポートを地域マネージャーに提出します。これらのステータス レポートには、標準化された形式はありません。進捗レポートを管理するプロセスは困難です。
Wide World Importers は、今後のアプリ開発に Microsoft 365、Microsoft Azure、および Power Platform を使用することを決定しました。Wide World Importers と Tailwind Traders はどちらも、Microsoft SharePoint と Azure の構成が同じです。両社は別々のテナントを使用しています。
要件
応用
営業担当者によるステータス レポートの作成を効率化するには、モバイル アプリを作成する必要があります。同じアプリを Tailwind トレーダーが利用できるようにする必要があります。モバイル アプリは、次の要件を満たす必要があります。
* コードの使用を最小限に抑えます。
※必要に応じて数式や表現を使用してください。
* さまざまなビジュアル レイアウトをサポートします。
* SharePoint リストを使用して、地域のマネージャーと営業担当者に関する情報を保存します。
* Azure SQL データベースを使用して他のデータを保存します。
進捗報告
* 営業担当者は、毎週月曜日にすべての作業プロセスの週次ステータス レポートを提供する必要があります。
※代表者は、各工程ごとに以下の情報を入力する必要があります。

* 営業担当者がステータス レポートを提出し、リスクありステータスをプロセスに割り当てた場合、アプリは営業担当者にリスクの詳細な説明を入力するように求める必要があります。この情報は、地域マネージャーに電子メールで送信する必要があります。カテゴリがワーク/ライフ バランスの場合、情報は人事部にカーボン コピーする必要があります。
* 営業担当者が合意された期限までに週次ステータス レポートを提出しない場合、システムは営業担当者に通知するために電子メールを送信する必要があります。
* アプリはオンラインとオフラインの両方で実行できる必要があります。アプリが実行されているモバイル デバイスがインターネットに接続されている場合、アプリはすぐにステータス レポートを送信する必要があります。
* 営業担当者がレポートを提出する前にアプリがオフラインかどうかを知ることができるように、アプリに視覚的なインジケーターを表示する必要があります。
※オフラインでデータを提出した場合、アプリがオンラインに戻るまでデータをアプリに保存する必要があります。
テクニカル
UI レイアウトに関係なく、記録されたデータは Azure DB テーブルで標準化する必要があります。アプリでグローバル変数を使用する必要があります。
展開
* アプリを運用環境に展開する前に、アプリが Microsoft のアクセシビリティとパフォーマンスのガイドラインに準拠していることを確認する必要があります。
* 完成したアプリとすべてのサポート コンポーネントを Tailwind トレーダーに提供する必要があります。
* Tailwind トレーダーは、どのコンポーネントも変更できてはなりません。
* 次のバージョン管理番号スキームを使用する必要があります。
* Major: アプリがパッケージ化された年の下 2 桁
* マイナー: アプリがパッケージ化された月を表す 2 桁の数字
* ビルド: アプリへの重要な変更を表すために増分される数値
* リビジョン: パッケージのインクリメントされたリビジョン
* アプリケーションの新しいバージョンは、以前のバージョンのアプリを完全に置き換える必要があります。
* アプリ ソリューションのバージョンを特定するときは、個々のコンポーネントを以前のバージョンに戻すことによって発生する意図しない問題を回避するために、すべての依存関係、エンティティ、およびユーザー インターフェイス コンポーネントを特定する必要があります。
* ロールバックのために、以前のバージョンのモバイル アプリが利用可能である必要があります。
* 本番環境で使用されたソフトウェアのすべてのバージョンは、5 年間保持する必要があります。
問題
モバイル アプリは数か月間稼働しています。アプリの最初のバージョンが営業担当者に展開されて以来、アプリの 8 つのバージョンがリリースされました。アプリを以前のバージョンに戻し、一部の機能を再設計する必要があります。
User1 は、多くの場合、インターネット接続のない倉庫で働いています。User1 は、既存の進捗レポートを編集し、新しい進捗レポートを提出する必要があります。
一部の営業担当者はアクセシビリティ制限を設けています。User2 は視覚障害があり、画像を見ることができません。User3 はマウスを使用できません。