≪  2020.09.04 「Salesforce - Summer '20 新機能をチェック（３）：Service Cloud 編 （+ Winter '21 Sandbox プレビューの案内）」

2020.10.15 「Salesforce - 気になる機能を使ってみた：vol.1 - Salesforce Shield の Event Monitoring」 ≫

 

お世話になっております。
ウフル カスタマーサポート Salesforce 担当の 後藤 でございます。

 

皆様いかがお過ごしでしょうか。

お送りしております Summer '20 新機能特集も、今回で最終回になりました。
今回は Community Cloud と、開発者向け機能の中からノンコーディングの部分を抜粋してご紹介いたします。

 

リリースノートはこちらからダウンロードいただけますので、併せてご参照いただければと存じます。
https://resources.docs.salesforce.com/226/latest/ja-jp/sfdc/pdf/salesforce_summer20_release_notes.pdf

 

 

 

＊ Community Cloud 新機能

 

 

今回は以下の２機能をピックアップいたします。

 

• Lightning コミュニティでの「標準アクションの上書き」
• Salesforce CMS の機能改善

 

まずは、Lightning コミュニティでの「標準アクションの上書き」についてです。

 

そもそも、「標準アクションの上書き」とはどのような機能でしょうか。
前提としてそこから話を始めたいと思います。

 

標準アクションの上書き
https://help.salesforce.com/articleView?id=standard_actions_overrides.htm&type=5

 

=================================================
削除、編集、リスト、新規、タブ、表示などの標準アクションについては、アクション上書きと呼ばれる、アクションのカスタムユーザインターフェースを提供できます。Salesforce 標準ページで提供されるユーザ環境よりもさらにカスタマイズされたユーザ環境がビジネスモデルで必要とされる場合、アクション上書きを使用します。
=================================================

 

例えば標準の「削除」ボタンを押したとき、レコードの所有権を持つユーザならば、特に警告も表示されることなく削除が実行され、オブジェクトのホーム画面やリストビュー画面にリダイレクトされます。
ここに「削除しますか？ [はい] [キャンセル]」などの確認画面を出したい、というニーズは決して少なくないと思われます。

 

予め削除前確認用のカスタム画面を Visualforce や Lightning Web コンポーネントで作成しておき、 アクション上書きの機能を使用して「削除」アクションに対してカスタム画面を割り当てることで、「削除」ボタンを押した際にカスタム画面に遷移させることが可能になります。

実際の削除は、カスタム画面の「はい」ボタンを押した後に Apex クラスを呼び出すことで実行されますので、Apex クラス側に条件分岐を設けて、条件に合致しないレコードは「削除できません」とブロックさせることも可能です。

 

この設定は、設定の「オブジェクトマネージャ」にて、「ボタン、リンク、およびアクション」リストより、「編集」や「削除」などの標準ボタンの右側の [▼] をクリックして「編集」メニューを開き、「プロパティの上書き」で設定します。

 

 

 

この「標準アクションの上書き」機能、今までは Sales / Service Cloud や Platform 側、つまり「組織内部」のみが対象となっており、コミュニティには反映されませんでしたが、今回のリリースにて、各コミュニティの管理メニューの詳細に「Lightning コンポーネントでの標準アクションの上書き」を有効にすることで、コミュニティユーザのアクションにも反映させることができるようになりました。

 

 

 

 

標準アクションの置き換えを行うには、Visualforce や Lightning コンポーネントで予め画面を作っておく必要があります。

もちろんコーディングを伴うため、（私もそうですが）コーディングに馴染みのない Salesforce 管理者には敷居が高いと思いますが、「よくあるタイプのインターフェース」ならば、Salesforce 公式開発者サイトにサンプルコードが公開されているので、こちらを活用するのが有効です。

 

Component Library
https://developer.salesforce.com/docs/component-library/overview/components

 

 

そのままソースをコピーペーストしたり、ソース内のオブジェクトや項目のシステム参照名を置き換えるだけで使用できるものも多いようです。

Trailhead ハンズオンも提供されています。
まだ日本語化はされていないですが、見る限り難しい表現もなさそうなので、関心ございましたら是非挑戦していただければと存じます。

 

