進行状況の追跡を始めよう
Trailhead のホーム
Trailhead のホーム

プロセス条件の順序の決定

学習の目的

この単元を完了すると、次のことができるようになります。
  • アクショングループの実行後、プロセスで何を行うかを設定する。
  • 条件ノードの順序を決める場合のベストプラクティスを説明する。
重要

重要

このモジュールで説明する例には、Trailhead Playground に存在しないカスタム項目とメールテンプレートが含まれています。このモジュールでは、ワークフロールールの移行の概念とベストプラクティスに重点が置かれているため、それらの項目やテンプレートを作成する方法については説明しません。概念を理解するために内容を一読することをお勧めしますが、Playground で演習ステップを実行しようとはしないでください。概念についての知識を適用して、各単元の終わりにある Challenge を実行します。安心してください。Challenge を実行するためにカスタム項目やメールテンプレートを作成する必要はありません。

決定論的なアプローチ

最後に、ワークフロールールを変換するための最終ステップでは、条件ノードの順序を決めます。条件ノードの順序について考えるときは、最終動作をどのようなものにするかも検討します。最終動作は順序に影響することがあり、その逆もあります。

プランのまとめにはいる前に、条件ノードの順序を計画するとき、何を検討すべきかを調べてみましょう。

最終動作の設定

プロセスによってアクションのグループが実行された後の処理を設定できることをご存じでしょうか? 行の最終要素 (デフォルトでは [停止]) をクリックすると、条件ノードの最終動作を設定できるようになります。

さまざまな最終動作を示すアニメーション 停止: 条件ノードが true に評価されると、関連付けられたアクションが実行されて、そのプロセスは終了します。プロセスに条件ノードが残っていても、Salesforce ではそれが評価されません。次の条件を評価: 条件ノードが true に評価されると、関連付けられたアクションが実行されてから、プロセスの次の条件ノードが評価されます。このオプションを使用できるのは、アクショングループにスケジュール済みアクションが含まれていなくて、評価すべき条件ノードが他にあるときのみです。プロセスの最後の条件ノードでは、常に [停止] オプションが使用されます。
メモ

メモ

プロセスで次の条件ノードが評価される場合は、プロセスの最初にレコードに含まれていた値が評価されます。例:

  1. ケースが編集されて、その状況が [新規] になります。
  2. プロセスで条件 1 が評価されます。条件が合ったため、Salesforce によってケースの状況が [エスカレーション済] に更新されます。
  3. プロセスで条件 2 が評価されますが、ステップ 1 のレコード値が使用されます。

プロセス内で発生した変更に対してプロセスに反応させるには、オブジェクトノードの詳細オプションを選択します。

上書きするアクションに対する注意事項

複数のアクショングループが同じ項目を更新するときは、特に注意してください。最後に実行されるアクショングループの更新が有効になります。

順序の最終決定

では、順序についてここまでに学習した内容をケースプロセス条件に適用してみましょう。前の単元でアクションに行ったように、各プロセスで条件の順序のゲームプランを作成します。

最上位プロセスの順序

確認になりますが、最上位プロセスには 3 つの条件ノードが含まれています。

条件名 アクション
即時 スケジュール スケジュール済み
プラチナ契約のケースクローズ N/A 完了日の 7 日後 メールアラート: フィードバック要求をケースの取引先責任者にメールで送信
エスカレーションキーワード

レコードを更新: [優先度] を [影響するサービス] に、[サポートレベル] を [Tier 3] に設定

クイックアクション: [目標解決日] を TODAY() に設定

N/A N/A
新規ケース プロセス: 新規ケース、このプロセスを開始したケースの参照を含める N/A N/A

プラチナ契約のケースクローズにはスケジュール済みアクションが含まれているため、その最終動作は [停止] にする必要があります。その他 2 つの条件ノードは相互に排他的なので、両方の最終動作として [次の条件を評価] を使用します。プロセスが常にエスカレーションキーワードと新規ケースを両方とも評価するように、プラチナ契約のケースクローズを 3 番目に配置します。

2 つの条件ノードでは、同じ項目、[目標解決日] が更新されます。

  • エスカレーションキーワードでは、この項目が本日に更新される。
  • 新規ケースでは、この項目が、本日から 1 か月か 2 週間、または本日に更新される。

エスカレーションキーワードのアクションが優先されるべきなので、その条件ノードを 2 番目に配置します。新規ケースでは次の条件が評価されるため、エスカレーションキーワードは常に評価されます。

最上位プロセスの順序と最終動作は次のようになります。

プロセス「ケース管理」
順序 条件ノード 最終動作
1 新規ケース 次の条件を評価
2 エスカレーションキーワード 次の条件を評価
3 プラチナ契約のケースクローズ 停止

それでは、呼び出し可能なプロセスに、同じことを行いましょう。

呼び出し可能なプロセスの順序

確認になりますが、最上位プロセスには 3 つの条件ノードが含まれています。

条件名 アクション
即時 スケジュール スケジュール済み
主要取引先 Chatter に投稿: 主要取引先のケースについて AE とマネージャに通知

