Field Service：ディスパッチャコンソールの表示項目の変更
arinoです。
ディスパッチャコンソールに表示される項目の変更方法について記載します。
本記事で説明する箇所は下記の部分。
表示される項目はサービス予定の項目セットで設定されています。
項目セットに格納している項目を変更することで、表示を変更することができます。
①Service Appointment List Columns
②Service Appointment Expanded
③Service Appointment List Preview
※項目セットに項目がない場合、ヘルプテキストは表示されません。
・注意点
項目セットに他オブジェクトのレコードを記述しても、ディスパッチャコンソールには表示されません。
表示したい場合はサービス予定オブジェクトに数式項目等を作成し、値を取得してくる必要があります。
下記のように取引先の項目を項目セットに格納しても･･･
･･･項目は表示されない。
その他、ディスパッチャコンソールの項目表示に関する項目セットは下記ヘルプページにまとめられてます。
項目セットを使用したディスパッチャコンソールのカスタマイズ
フロー：Chatter(FeedItem)投稿時に起動するフローの作成
arinoです。
Chatter投稿で起動するフローの作成について記載します。
設定からフローを新規作成。
フロー作成時に、"レコードトリガフロー"を選択します。
オブジェクトに"フィード項目"を選択します。
これで、Chatter投稿時にこのフローが起動するようになります。
後は動作させたい処理を後ろに設定すればよいです。
今回はサンプルとして、Chatter投稿で取引先データを作成する処理を作成します。
テスト時にテスト用の取引先データを作成するのが面倒なので、その時間を短縮することが目的です。
まずはChatterメッセージに応じて分岐する決定ロジックを作成します。
起動条件は以下のように設定します。
リソース：{!$Record.Body}
演算子：次の文字列で始まる
値：<p>取引先作成：
これで「取引先作成：」と入力したChatterを判別することができます。
値の最初に"<p>"と入力する理由は画面から投稿するChatterはリッチテキストとして保存されるため行ごとに<p>~</p>で括られているためです。
次に作成する取引先レコードの取引先名をリソースで作成します。
リソースは以下のように設定します。
リソース種別：数式
データ型：テキスト
数式：SUBSTITUTE(MID({!$Record.Body},4,LEN({!$Record.Body})-7),"取引先作成：","")
この設定で「取引先作成：〇〇〇〇」とChatterで入力した際に、
「〇〇〇〇」という名称をリソースに格納することができます。
レコード作成処理を追加します。
オブジェクトは取引先を指定し、Name項目に先ほどのリソースを設定します。
最後に作成した処理を繋げて完成です。
完成した後は保存→有効化もおわすれなく。
実際にChatter投稿をします。
「取引先作成：テスト用取引先20210905」というChatterを投稿。
実際に取引先画面を確認すると、作成されていることを確認できます。
これで手動でテスト用レコードを作成するよりは、時間を短縮することが可能になりました。
フローはアクションも豊富なので、Chatter起動で色々なことができるかと思います。
Field Service：在庫の設定
arinoです。
在庫管理に関する事前の設定について記載します。
フィールドサービスの在庫の設定
Salesforceで在庫管理を行うための設定を行います。
在庫設定のカスタマイズ
在庫に関するレコード作成を行う前に、権限設定・各種オブジェクトのページレイアウト設定を変更する必要があります。詳細は上記ヘルプページを参照してください。
ロケーションページレイアウトの設定
在庫ロケーション設定で必要となる項目をページレイアウトに追加します。
オブジェクトマネージャからロケーションを選択し、ページレイアウト設定を変更します。「在庫のロケーション」項目、「モバイルのロケーション」項目が追加されていないため、レイアウトに追加して保存します。
フィールドサービスの在庫ロケーションの設定
ロケーションは在庫が保管される場所です。
基本的な倉庫だけではなく、バンやトラックといった商品を積み移動するものもロケーションとして登録します。
ロケーションの作成
ロケーションのレコードはロケーションタブ→新規ボタンで作成できます。
ロケーションの名前を入力し、種別を選択します。
作成するロケーションで在庫管理するために、「在庫のロケーション」項目にチェックを入れます。ロケーションが、在庫を運ぶことのできるバンやトラックの場合は「モバイルのロケーション」項目にチェックを入れます。
サービステリトリーロケーションの作成
サービステリトリーロケーションはロケーションがどのサービステリトリーに存在するかを表します。
サービステリトリーロケーションはロケーションレコードの関連リストから作成できます。
サービステリトリーを指定して保存をします。
在庫を表す商品項目の作成
商品項目はロケーションに保管されている在庫の商品です。
在庫の使用状況を追跡したり、必要に応じて在庫を補充することができます。
商品項目の作成
商品項目はロケーションレコードの関連リストから作成できます。
商品名と在庫数量を記入し保存します。
シリアル番号を指定した場合には、数量は1で記入します。シリアル番号を入力した商品は、モバイルアプリケーションから1つしか消費することができないためです。
以上で在庫の設定は完了です。
在庫設定をすることで、作業時の在庫消費やロケーション間の移送を行うことができます。
Field Service：サービスクルーの作成
arinoです。
今日はサービスクルーについて記載します。
サービスクルーの作成
サービスクルーは複数のサービスリソースからなるグループです。
後に記載するクルー種別のリソースを作成することでサービスクルーを作業に割り当てることができます。
サービスクルーの作成
サービスクルーのレコードはサービスクルータブ→新規ボタンで作成できます。
名前とクルーサイズに値を入力して保存をします。
サービスクルーメンバーの作成
サービスクルーメンバーはサービスクルーに所属するサービスリソースを表します。
サービスクルーレコードページのサービスクルーメンバー関連リストの新規ボタンから作成できます。
サービスクルーに加えるサービスリソースを選択、クルーメンバーとしての期間(開始日～終了日)、リーダーであるかどうかのチェックを記載して保存します。
選択したサービスリソースの業務量ベースにチェックが入っている場合は、サービスクルーに含めることができません。
サービスクルーの業務量ベース項目のチェックを外してクルーメンバーに含めましょう。
サービスクルーを表すサービスリソースの作成
クルーを表すサービスリソースは、スケジュールするために必要になります。
サービスリソースのレコードはサービスリソースタブ→新規ボタンで作成できます。
サービスクルーに作成したサービスクルーを指定し、リソース種別にクルーを指定し、有効にチェックをいれて保存します。サービスクルーが表示されない場合は、ページレイアウトで項目を追加してください。
サービスクルーにサービスクルーメンバーが1つも設定されていない場合は、有効化することができずエラーが表示されます。
クルー種別のサービスリソースを作成することで、サービスクルーをサービスで割り当てることができるようになります。
サービスクルーは管理パッケージに入っている、Crew Managementタブからも作成できます。
こちらで作成した場合には、サービスクルーを表すクルー種別のサービスリソースは自動的に作成されます。
Field Service：サービスリソースの作成
arinoです。
サービスリソースについて記載します。
フィールドサービスのサービスリソースの作成
サービスリソースは、作業を実施する人です。
サービスリソースのレコードはサービスリソースタブ→新規ボタンで作成できます。
サービスリソースとして設定するユーザと、そのリソース種別を選択して保存します。
名前は設定したユーザ名と同じ名前にすることが推奨されてるようです。
サービスリソースの業務量の定義
一定の期間で決まった量だけ作業ができるよう設定することができます。
サービスリソースの「業務量ベース」項目にチェックを入れます。
業務量の関連リストから業務量レコードを作成します。
関連リストがない場合は、ページレイアウトに追加してください。
各種項目を設定します。
作業時間数で業務量を指定する場合は、「期間あたりの時間数」項目に時間数を入力します。
サービス予定の対応数(割り当て)で業務量を指定する場合は、「期間あたりの作業項目数」項目に割り当て数を入力します。
設定した業務量は、サービスリソースレコードに配置されたVF:Resource ViewsのCAPACITYで確認できます。こちらで業務量を定義することも可能です。
考慮事項等、他項目は後日追記予定
Field Service：作業種別の作成
arinoです。
作業種別の作成について記載します。
フィールドサービスの作業種別の作成
作業種別は、作業指示のテンプレートです。
作業指示の作成時に、予め作業種別に設定した値が作業指示の各種項目に自動的に設定されます。
フィールドサービスの作業種別作成のガイドライン
作業種別のレコードは「Field Service Admin」アプリケーションの作業種別タブ→新規ボタンで作成できます。
所要時間種別は時間、分のどちらかを選べて、予想所要時間に選んだ単位での時間値を入力します。
スキル要件
作業を実施するために必要なスキルを関連付けることができます。
スキル要件は関連リストから作成できます。
スキル要件に設定したスキルとスキルレベルは、作業指示にも自動作成、設定されます。
必要商品
作業に必要な商品を関連付けることができます。
必要商品も関連リストから作成できます。
必要商品に設定した商品、数量、単位は、作業指示に自動作成、設定されます。
自動作成されたサービス予定
「サービス予定を自動作成」項目にチェックを入れていると、作業種別をテンプレートとして指定した作業指示を作成すると、サービス予定も自動的に作成されます。
作業種別を指定して作業指示を作成すると･･･
自動的にサービス予定が作成されます。とても便利です。
スキル作成のガイドラインについてのヘルプについては、また次回以降に記載します又は本記事に追記します。
Field Service：サービステリトリーの作成
arinoです。
今日からまた再開していきます。
フィールドサービスのサービステリトリーの作成
サービステリトリーは、作業する地域(エリア)です。
サービステリトリーにはサービスリソース(人)を関連付けることができて、そのテリトリーで作業を実施します。
フィールドサービスのサービステリトリー作成のガイドライン
サービステリトリーの作成
サービステリトリーのレコードは一般的な他のオブジェクトと同じで、タブをクリック→新規ボタンから作成することができます。
作成時に注意が必要なのが営業時間レコードを作成しておく必要があることです。
作成してない場合は、「新規営業時間」でついでに作ってしまうのが良いですね。
テリトリーサイズの決定
サービステリトリーは、下記の制限内に収めるよう推奨されています。
・サービステリトリーあたり最大50人のサービスリソース
・サービステリトリーごとに1日あたり最大1,000件のサービス予定
・サービス予定あたり最大20人の有資格のサービスリソース
これらサービステリトリーに関連付いたレコード数を総じて"テリトリーサイズ"と呼ぶみたいですが、制限以上の数になるとディスパッチャーコンソールでのスケジューリングや最適化に影響が出るみたいですね。
Dev環境では50人も作ることができないので、実際にそうなるのかは未確認です。
サービステリトリーメンバーの作成
サービステリトリーメンバーはテリトリー内で作業するサービスリソースです。
サービステリトリーレコードページのサービステリトリーメンバー関連リストの新規ボタンから作成できます。
作成時にはテリトリー種別を3種類から選びます。
プライマリテリトリー：リソースが最も頻繁に作業するテリトリー (本拠地の周辺など) です。リソースに割り当てることができるプライマリテリトリーは1つのみ。
適用されるスケジュールポリシーに [テリトリーを照合] 作業ルールが含まれている場合、プライマリテリトリーまたは再配置テリトリーの予定にのみ割り当てることができる。
セカンダリテリトリー：リソースを必要に応じて予定に割り当てることができるテリトリー。リソースに複数のセカンダリテリトリーを割り当てることができる。
再配置テリトリー：一時的な異動を表し、有効な期間中はスケジュールでプライマリテリトリーとして機能する。適用されるスケジュールポリシーに [作業テリトリー] 作業ルールが含まれている場合、セカンダリテリトリーの予定にも割り当てることができる。
メンバーシップの開始時間と終了時間の設定
サービスリソースがサービステリトリーのメンバーとして活動する期間を設定します。
簡潔にするために、いずれの項目も午前0時(00:00)を使用することがお勧めされているようです。
スケジュールの最適化では、サービステリトリーメンバーのユーザ自身に設定されているタイムゾーンが使用されます。
ユーザのタイムゾーンがサービステリトリー(営業時間)のタイムゾーンと異なる場合は、開始時間と終了時間を調整します。
たとえば、ユーザのタイムゾーンがサービステリトリーのタイムゾーンよりも3時間遅れている場合は、サービステリトリーメンバーの開始時間を00:00ではなく3:00に設定する必要があります。
サービステリトリーの削除
サービス予定のあるサービステリトリーは削除することができません。
別のテリトリーに割り当ててから削除する必要があります。
削除しようとすると･･･
関連付いているサービス予定が表示されて却下されます。
業務時間作成のガイドラインについてのヘルプについては、また次回以降に記載します。
7日の記事内容と被る部分が多いので、7日の記事は後ほど削除しようと思います。→削除しました。
