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

ワークフローからプロセスビルダーへの移行

Lightning Experience のコンテンツであることを示す稲妻のアイコン

Trailblazer の皆さん!

Salesforce には Lightning Experience と Salesforce Classic の 2 種類のデスクトップユーザインターフェースがあります。このモジュールは Lightning Experience 向けです。

インターフェース間の切り替え、Lightning Experience の有効化などについての詳細は、Trailhead の「Lightning Experience の基本」モジュールを参照してください。

学習の目的

この単元を完了すると、次のことができるようになります。
  • プロセスビルダーのビジネス価値をワークフローと比較して説明する。
  • ワークフロールールをプロセスに変換する工程全体を説明する。

新しい会社、新しい組織

あなたが Acme Wireless 社に入社して数か月がたちました。新しい組織内で働くことに慣れてきて、改善の余地がある領域が気になり始めました。こうしたものの一部は、手早く修正するだけで改善できます。

改善に時間がかかりそうなものは、ソリューションの実装に関してです。ソリューションが問題のベストプラクティスに必ずしもなっていないにも関わらず、修正する火急の必要性がないためにそのままになっています。最新機能について行くのは難しく (リリースノートは毎年 1,200 ページにのぼります)、ましてその機能を実際に実装するのは困難です。常に時間に余裕があるわけではありません。時間があったとしても、実装に値するだけのメリットがありません。

すべてを自動化するために使用されているのは、プロセスビルダーではなく、多くのワークフロールールですが、これも改善の余地があります。

重要

重要

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

ワークフローとプロセスビルダーの比較

何か大きな問題でもあるのでしょうか。よく知っているツールから知らないツールに自動化を変換するために、なぜ時間を費やさなければならないのでしょうか。

プロセスビルダーでは、さらに多くことを自動化できます。
プロセスビルダーには、対応するワークフローアクションに比べ、より柔軟なアクションが含まれています。たとえば、[レコードを作成] プロセスアクションでは、ToDo だけではなく、どのようなレコードでも作成できます。[レコードを更新] プロセスアクション (項目自動更新ワークフローアクションに対応) では、どのような関連レコードでも更新できますが、項目自動更新ワークフローアクションでは、そのレコードまたはその親しか更新できません。
プロセスビルダーには、[Chatter に投稿] や [承認申請] など、まったく新しいアクションも組み込まれていますが、ワークフローではこれを使用できません。
プロセスビルダーでは、条件の順序を制御できます。
ワークフローでは、ワークフロールールの実行順序を決められません。あるルールが実行したことが、別のルールによって上書きされる危険性が常にあります。プロセスビルダーでは、プロセスの条件の正しい評価順序を指定します。その結果、特定のプロセス条件内では、アクションの順序が決まります。
ヒント

ヒント

ワークフローでは、どのワークフロールールを先に評価するかは選択できないため、1 つのツールを選択して、特定のオブジェクトのすべてを自動化します。ワークフローとプロセスビルダーを両方とも使用する場合は、レコード変更の結果を確実には予測できません。

プロセスビルダーでは、すべての関連レコードの項目にアクセスできます。
ワークフローでは、レコードの親の項目を参照できます。プロセスビルダーでは、どのような関連レコードの項目にでも、そのレコードがどれほど離れているかに関係なくアクセスできます。親レコードでも、親の親レコードでも、2 世代を飛び越えて親の親の親の親の親レコードでも、項目を参照できます。
プロセスビルダーには未来があります。
ワークフローは拡張されません。ワークフロールールの使用はサポートされ、今後もサポートされ続けます。しかし、ワークフローの使用事例の新機能はすべて、プロセスビルダーで実現します。光り輝く新機能を使用することをお望みの場合は、自動化をプロセスビルダーに移行してください。

これで、今後のプロジェクトにワークフローとプロセスビルダーのどちらを使用するかを判断するのに必要な情報がすべて揃いました。

新規ビジネス要件

人生でも、Salesforce システム管理者としての仕事でも、変更は常にあります。次のようなメールをカスタマーサービス統括責任者から受け取っても、それほど驚くことはないでしょう。

数か月前、会社が (あるいは前任者によって) Chatter がロールアウトされました。Chatter を利用する人が増えるのを見て、私は担当役員として嬉しく思っていますが、利用率の目標基準を達成するにあたり、いくつか方法を見つけました。私のチームは、利用率をさらに上げるために有効な方法を特定しています。そこで、簡単なお願いがあるのです。
サポートチームは、Salesforce からケースに関するメールを自動的にたくさん受信します。実装を変更して、サポートチームが、メールの代わりに Chatter によって通知を受けることはできるでしょうか。

最初は思わず笑ってしまいました。簡単なお願いなどというものはないのです。

