作業指示書フォームのカスタマイズ

組織をセットアップする際に、ディスパッチャやサービス マネージャなどのバックオフィス ワーカーが重要な情報を表示したり作業を文書化したりするために使用するフォームをカスタマイズする必要がある場合があります。 Dynamics 365 Field Service IT管理者は、フォームのレイアウトがビジネス プロセスと一致し、ユーザーがビジネスや業界に固有の情報を取得できるように、Field Serviceフォームをカスタマイズする場合があります。

パフォーマンスを最大化するには、フォームを正しくカスタマイズすることが重要です。 フォームのカスタマイズは、フォームの読み込みと変更の保存にかかる時間に影響する可能性があります。 フォームを正しくカスタマイズすると、使いやすさが向上します。 したがって、ユーザーはより簡単に情報を表示および更新できます。

この記事では、作業指示書 フォームをカスタマイズする方法について説明します。 ただし、これらの手順は、任意のField Service Webフォームをカスタマイズするために使用できます。

注意

モバイル アプリの 作業指示書 フォームをカスタマイズする方法については、 「予約と 作業指示書 フォームの編集」を参照してください

ステップ 1. デフォルトの作業指示書フォームを理解する

作業指示書 フォームをカスタマイズする前に、Field Serviceに含まれているデフォルトの 作業指示書 フォームを理解していることを確認してください。 既存のフィールドと推奨されるプロセス フローを理解することで、フォームにどのような変更を加えるべきかを判断するのに役立ちます。 パフォーマンス、使いやすさ、アップグレード性を向上させるために、デフォルトのフィールドとプロセスを使用することをお勧めします。

  1. フィールド サービス>作業指示書 に移動し、既存のレコードを 選択 するか、新しいレコードを作成します。

  2. デフォルトのフィールドを確認して理解し、どのフィールドをビジネスに使用できるかを判断します。

    製品とサービスを表示するフィールド サービス 作業指示書 のスクリーンショット。

標準の 作業指示書 プロセス

デフォルトの 作業指示書 フォームは、次の標準の 作業指示書 プロセス用に最適化されています。

  1. 作業指示書 は、手動で、変換されたケースから、モノのインターネット (IoT) アラートから、契約スケジュールから、または統合を介して作成されます。 デフォルトでは、新しく作成された作業指示書のシステム ステータスは 「未スケジュール」になります
  2. 作業指示書 の詳細が入力されます。 これらの詳細には、アカウント、作業指示書 タイプ、場所、製品、サービス、サービス タスク、その他の重要な情報が含まれます。
  3. 作業指示書 は、1人以上のリソース (「最前線の作業者」) にスケジュールされます。 システム ステータスは自動的に 「スケジュール済み」 に変更されます。
  4. 最前線の作業員は、モバイル アプリでスケジュールされた 作業指示書 を確認し、顧客の場所まで出向いて必要な作業を実行します。 システム ステータスが 進行中 に変更されます。 最前線の作業者は、現場に到着した時間、完了したサービス タスク、請求するサービスや製品などの情報を更新します。
  5. 最前線の労働者が 作業指示書 を完了します。 システムステータスが 完了に変更されます。
  6. バックオフィス マネージャーまたはディスパッチャーは、完了した 作業指示書 を確認し、作業が完了し、必要なデータが取得されたことを確認します。 すべてが完了すると、システム ステータスは Posted に変更されます。

詳細については、 作業指示書 ライフサイクルとシステム ステータス をご覧ください。

クリティカル フィールド

次のフィールドは、Field Service の作業指示プロセスにとって重要であり、必須です。 組織でこれらのフィールドを使用する予定がない場合は、別のエンティティ テーブルを使用するか、新しいエンティティ テーブルを作成することを検討してください。

  • 作業指示書番号
  • システムの状態
  • サービス アカウント
  • 請求先取引先企業
  • 価格表
  • 作業指示書の種類
  • 作業場所
  • 住所
  • 経度
  • Longitude

次のサブグリッドも、Field Service作業指示書 プロセスにとって重要であり、強く推奨されます。

  • 予約可能リソースの予約 ("予約")
  • サービス タスク
  • 製品
  • サービス

詳細については、 作業指示書 アーキテクチャ および 作業指示書 の作成をご覧ください。