(レコードに投稿。元のメールアラートのメールテンプレートをメッセージに使用。取引先所有者および取引先所有者のマネージャをメンション)。

N/A N/A
ベーシックサポート レコードを更新: [目標解決日] を TODAY() + 30 に設定 N/A N/A
プレミアムサポート クイックアクション: [目標解決日] を TODAY() に設定 N/A N/A
標準サポート レコードを更新: [目標解決日] を TODAY() + 14 に設定 N/A N/A

3 つの条件ノードでは、同じ項目 (サポートプラン) が評価されて、同じ項目 (目標解決日) が更新されます。いずれかが実行されたら、その他を評価する必要はないため、それぞれの最終動作は [停止] にします。サポートプランの 3 つの条件ノードでは、順序はまったく問題ではありませんが、サポートプランの価値に従って順序を設定しましょう。ベーシックが 1 番、標準が 2 番、プレミアムが 3 番になります。

ただし、その他の条件ノード (主要取引先) が評価されるようにする必要があります。ケースに主要取引先が含まれる場合、プロセスでは、サポートプランに従って目標解決日を判断する必要があります。このため、主要取引先の最終動作は、[次の条件を評価] にする必要があります。これを呼び出し可能なプロセスの先頭に配置して、常に評価されるようにします。

呼び出し可能なプロセスの順序と最終動作は次のようになります。

呼び出し可能なプロセス「新規ケース」
順序 条件ノード 最終動作
1 主要取引先 次の条件を評価
2 ベーシックサポート 停止
3 標準サポート 停止
4 プレミアムサポート 停止

順序の計画の完了

これで完了です。これまでに、オブジェクトノード、条件ノード、アクション、条件ノードごとの順序と最終動作という、新しいプロセスのすべての部分を計画してきました。前の単元では、オブジェクトノード、条件ノード、アクションのプランを実装しました。残っているのは、条件ノードを並び替えて、最終動作を設定することだけです。

プロセスの最終的な順序の実装

条件ノードの順序を計画したので、プロセスを更新しましょう。この部分は前の単元で行った作業の上に構築するため、前の単元を先に終了することをお勧めします。

プランには、すべての条件ノード、最終的な順序、最終動作がリストされています。

最上位プロセスの順序

まず、最上位プロセスを開き、既存の順序を最終的な順序と比較しましょう。現在、条件ノードは次の順序になっています。

  1. プラチナ契約のケースクローズ
  2. エスカレーションキーワード
  3. 新規ケース

この順序を最終的な順序と比較します。

プロセス「ケース管理」
順序 条件ノード 最終動作
1 新規ケース 次の条件を評価
2 エスカレーションキーワード 次の条件を評価
3 プラチナ契約のケースクローズ 停止

プランでは、条件ノードが逆順で評価されます。幸いなことに、条件ノードの並び替えは非常に簡単です。

条件ノードの並び替え

  1. 新規ケースの上にマウスポインタを置きます。青枠が条件グループを囲んで表示され、右上に 条件をドラッグできることを示すアイコン アイコンが表示されます。このアイコンは、条件グループをドラッグできることを表しています。
  2. 青枠内をクリックし、新規ケースの条件グループを上にドラッグします。緑色の線は、条件グループが配置される場所を示します。
  3. 緑色の線がオブジェクトノードとプラチナ契約のケースクローズの間に表示されたら、条件グループをドロップします。
プロセスビルダーのドラッグアンドドロップ機能による条件の並び替え

同じ手順を繰り返して、新規ケースを 1 番、エスカレーションキーワードを 2 番、プラチナ契約のケースクローズを 3 番にします。言い換えると、条件ノードの順序を変更して、プロセスでの順序をプランに合わせます。

最終動作の設定

条件ノードを最終的な順序にしたので、最終動作を設定します。デフォルトの動作は [停止] なので、プラチナ契約のケースクローズの最終動作を設定する必要はありません。

その他 2 つの条件ノードでは、次のように操作します。

  1. [停止] をクリックします。
  2. [次の条件を評価] を選択します。
  3. 最終動作を保存します。

これで、最上位プロセスが完了しました。すべての条件ノードは最終的な順序になり、最初の 2 つの条件ノードでアクションが実行されると、プロセスで次の条件が評価されます。

呼び出し可能なプロセスの順序

次は呼び出し可能なプロセスです。新規ケースの呼び出し可能なプロセスを開くと、条件ノードの現在の順序は次のようになっています。

  • 主要取引先
  • ベーシックサポート
  • プレミアムサポート
  • 標準サポート

この順序を最終的な順序と比較します。

呼び出し可能なプロセス「新規ケース」
順序 条件ノード 最終動作
1 主要取引先 次の条件を評価
2 ベーシックサポート 停止
3 標準サポート 停止
4 プレミアムサポート 停止

順序はほぼ同じです。プレミアムサポートと標準サポートの順序を入れ替える必要しかありません。同じように、最終動作の設定も少ししか必要ありません。プランによると、主要取引先以外のすべての条件ノードでは、デフォルトの [停止] 動作を維持します。

