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

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