ステップ 2. 必要なフィールドと不要なフィールドのリストを作成する

ビジネス プロセスに関連するデフォルトの 作業指示書 フィールドのリストを作成します。 不要なフィールドのリストをもう1つ作成します。 重要なフィールド は必須なので、必要なフィールドのリストに必ず追加してください。

ステップ 3. 必要に応じて新しいフィールドを作成する

デフォルトの 作業指示書 フォームに必要なフィールドが不足している場合は、新しいフィールドを作成します。

ベスト プラクティスの詳細については、「 Field Service列の作成と編集」を参照してください。

重要

デフォルトのフィールドを編集するときは注意してください。 デフォルトのフィールドは削除しないでください。

ステップ 4. 作業指示書 フォームのカスタマイズを開始する

Field Serviceに含まれている既存の (デフォルトの) 作業指示書 フォームを使用することをお勧めしますが、新しいカスタム 作業指示書 フォームを作成する必要があるシナリオもあります。

次のタブ付きのセクションでは、それぞれのアプローチの長所と短所について説明します。 また、それぞれのアプローチを開始するための手順も含まれています。

組織が レイアウト またはフィールドに多くの変更を加えたくないシナリオでは、既存の 作業指示書 フォームの方が適しています。 また、通常はデフォルトの 作業指示書 プロセスを使用したい組織にとっても、より適切な選択肢となります。

長所

  • お勧めです。 既存のフォームはMicrosoftによって推奨されています。
  • アップデートを受信します。 既存のフォームは、パフォーマンスと新機能の更新を受け取ります。
  • より優れたサポート性を提供します。 既存のフォームを使用すると、サポート チームが問題を診断して修正しやすくなります。

デメリット

  • カスタマイズ性は低くなります。 既存のフォームを使用することに同意すると、フォームへの変更が少なくなることに同意したことになります。
  • アップグレードをテストする必要があります。 既存のフォームは年に2回ほど更新されます。 サンドボックス 環境 で新しい更新をテストし、ユーザーに支障をきたさないことを確認します。 詳細はこちら フォームのカスタマイズをマージする

既存の作業指示書フォームのカスタマイズを開始します

  1. Power Apps にサインインします。

  2. テーブル を選択します。

  3. 作業指示書 を検索して選択します。

  4. データ エクスペリエンスで、フォームを選択します。

  5. メインの 作業指示書 フォームを検索します。

    メインのフィールド サービス 作業指示書 フォームのスクリーンショット。

ステップ 5 フォームのタブ、セクション、フィールドを非表示にする

次のステップは、不要なタブ、セクション、およびフィールドを非表示にすることです。 アイテムを削除するのではなく、非表示にすることをお勧めします。 このアプローチはエラーの可能性を減らすのに役立ちます。 さらに、必要になった場合に後でアイテムを簡単に追加し直すことができます。 フィールドを並べ替えたり追加したりする前に、項目を非表示にします。

注意

クリティカル フィールド を非表示にしません。 組織でこれらのフィールドを使用する予定がない場合は、新しいエンティティ テーブルの作成を検討してください。

不要なタブを非表示にする

タブはフォームの上部に水平に表示されます。 不要なタブを非表示にします。 概説タブは非表示にすることはできません。

タブの [非表示] チェックボックスが選択されていることを示すスクリーンショット Power Apps。

不要なセクションを非表示にする

セクションはタブ上の領域です。 必要のないセクションを非表示にします。 必要なセクションにフィールドが1つしかない場合は、そのフィールドを別のセクションに移動し、不要なセクションを非表示にします。

不要なフィールドを非表示にする

重要なフィールドでない限り、必要のないフィールドは非表示にします

作業指示書, 作業指示書 製品および 作業指示書 サービス フォームから、価格関連のフィールド ( 価格表合計金額 など) をすべて削除する簡単でサポートされている方法があります。

  1. Field Serviceアプリにログインします。
  2. 選択 設定 領域。
  3. 全般 セクションで、Field Service 設定 を選択します。
  4. 作業指示書 / Booking タブで、 価格計算 フィールドを いいえに設定します。 詳細については、 作業指示書 / 予約設定をご覧ください。