とは言っても、組織のケース管理システムを変更するため、最適な方法を調べるべき時は今でしょう。管理ツールキットの 3 つの項目、Apex トリガ、フロービルダー、プロセスビルダーにより、Chatter 投稿を自動的に作成できます。そのツールの中で、プロセスビルダーが最も単純です。そこで、メールを送信する、ケースベースのワークフロールールをプロセスビルダーによるプロセスに移行する計画を立てました。

少し時間を取って、既存のケースワークフロールールを確認してみましょう。

ルール名 条件 アクション
件名または説明のキーワードに基づいてエスカレーション 評価条件: 作成されたとき、またはその後の基準を満たすように編集されたとき
ルール条件:
Contains(LOWER( Subject ),"urgent") ||
Contains(LOWER( Subject ),"password") ||
Contains(LOWER( Subject ),"down") ||
Contains(LOWER( Subject ),"emergency") ||
Contains(LOWER( Subject ),"internal server error") ||
Contains(LOWER( Description ),"urgent") ||
Contains(LOWER( Description ),"password") ||
Contains(LOWER( Description ),"down") ||
Contains(LOWER( Description ),"emergency") ||
Contains(LOWER( Description ),"internal server error")                                                  
即時:
  • 項目自動更新: [優先度] を [影響するサービス] に設定
  • 項目自動更新: [サポートレベル] を [Tier 3] に設定
  • 項目自動更新: [目標解決日] を [TODAY()] に設定

時間ベース: N/A

プラチナ契約のケースクローズ時のフォローアップ 評価条件: 作成されたとき、またはその後の基準を満たすように編集されたとき
ルール条件:
  • (ケース: 優先度 次の文字列と一致する 高) および
  • (ケース: クローズ 次の文字列と一致する True) および
  • (ケース: 契約種別 次の文字列と一致する プラチナ)
即時: N/A
7 日後 ケース: クローズ日時:
  • メールアラート: フィードバック要求をケースの取引先責任者にメールで送信
営業統括責任者への重要取引先のケースに関する通知 評価条件: 作成されたとき

ルール条件: (取引先: 主要取引先 次の文字列と一致する true)

即時:
  • メールアラート: 主要取引先のケースについて AE に通知
  • メールアラート: 主要取引先のケースについて AE のマネージャに通知

時間ベース: N/A

ベーシックサポートの解決日の設定 評価条件: 作成されたとき

ルール条件: (ケース: サポートプラン 次の文字列と一致する ベーシック)

即時:
  • 項目自動更新: [目標解決日] を TODAY() + 30 に設定

時間ベース: N/A

プレミアムサポートの解決日の設定 評価条件: 作成されたとき

ルール条件: (ケース: サポートプラン 次の文字列と一致する プレミアム)

即時:
  • 項目自動更新: [目標解決日] を TODAY() に設定

時間ベース: N/A

標準サポートの解決日の設定 評価条件: 作成されたとき

ルール条件: (ケース: サポートプラン 次の文字列と一致する 標準)

即時:
  • 項目自動更新: [目標解決日] を TODAY() + 14 に設定

時間ベース: N/A

5 個のワークフロールールのうち、メールアラートアクションが含まれるのは 2 個のみです。ただし、ベストプラクティスでは、プロセス (プロセスビルダーのもの) を特定のオブジェクトのワークフロールールと混在させることを避けます。このようにしないと、プロセスとワークフロールールの評価順序は保証されません。1 つのケースワークフロールールをプロセスで置き換える場合は、すべてのケースワークフロールールをプロセスビルダーに移行することをお勧めします。

プロセスへのワークフロールールの変換

新機能にかかるコストは、その機能に自動移行オプションがないと高くなります。ボタンをクリックするだけで、ワークフロールールをプロセスビルダーに変換するという考えは、非常に素晴らしいものだということは承知しています。残念なことに、ワークフロールールはプロセスとは大きく異なるため、自動移行は不可能です。そこで、次善の策として、移行プロセスについて説明するモジュールを用意しました。

少し抽象的ですが、ワークフローから別れてプロセスビルダーに移行するプロセスは次のようになります。このステップのそれぞれについては、このモジュール全体で説明します。

ヒント

ヒント

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

  1. ルールの条件をプロセスの条件に対応付けます。呼び出し可能なプロセスで条件をネストするかどうかを検討します。
  2. ルールのアクションをプロセスアクションに対応付けます。
  3. 条件ノードの最適な順序を判断します。

各ステップについては、そのステップ中に検討すべきことの説明、そのステップの計画の策定、プロセスビルダーでのその計画の実装という、3 つの部分に分けて説明します。このモジュールでは、計画を記すために表を使用します。ただし、どのような計画ツールでも使用できます。ペンと紙でも、ホワイトボードでも、スプレッドシートでも問題ありません。

retargeting