Build an Aura Component to Override a Standard Action
https://trailhead.salesforce.com/ja/content/learn/projects/workshop-override-standard-action/override_1

 

これらのコンポーネントを自社組織向けに調整する過程を経て、開発者としてのスキルを習得する足掛かりにもなるのでは、と思います。（私もがんばってみます！）

 

 

次の新機能紹介は、Salesforce CMS の機能改善についてです。

 

 

従来の「コミュニティビルダー」が、Spring '20 にて「Salesforce CMS」に進化したことは、前回リリースの際の新機能紹介でもご案内させていただきました。

 

2020.03.19 「Salesforce - Spring '20 新機能をチェック（５ - 最終回）：開発者向け機能、コミュニティ、Pardot 連携」
https://csminfo.uhuru.jp/hc/ja/articles/900000374983

 

===================================================
Salesforce CMS のリリースには、Summer '17 で正式リリースされた「Commerce Cloud」（Eコマース管理システム）の機能拡張が大きく関わっています。
https://www.salesforce.com/jp/campaign/releases/summer-17/commerce-cloud/

Eコマースサイトを運用するうえで必要不可欠なサイト構築機能を拡張した結果、Sales Cloud や Service Cloud の一部をなすコミュニティ構築機能を飲み込む形で「Salesforce CMS というひとつのコンテンツ管理機能」に統合された、と解釈できます。

従来のコミュニティ機能は「CMS エクスペリエンス」という名称で Salesforce CMS の構成要素となっています。
それに関連して、コミュニティビルダーも「エクスペリエンスビルダー」と名称を変え、機能強化されています。
===================================================

 

「Salesforce あるある」として、新機能の実装から数リリースは、既存機能の改善が次々と提供されていく、というのがよくあるパターンです。

Summer '20 では、下記の二点が大きなトピックです。

 

• 画像やドキュメントなどのコンテンツを CMS ワークスペースで直接管理できるようになった
• 外部 CMS で使用されているコンテンツを一括インポートできるようになった

 

今までの Salesforce CMS では、画像やドキュメントなどのコンテンツは、「アセット」という別の場所で管理し、都度検索して使用する形をとっていました。
今回のリリースより、CMS ワークスペース上で直接扱うことができるようになり、コンテンツの参照のために、CMS ワークスペースとアセットライブラリの間を行き来する必要がなくなりました。  

（従来のアセットライブラリにアップロード済みのコンテンツについても、CMS ワークスペース上で参照が可能、とのことです）

 

 

 

画像およびドキュメントコンテンツタイプを使用した CMS コンテンツの一元管理
https://releasenotes.docs.salesforce.com/ja-jp/summer20/release-notes/rn_centralize_your_cms_content.htm

 

CMS ワークスペース上にコンテンツライブラリが移行したことにより、コンテンツの一括インポートにも対応するようになりました。
他の CMS サービスなどで使用しているコンテンツを単一の ZIP フォルダに格納し、ファイル一覧を JSON ファイルで定義することで、一度に 5000 アイテムまでを CMS ワークスペースに取り込むことができます。

 

 

Salesforce CMS ワークスペースへのコンテンツのインポート
https://releasenotes.docs.salesforce.com/ja-jp/summer20/release-notes/rn_cms_import_content.htm?edition=&impact=

 

 

 

＊ Lightning フローの機能改善

 

 

続いては、開発者向け新機能についてです。

Salesforce 管理者向けの記事ですので、原則としてノンコーディングの部分をお送りするため、必然的に「Lightning フローの機能改善」についてになります。

 

• 「レコード変更フロー」による、レコード保存をトリガとするフローの実装

 

Spring '20 では「保存前のフロートリガ」が追加されていました。
これにより、レコード保存プロセスを飛ばしてフローを実行することで「10倍速い保存の実行」が可能になっていました。

 

2020.03.19 「Salesforce - Spring '20 新機能をチェック（５ - 最終回）：開発者向け機能、コミュニティ、Pardot 連携」
https://csminfo.uhuru.jp/hc/ja/articles/900000374983

 