作業指示書, 作業指示書 製品および 作業指示書 サービス フォームから、税金関連のフィールド ( 課税対象 など) をすべて削除する簡単でサポートされている方法があります。

  1. Field Service で、設定 範囲を開きます。
  2. 全般 セクションで、Field Service 設定 を選択します。
  3. 作業指示書 / Booking タブで、 税金の計算 フィールドを いいえに設定します。 詳細については、 作業指示書 / 予約設定をご覧ください。

ステップ 6: フォームにカスタムフィールドを追加する

以前にカスタム フィールド (列) を作成した場合は、フォームに追加します。 最良の結果を得るには、次のガイドラインに従ってください:

  • (必須) 新しいフォーム セクションに新しいカスタム フィールドを追加します。
  • (強く推奨されますが、必須ではありません) 新しいフォーム タブに新しいカスタム フィールドを追加します。
  • 必要がない限り、最初のフォーム タブに新しいカスタム フィールドを追加しないでください。 (デフォルトでは、最初のタブは概要タブです。) 最初のタブにカスタム フィールドがあると、フォームの読み込み時間が遅くなります。 特に、最初のフォーム タブにサブグリッドやルックアップ フィールドを追加することは避けてください。読み込み時間が大幅に遅くなる可能性があるためです。

この例では、 Source という名前の新しいカスタム フィールドがあります。 これは、作業指示書 が、たとえば、電話、電子メール、IoTアラート、または契約から発生したかどうかを 選択 するために使用される選択タイプのフィールドです。 このカスタム フィールドを 作業指示書 フォームに追加します。

  1. Power Appsで、作業指示書 フォーム エディター.を開きます

  2. ツールバーの 選択 コンポーネント をクリックし、左側の コンポーネント ペインで、選択 1列タブ2列タブ、または 3列タブを選択します。

     Power Appsの 作業指示書 フォームに追加された新しい1列のタブを示すスクリーンショット。

  3. ビジネス プロセスに基づいてタブの名前を変更します。

    新しいフォーム タブが作成されると、その上に新しいセクションが自動的に作成されます。

  4. 新しいタブの新しいセクションにカスタム フィールドを追加します。必要に応じて、新しいタブと新しいセクションを追加できます。

新しいセクションにカスタムフィールドを追加します(必須)

既存のタブにカスタム フィールドが必要な場合は、タブに新しいセクションを作成し、新しいセクションにカスタム フィールドを追加します。

重要

既存のセクションに新しいカスタム フィールドを追加しないでください。 新しいセクションを作成する必要があります。 さらに、最初のフォーム タブ (デフォルトでは概要タブ) に新しいセクションやカスタム フィールドを追加しないでください。 最初のタブのカスタム フィールドにより、フォームの読み込み時間が遅くなります。

たとえば、作業指示書 フォームの [全般] タブに新しいセクションを作成し、そこにカスタム フィールドを追加するとします。

新しいセクションを示す  Power Apps  の 作業指示書 フォーム エディター のスクリーンショット。

フォームの編集方法の詳細については、「 フォーム デザイナー を使用してフォームを作成、編集、または構成する」を参照してください。

ステップ 7: ツールを使用してフォームをテストする

ブラウザ、ネットワーク パフォーマンス、データ クエリなどの要素がアプリとフォームのパフォーマンスにどのように影響するかを判断するには、 パフォーマンス インサイトを実行します。

フォームの読み込み時間が遅い根本的な原因を理解するには、監視ツールを使用します。 詳細については、 モニターを使用してモデル駆動型アプリのフォームの動作をトラブルシューティングするを参照してください。

フォーム スクリプト

作業指示書には、フォーム スクリプト ライブラリが含まれています。 すぐに使用できるフォーム ライブラリを編集または削除しないでください。

フォームが読み込まれ、変更され、保存されると、多くの組織ではコード スクリプトを実行して検証を実行し、プロセスを実行します。 フォーム スクリプトは、読み込み時間などのフォームのパフォーマンスの側面に大きな影響を与える可能性があります。 ソリューション チェッカーを実行してスクリプトの問題をテストするなどのベスト プラクティスの詳細については、「 複雑なビジネス ロジックを実装するスクリプトの作成」を参照してください。