フォローする

2019.11.28 「Salesforce ビジネスプロセス自動化ツールを活用しよう(2) - 混在するワークフロールールをプロセスビルダーで整理してみましょう」

2019.11.22 「Salesforce ビジネスプロセス自動化ツールを活用しよう(1) - どのような自動化ツールがあるかを再確認してみましょう」

2019.12.6 「Salesforce ビジネスプロセス自動化ツールを活用しよう(3) - プロセスビルダーを活用して既存の承認プロセスも整理してみましょう」

 

お世話になっております。

ウフル カスタマーサポート Salesforce 担当の 後藤 でございます。

 

先週よりお送りしております「Salesforce ビジネスプロセスの自動化ツール」、今回はその第2回、 先週予告 いたしました通り、「 混在したワークフロールールをプロセスビルダーで置き換えて整理 するケーススタディ」についてお送りします。 今回の内容は、 特に「長い間継続して使ってきたお客様」 に恐らくお役に立つのではないかと考えております。

 

1.おさらい: ワークフロールールとプロセスビルダーの共通点および相違点

 

先週の内容のおさらいになりますが、 今回の解説を円滑に進めていくため、改めて「 ワークフロールールとプロセスビルダーの共通点と相違点」 を確認してみましょう。

 

【ワークフロールールとプロセスビルダーの共通点】
  • if/then ステートメントによる実行条件の規定
  • レコードの作成/編集からの [保存] のタイミングで呼び出される
  • 条件に合致した際に指定したアクションが呼び出される
  • アクション実行タイミングは即時以外にスケジュール設定が可能
【ワークフロールールとプロセスビルダーの相違点】
  • if/then ステートメントの複数設定の可否
    - ワークフロールールは単一のみ
    - プロセスビルダーは複数設定可
  • レコード [保存] 以外の開始方法の設定可否
    - ワークフロールールは [保存] 以外設定不可
    - プロセスビルダーは [保存] 以外に「別プロセスから呼び出す」ことが可能
  • サポートされるアクション「項目の更新」対象の相違
    - ワークフロールールでは「自レコード」及び「 主従関係の親レコード」のみ
    - プロセスビルダーでは「自レコード」とリレーションのある( 主従だけではなく参照関係も含め)任意のレコードを更新可能
  • サポートされるアクション「レコードの作成」対象の相違
    - ワークフロールールでは、ToDo のみ作成可能
    - プロセスビルダーでは、 オブジェクトのリレーション有無を問わず、 レコード作成が自由に可能
  • サポートされるアクション「Chatter への投稿」の可否
    - ワークフロールールでは Chatter 投稿は設定不可
    - プロセスビルダーでは「自レコード」「指定したユーザ」「 指定したグループ」に Chatter 投稿を設定可能
詳しくは下記ヘルプに機能一覧表がございますのでご参照ください 。

 

使用する自動化ツール

 

2.ケーススタディ: 肥大化したワークフロールールをプロセスビルダーに集約してスリム化する

 

カスタマーサポートでお客様のご対応をする中で、 定期的に寄せられるお問合せがございます。

 

「場当たり的にワークフロールールを設定してきて、 何を設定したか訳が分からなくなってしまったので、 なんとかして整理したい、いい方法はないですか?」

 

先述したように、ワークフロールールは「単一の if/then ステートメントのみサポートしている」ため、 条件によって違うアクションを割り当てる場合、 条件の数だけワークフロールールを設定する必要がありました。
そのため、例えば以下のワークフローについて;
  • 条件:商談のフェーズが [見積の作成] になった時に
  • アクション1:商談カスタム項目 [見積作成担当者] に特定のユーザを割り当て
  • アクション2:見積作成担当者にメールを送信する
商談作成者の部署ごとに見積作成担当者を分岐させている場合は、 部署の数だけワークフロールールを設定する必要があります。 しかも部署は往々にして年1回( 多いところでは半期ごとや四半期ごとに) 構成変更が行われるので、その度にルールが増えていくわけです。

 

<ルール1>
  • 条件1:商談所有者のロールが「東京営業部」で
  • 条件2:商談のフェーズが [見積の作成] になった時に
  • アクション1:商談カスタム項目 [見積作成担当者] に東京営業部長を割り当て
  • アクション2:東京営業部長にメールアラートを送信する
<ルール2>
  • 条件1:商談所有者のロールが「大阪営業部」で
  • 条件2:商談のフェーズが [見積の作成] になった時に
  • アクション1:商談カスタム項目 [見積作成担当者] に大阪営業部長を割り当て
  • アクション2:大阪営業部長にメールアラートを送信する
<ルール3>
  • 条件1:商談所有者のロールが「新規事業開拓室」で
  • 条件2:商談のフェーズが [見積の作成] になった時に
  • アクション1:商談カスタム項目 [見積作成担当者] に新規事業開拓室長を割り当て
  • アクション2:新規事業開拓室長にメールアラートを送信する
<ルール4>

 

・・・以下省略!!

 