ただし、まず、ボタンバーのプロセスの状況が [参照のみ] になっていることに注意してください。アクションの単元では、このプロセスを有効にして、ケース管理プロセスにアクションとしてこれを追加できるようにしました。このプロセスを変更するには、新しいバージョンをコピーします。後でこの新規バージョンを有効にして、ケース管理プロセスでは、最新で最適なバージョンを使用します。

  1. ボタンバーで、[コピー] をクリックします。
  2. デフォルトの選択を残し、新規バージョンを保存します。
  3. プロセスを編集できるようになったので、プレミアムサポートをドラッグして最終条件ノードにします。
  4. 主要取引先の最終動作を [次の条件を評価] に変更します。
  5. 最上位プロセスでこのバージョンの新規ケースプロセスを使用するため、[有効化] をクリックします。

仕上げ

本当に終わりが見えてきました。残りは多少のクリーンアップのみです。プロセスが正しく動作することを確認するときがきましたが、その前に、プロセスを有効にして、置き換えたワークフロールールを無効にします。

ヒント

ヒント

Sandbox 環境でプロセスを構築してテストしてください。本番データに影響を与えずに問題を特定できます。

置き換えたワークフロールールの無効化

ワークフロールールを無効にしてからプロセスをテストしないと、プロセスとワークフロールールが両方とも動作してしまいます。そうなった場合、各アクションが重複してしまいます。そうしたことがまず起こらないように、ワークフロールールが動作しないようにしましょう。

ヒント

ヒント

ワークフロールールは、削除せずに無効にしてください。完全にテストして、プロセスが期待どおりに動作するまでは削除しません。プロセスが正しく動作しないことがわかった場合に、ワークフロールールを最初から構築することを避けることができます。

  1. [設定] から、[クイック検索] ボックスに「ワークフロー」と入力し、[ワークフロールール] をクリックします。
  2. 置き換えた各ワークフロールールの横で、[無効化] をクリックします。
  3. ダイアログが表示されたら、[OK] をクリックします。

プロセスの有効化

最上位プロセスを有効にできるようになりました。

  1. [設定] から、[クイック検索] ボックスに「ビルダー」と入力し、[プロセスビルダー] をクリックしてケース管理プロセスを開きます。
  2. ボタンバーで、[有効化] をクリックします。
  3. [確認] をクリックします。

プロセスのテスト

最後にプロセスをテストします。順列のリストを立案して、結果に期待するものを特定してください。次に、レコードの作成や編集を試してプロセスをトリガし、結果を確認します。テストプランは長いほど良いです。

テストプランを立案するときは、次のことを考慮してください。
  • どのようなときにアクションが実行されることを期待するか
  • どのようなときに、アクションが実行されないことを期待するか (たとえば、レコードが絞り込み条件の一部を満たすが、すべてを満たすわけではないときなど)。
  • 変更が複数の条件ノードを満たす場合の結果。
  • 使用される数式に基づく順列。たとえば、プロセスの数式で LOWER() を使用して、すべてのテキストを小文字に変換しているとします。テストプランでは、「password」、「PASSWORD」、「Password」、「pAsSwOrD」というように、件名でキーワードの大文字と小文字がさまざまに混在している場合の結果を考慮します。
変更のタイプ 値セット 期待される結果
作成 完了 = True

優先度 = 高

契約種別 = プラチナ

待機中のインタビューに、インタビューが今から 7 日後にスケジュールされたことが表示される。
編集 件名に「緊急」が含まれる。 なし
作成 件名に「緊急」が含まれる。

サポートプランは設定されていない。

優先度 = 影響するサービス

サポートレベル = Tier 3

目標解決日: 今日の日付

作成 契約種別 = ベーシック

件名 = 「パスワードの紛失」

優先度 = 影響するサービス

サポートレベル = Tier 3

目標解決日: 今日の日付

編集 完了 = true

優先度 = 低

件名にエスカレーションキーワードが含まれていない。

説明にエスカレーションキーワードが含まれていない。

なし
作成 主要取引先 = true Chatter 投稿がケースレコードで作成され、取引先所有者とそのマネージャがメンションされる。
作成 主要取引先 = true

サポートプラン = 標準

目標解決日 = 今日から 2 週間後

Chatter 投稿がケースレコードで作成され、取引先所有者とそのマネージャがメンションされる。

本番組織への変更のリリース

これまでに、ワークフロールールを分析してプロセスで置き換える方法を計画し、その計画を別の環境で実装しました。テストも行って、プロセスが正しく動作することを確認しました。ここでは、このすべての変更を本番環境に移して、このプロジェクトを完了します。

先ほど、評価とアクションを重複させずにプロセスをテストするため、ワークフロールールを無効にしました。プロセスが動作することを確認したので、プロセスで置き換えたワークフロールールは削除しても問題ありません。使用されなくなっているワークフローアクションを削除することも検討してください。たとえば、項目自動更新ワークフローアクションが、その他のルールや承認プロセスで参照されていない場合は、それを削除します。