===================================================
フローで Apex トリガと全く同じことができるわけではなく、Apex トリガに対しフローではいくつかの制限があり、その一つが

フローは AfterInsert / AfterUpdate（レコード保存後の動作）固定で、BeforeInsert / BeforeUpdate（レコード保存前の動作）には対応していない

という点でした。

このことは、「一旦保存してから、項目値を置き換える動作を行うため、完了までの時間が長くなる」というウィークポイントとなっていました。

これを補う Spring '20 の機能強化として、「フロー内の保存前更新」が実装されました。
===================================================

 

今回 Summer '20 でも、Lightning フローの機能強化は行われています。
それも非常にエポックメイキングな。

 

新たに提供されたのが、「レコード保存（トリガ）フロー」です。

 

 

 

今までは、「フロー自体はトリガを持たず、外部 Apex トリガやプロセスビルダーから呼び出す」のが常識でした。
そのため、プロセスビルダーからレコードの項目値を引き渡してフロー側の変数で受信する、などの「少々面倒くさい」設定が必要となっており、しかもその動線が「開発に馴染みのない」管理者ユーザには敷居が高く、「何のためのノンコーディングなのか」悩ましいところではありました。

それが、フロー自体に「レコード保存トリガ」を持たせることで、外部プロセスビルダーの設定も不要となり、 評価対象となるレコードはおのずと「保存したレコード」に固定されることで、対象レコードを特定するための検索アクションも必要なくなるという利点があります。

 

要は、「プロセスビルダーとほぼ同じ感覚でレコード更新時のフローを設定できるようになった」、と言っても過言ではないでしょう。

 

ちなみに従来の「外部から呼び出すフロー」は、「自動起動フロー（トリガ無し）」と呼び名が少々変わっています。

 

試しに、フローを一つ作成してみました。
取引先責任者にカスタム選択リストで「ステータス」を追加し、ここが [有効] となっているコンタクトの数を、取引先のカスタム数値項目「有効コンタクト数」に積み上げる、という「よくある」ものです。
（※ 取引先 - 取引先責任者は主従関係ではないので「積み上げ集計」は使用できません。）

 

 

レコードトリガフローのプロパティは以下のようになっています。

ちなみに Spring '20 の「保存前実行フロー」についてもレコードトリガフローの対象となっており、外部から呼び出すことなくフロー自身での起動が可能になりました。
保存前実行フローではクロスオブジェクトリレーションに一切対応していないため、今回の「取引先責任者の保存によって取引先の値を自動更新する」要件には向いていません。

 

 

フローの開始により、対象となったレコードは、自動で [$Record] というグローバル変数に格納されます。

 

次は、保存した取引先責任者と同じ取引先に属する取引先責任者をすべて収集するステップです。
「レコードの取得」を使用して以下のように定義します。

 $Record グローバル変数が使用できるようになったことで、「取引先 ID / 次の文字列と一致する / 当該取引先責任者の企業名 ID」という条件が、非常に容易に設定できるようになりました。

 その下の「StatusContact__c / 次の文字列と一致する / Enabled」というのは、先述の「ステータス」が [有効] かどうかになります。 　 

 

 

 

カウントの対象となる取引先責任者を収集したら、件数をカウントするためのプロセスに移行します。
今までのフローと同様に「ループ」を使用します。

こちらも、コレクション変数として上記の「レコードの取得」をそのまま使用できますので、深く考えることなく設定できます。

  

 

 

件数をカウントするための「割り当て」を設定します。