まさに「場当たり的」にならざるを得ない「罠」です。
しかもこのような場合、 廃止になった部署のルールも削除されずに残ったままになりがちで 、年次を重ねるごとに益々「手を付けるのが本当に億劫」 になっていくのが、まさしく「Salesforce あるある」な訳です。

 

・・・しかし!

 

プロセスビルダーを使用すれば、 これを一つの設定にまとめることが可能になります!

 

プロセスビルダーの、ワークフロールールに対する相違点、「 複数の if/then ステートメントをサポートする」という長所を生かすことで、 開始条件が違う同一オブジェクト対象の複数のアクションを、 単一のプロセスで賄うことができます。

 

以下は「商談所有者ロールによって、 見積作成者の依頼先を分岐するプロセス」 の設定画面イメージです。

 

 

 

フローチャートの左上から順に参照していくと、「商談」 ブロックがあります。
ここでは「商談を作成したときのみか、作成/編集のときか」 を選択します。
今回の例の場合は「レコードを作成または編集したとき」 を選択します。

 

引き続いて第一の条件に進みます。
今回は「東京事業部」という条件名を付けておきます。
  • 条件1:商談所有者のロールが「東京営業部」で
  • 条件2:商談のフェーズが [見積の作成] になった時

 

ワークフロールールで同様の設定を行っている方は既にご存知かと 思われますが、「 条件に合致するように編集が行われたときだけ実行される」 設定を行うことが重要になります。(そうしないと、フェーズが「 見積の作成」に留まっている限りは、 編集して保存するたびに毎回メールアラートが送られてしまいます 。)

 

プロセスビルダーの場合は「詳細」を開き「 レコードに指定の変更が行われた場合にのみアクションを実行しま すか?」にチェックを入れます。

 

 

第一条件「東京事業部」に合致した場合、 商談に追加したユーザ参照項目「見積作成担当者」 に東京事業部長が指定されるアクションが実行されます。
設定でユーザを指定するには、ユーザ名ではなく ID を使用します。
ユーザ ID は、ユーザの詳細を開いた際の URL から確認します。

 

(例)
https://ap15.lightning.force.com/lightning/r/User/ 0050o00000XnRFT /view
https://ap15.lightning.force.com/lightning/setup/ManageUsers/page?address=%2F 0050o00000XnRFT %3Fnoredirect%3D1%26isUserEntityOverride%3D1

 

 
見積作成担当者に東京事業部長が指定されるアクションの実行から 1時間後に、見積作成担当者のメールアドレスに「 見積作成が割り当てられました」 通知が送信されるようスケジュールされます。

 

※ 見積作成担当者が割り当てられてからのメールアラートのため、 メール送信時に確実に宛先が指定されているよう、 保険として時間差を設定しました。

 

従来のワークフロールールならこれで完結ですが、複数の if/then ステートメントが設定可能なプロセスビルダーなので、 引き続いて、東京事業部ではない、では大阪事業部かどうかの「 第二条件」を設定し、 同様に実行アクションを設定することができます。
  • 条件1:商談所有者のロールが「大阪営業部」で
  • 条件2:商談のフェーズが [見積の作成] になった時
  • アクション1:商談カスタム項目 [見積作成担当者] に大阪営業部長を割り当て
  • アクション2:1時間後、 見積作成担当者にメールアラートを送信する

 

同様に「第三条件」に「新規事業開拓室」の場合を設定し、 実行アクションを設定します。

 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 

プロセスビルダーで複数条件を集約することのメリットは、 プロセスの初期設定以上に、条件が追加/ 変更された際のメンテナンスにおいて真価を発揮します。
今回の例でも、新規部署が追加された場合や、 部署名が変更された場合、 今までは複数のワークフロールールを一つ一つ参照しておく必要が ありましたが、プロセスビルダーでは、 プロセス設定を開いてフローチャートを参照し、 足りないものは補う、余計なものは削除する、 名前の変更が必要なものは既存の設定を開いて条件を修正する・・ ・だけで完了です。

 

今後のメンテナンスコスト削減のため、 ワークフロールールからプロセスビルダーへの移行を、 是非ご検討いただければと存じます。

 

(プロセスビルダーに移行するなら、せっかく Chatter 自動投稿が使用できるようになったので、 メールアラートではなく、Chatter で見積作成の依頼をする方がよりスマートかもしれないですね!)

 

お時間ございましたら、以下の Trailhead モジュールにもぜひ挑戦してみてください。
 
ワークフロールールの移行

 

===========================================================

 

ビジネスプロセスの自動化ツールに関するシリーズの二回目、 いかがでしたでしょうか。
次回は「承認プロセスのおさらい~ 既存承認申請をプロセスビルダーに組み込んで集約管理する」 ケーススタディをお送りする予定です。
お待ちかねの「Lightning フローを使って高度な自動化を実装する」 は翌々週のお題となりますので、 恐れ入りますが今しばらくお待ちくださいませ。

 

今後ともウフル カスタマーサポートを引き続きご愛顧いただきますよう、 何卒よろしくお願い申し上げます。

 


Salesforce・Googleの運用・サポートでお困りなら

 カスタマーサポートへお問合せください。


コメント

 
 
この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています