2019.11.22 「Salesforce ビジネスプロセス自動化ツールを活用しよう（１） - どのような自動化ツールがあるかを再確認してみましょう」
≪ 2019.11.15 「Salesforce - Winter '20 新機能をチェック（４）：Lightning フローの大幅強化～スケジュールへの対応」
2019.11.28 「Salesforce ビジネスプロセス自動化ツールを活用しよう（２） - 混在するワークフロールールをプロセスビルダーで整理してみましょう」 ≫
お世話になっております。
ウフル カスタマーサポート Salesforce 担当の 後藤 でございます。
先週まで Winter '20 の新機能についてご案内させていただきましたが、最終週の「フローの機能強化：スケジュール実行に対応」を解説した際に、「 そういえばフローって敷居が高くて、今まで触れてこなかった」 という声が社内外から寄せられたため、今週から３～ ４回に分けて、フローを含めた「Salesforce ビジネスプロセス自動化ツール」 全体を集中的にご案内させていただきます。
本ニュースメールをご覧いただいたお客様が、年内に「フローを使って関連レコードの一括更新を行えるようになる」 くらいのレベルを目指したいと思います。
１．Salesforce における「ビジネスプロセスの自動化」とは
Salesforce において、取引先を登録する、商談のフェーズを更新する、 Chatter で同僚にコメントをする、といった作業は、いずれも「 手動の作業」になります。
それだけでも組織は機能しないわけではないですが、 手動の作業に伴う他のプロセス、例えば「取引先を登録したら、 デフォルトの商談を一つ登録する」「 商談のフェーズを更新したらマネージャに Chatter で通知をする」といった作業を、連動して自動で行えたら、 業務が格段に楽になり、かつ組織の管理者やマネージャも、 付随作業の漏れがないかのチェックをせずに済むようになります。
それらの「ビジネスプロセスの自動化」を実現するツールが、 Salesforce には用意されています。
関連ヘルプ：
「ビジネスプロセスの自動化」
２．ビジネスプロセスの自動化を支援するツール
ビジネスプロセスの自動化を支援するツールは、 以下の２カテゴリに区分されます。
- コードを記述することなく、宣言型カスタマイズ（＝ 画面上のクリックおよび設定名の記述だけでオペレーションを行う 形式）で設定が完了するもの
- 設定を行うためにプログラミングコードの記述が必要になるもの
後者は「Apex トリガ」と呼ばれるもので、Salesforce のごく初期から提供されていたプログラミング言語（Apex）を用いてコードを記述することで、 ありとあらゆる自動化設定を可能とします。
本ニュースメールは、 プログラミングを行わない一般的なビジネスユーザの皆様を対象と しているため、本記事では Apex トリガについての詳細説明を割愛させていただきます。
前者の「コードを書かずにクリック＆ タイプだけで設定できるツール」は、 最初はシンプルなものだけが提供されており、対象としない領域は Apex トリガでカバーする必要があったのですが、 年三回定期的に提供されているリリースバージョンを追うごとに、 次々と新しいツールが提供され、従来 Apex トリガを使わないと実現できないことが徐々に可能になってきまし た。
本記事ではこちらのカテゴリを取り上げてまいります。
宣言型のビジネスプロセス自動化ツールには以下のものがあります 。
リリースされた順にリストアップします。
- ワークフロールール
- 承認プロセス
- プロセスビルダー
- Lightning フロー
ワークフロールールと承認プロセスは、Apex トリガと同様、Salesforce のごく初期のバージョンから存在していました。
そのため、「ワークフロールールで実装できるか、Apex トリガでコードを書く必要があるか」の二者択一が、長い間の Salesforce 管理者/開発者の「常識」で、そのことが「 ワークフロールールには詳しいんだけど、そのあと出てきたツールにはどうも疎くて」 というユーザを数多く生む要因になってきました。
ワークフロー
ワークフロールールは最もシンプルな自動化ツールです。
「if/then ステートメント」、つまり上記ヘルプでも触れられている
「雨が降ったら（= if：条件）、傘を持っていく（= then：アクション）」
から構成されています。
条件が発動するのは「レコードを作成、もしくは更新した」 タイミングのみです。 画面上にボタンを配置したらアクションが動く、 という設定はできません。
ワークフロールールのバリエーションで、「ボタンを押したらアクションが動く」を実現するのが承認プロセスです。
承認
承認プロセスでは、画面上に「承認申請」ボタンを配置し、押したタイミングで指定したユーザに「承認か却下を選択してください」という通知を送信し、 承認をした時点で指定したアクションが動作するというものです。
（残念ながら自由にボタンを作成できるわけではありません、実現できるのはまだ先の話です・・・）
承認ユーザは、一般的にはユーザ設定で「マネージャ」 として指定したユーザを自動で割り当てますが、 特定のユーザを指名して割り当てることも可能です。
ワークフロールール/承認プロセス共に、 設定可能なアクションは以下のものに限定されます。
- 当該レコード（及び主従関係の親レコード）の他の項目値を自動更新する
- 設定済みのメールアラートを実行する
- 当該レコードに関連した ToDo を作成する
- 外部基幹システムにメッセージを送信する（※）
つまり、以下のことはワークフロールールでは実現できません。
- Chatter の自動投稿
- 関連レコードの自動作成
- 参照関係レコード（子レコード含む）の更新
併せて、最初に述べた「if/then ステートメント」も「単一の条件」に限定されるため、例えば
「弱い雨が降った場合（= if_1）は傘を持っていく（= then_1）」
「強い雨が降った場合（= if_2）は合羽を着ていく（= then_2）」
「非常に強い雨が降った場合（= if_3）は会社に休みの連絡をする（= then_3）」
といった、 条件の分岐によって違うアクションを割り当てることができません 。
（承認プロセスの場合も、開始時の条件は単一のものとなるため、 開始条件を分岐させるには分岐の数だけ設定を行う必要があります 。）
そのため、「ワークフローでできないことは全部 Apex トリガで処理する」のが、古参 Salesforce ユーザの共通認識となっていました。
これら「ワークフロールールのウィークポイントを解消」 するべく、新たに登場した自動化ツールが、プロセスビルダーです 。
Lightning プロセスビルダー
プロセスビルダーでは、ワークフロールールで実現可能なことの「殆ど」（※）を実現し、 かつ実現不可能だった上記のアクションも可能とします。
そのため、 ワークフロールールのヘルプにはこのような記載があります。
===========================================================
ヒント
可能な場合は、ワークフロールールの代わりにプロセスビルダーで if/then ステートメントを自動化します。
===========================================================
そうです、今後はビジネスプロセスの自動化を行うには、 ワークフローではなくプロセスビルダーを使用することが、 Salesforce 公式の推奨ソリューションとして明言されていますので、 今からプロセス自動化の学習を行うユーザは、 ワークフロールールの習得に掛ける分の時間を、 そのままプロセスビルダーの習得にあてた方が効率的であると言え ます。
（※）
ワークフローで可能なアクションのうち、 唯一プロセスビルダーでサポートされていないのが、「外部基幹システムにメッセージを送信する」アクション（ 正式名称は「アウトバウンドメッセージ」）です。
但しこれはあくまでも「コードを書かずに外部連携の設定をすることができない」だけで、 プロセスビルダーでは「Apex を呼び出す」ことが可能なので、予め「Apex コールアウト」の設定を行い、 プロセスビルダーでアクションとして設定すれば、同様のことを「より安定した動作で」行うことができます。
参考
「Apex を使用したコールアウトの呼び出し」
さて、ワークフロールールの説明で「レコードの作成または更新でしか呼び出せない」と述べましたが、 実はプロセスビルダーについてもこの点はほぼ共通です。
（プロセスビルダーでは「プラットフォームイベントから呼び出せる」 という違いがありますが、Apex 開発が絡む範疇なので詳しくは割愛します）
「ボタンを押したら自動化処理が行われる」 という実に魅力的なユーザ体験は、 まだまだプロセスビルダーの守備領域とはならず、Apex トリガ（と Visualforce ページの組み合わせ）に頼らざるを得ませんでした。
その「Apex コーディングの聖域」を「プログラミングを行わない管理者」 に開放したのが、自動化ツールの真打、Lightning フローです。
フロー
フローは、「情報を収集して、アクションを実行する」 ビジネスプロセスです。
ワークフロールールやプロセスビルダーなど「レコードの作成および更新時に自動起動する」場合、 収集する情報は当該レコードに直接関係するものに限定されますが 、 フローでは情報の収集方法を設定の中に直接記載することができる ため、 レコードの枠に縛られない自由な自動化設定が可能になります。
呼び出し方法も「画面操作」と「自動起動」の二通りが可能で、「画面操作」を選択すれば、 画面上に設定したカスタムボタンを押すことでフローを呼び出す、 あの「憧れの」操作が、 コード記述をすることなく実現可能になります。
一方、「自動起動」については、 フロー自体には起動のオプションは無いため、あくまでも「外部アクションからフローを呼び出す」必要がありますが、 ご心配無用です、先述のプロセスビルダーにて、 アクションの一覧に「フローを呼び出す」があるため、 プロセスビルダーで「条件に合致した際、どのフローに、 どの情報を送り込むか」 のアクション設定を過不足なく行うことができます。
フローを使うとこんなことができます。
- 商談に紐づいている商品を一括で削除するボタンを商談レイアウト に配置する
- 完了日から６ヶ月を経過した完了済み ToDo を一括削除するボタンをホーム画面に配置する
- 取引先に設定したカスタムステータス項目を特定の値に更新したら 、関連する商談を一括で成立に設定する
そうそう、一つ重要なことを言い忘れていました。
フローでは「レコードの削除」がサポートされています。
Apex トリガのコードを書かずに削除アクションを実装するにはフローが 唯一のソリューションになります。
まさに往年のアニメで悪役軍団が最後に押す、あの "どくろマークの「自爆ボタン」" の Salesforce バージョン、「押した瞬間に組織の全レコードをきれいに消し去る」 悪魔のボタン、作りようによってはこれが作れてしまうのです。 取り扱いはくれぐれも慎重に・・・。（社長から「おしおき」 を受けても知りませんよ！）
===========================================================
ビジネスプロセスの自動化ツールに関するシリーズの一回目、 いかがでしたでしょうか。
興味を持たれた方は、文中に記載したヘルプ、および Trailhead の関連モジュールをご参照いただければ、 次回以降の記事がより楽しめるはずかと存じます。
次回は、基礎実践編として「既存のワークフロールールをプロセスビルダーで置き換える」 ケーススタディをお送りする予定でございます。
今後ともウフル カスタマーサポートを引き続きご愛顧いただきますよう、 何卒よろしくお願い申し上げます。
Salesforce･Googleの運用･サポートでお困りなら
カスタマーサポートへお問合せください。
コメント