ここでようやく、ユーザが定義する「変数」が登場しました。
{#varTotalActiveContact} という数値型の変数を作成し、ループが実行されるたび数値を１ずつ上げていきます。

 

 

 

有効コンタクト数を数え終わったらループ終了で、最後のステップ、取引先のカスタム数値項目「有効コンタクト数」に、上記のループで変数 {#varTotalActiveContact} に割り当てた件数を書き込む、という作業に進みます。

ここでも対象の取引先を「$Record の企業名 ID に一致する」ものとして実に簡単に指定できます。

 

 

以上です。

以前のフローに比べて、格段に容易に設定できるようになりました。
変数項目も殆どフローがおまかせで作成してくれるので、途中で混乱することも少なくなりました。

 

あ、大事なことを忘れてました。

「取引先責任者を削除したときに再計算を行う」際の挙動を定義する必要がありました。
いくらフローが自動でトリガしてくれるようになったとはいえ、それはレコードの作成/更新時に限定され、「レコードの削除で自動起動するトリガ」はまだ提供されていません。

 

もうひとつフローを作成します。
こちらは「画面フロー」を選択します。（先述の通り「レコードトリガフロー」を選べないため）

 

 

 

最初の「画面」は、「削除します、よろしいですか？」という確認のためのものです。「表示テキスト」コンポーネントを使用します。
この時点で「次へ」に進まなければ、指定した取引先責任者の削除はキャンセルされます。

 

 

 

「次へ」で進んだ先で、取引先責任者の削除を行います。
ここで重要なのが、「どの取引先責任者を削除するか」の指定です。

レコードトリガフローでは「$Record」変数が自動で作られましたが、画面フローでは変数を自分で指定しないといけません。
必要な変数は以下の通りです。

 

varContactId = 削除対象とする取引先責任者自体の Salesforce ID 用
varAccountId = 削除する取引先責任者が属する取引先の Salesforce ID 用

 

フローの外部から読み込むので、「入力で使用可」とする必要があります。

 

 

 

削除後の流れは、最初のフローとほぼ同じです。
取引先 ID の変数が、「$Record. 企業名」から「varAccountId」に変わっていること以外に違いはありません。

 

さて、このフローをどうやって呼び出すか、という「最後の課題」が残っています。

ここで若干の「掟破り」ですが、ちょっとした Visualforce の実装が発生します。
コード開発の知見が殆ど要求されない非常にシンプルなものなので、何卒ご了承ください。

 

以下のソースで Visualforce ページを新規作成します。

 

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

<apex:page standardController=" Contact ">
<flow:interview name=" CountActiveContactAfterDelete "
finishLocation="/{ !Contact.AccountId }">
<apex:param name=" varAccountId " value="{ !Contact.AccountId }"/>
<apex:param name=" varContactId " value="{ !Contact.Id }"/> </flow:interview> </apex:page>

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

 

flow:interview name=" CountActiveContactAfterDelete "

これはフロー名の指定になります。
あとはオブジェクト名、項目名、フロー変数名の指定です。

フローを呼び出す、ならびにフローの変数に取引先および取引先責任者の ID を送り込む作業を、Visualforce に担わせるということです。

 

Vislaforce ページを保存したら、最後の仕上げです。

本記事の冒頭でご案内した「標準アクションの上書き」を使って、標準の削除アクションに今回作成した Visualforce ページを割り当てます。

（・・・おお、見事につながった！）

 

これにより、「取引先責任者の削除」 → 「VF ページが情報を収集してフローを呼び出す」 → 「フローが呼び出され、取引先責任者の削除と他の有効コンタクト数の集計を行い、取引先に数値を書き込む」 → 「VF ページで定義された finishLocation により取引先ホーム画面に遷移する 」一連の流れが、標準の「削除」ボタンを押すことにより発生します。

 

これだけのことが、99% ノンコーディングで実現するようになりました。
今まで Lightning フローを「まだまだ敷居が高い」と敬遠されていた方も、Summer '20 のレコードトリガフローのリリースを機に、是非挑戦していただければ幸いでございます。

 

 

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

Summer '20 新機能シリーズ、いかがでしたでしょうか。

個人的には「レコードトリガフロー」のリリースが最も大きいと思っております。

Lightning フローは、コーディング不要とは言え、開発的な知見がかなりのレベルで求められ、まだまだ敷居が高いと感じていましたが、このリリースにより、プロセスビルダーに近いレベルまで敷居が下げられ、より多くの人がフローを活用できるようになるのでは、と感じております。
今までコーディングが必要だったために諦めてきた業務プロセスの改善を、フローによって解決できる事例もきっと少なくないと思います。

皆様も是非 Lightning フローに着目していただければ幸いです。

 

不明点は遠慮なくお問合せください。皆様の疑問点は我々の財産です。

 

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

 

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

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