2020.11.06 「Salesforce - Winter '21 新機能をチェック（前編）：Sales Cloud, Service Cloud, Lightning Platform 編」

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

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

お待たせいたしました、先月下旬、Winter '21 がリリースされました。

Summer '20 からわずか2ヶ月半のインターバルですので、「ついこの間リリースがあったばかりなのに、もうバージョンアップなの」とお思いの方も少なくないかと存じます。

リリースノートはこちらからダウンロードいただけます。
https://help.salesforce.com/articleView?id=release-notes.salesforce_release_notes.htm&type=5&release=228

インターバルが短いので、新機能も少ないのでは・・・という予想に反し、かゆい所に手が届く機能改善や、以前ベータリリースされていたものの正式リリースなど、結構ボリュームのあるリリースとなっているようです。

今回は前後編として、Sales Cloud、Service Cloud、およびプラットフォーム機能を前編、開発者向け機能、Pardot、および Einstein Analytics を後編としてお送りいたします。

実際に使ってみた際の画面コピーをふんだんに盛り込み、できるだけ簡潔でわかりやすい記事にしたいと思っております。

今回ピックアップするのは以下の機能になります。

【Sales Cloud】キャンペーンのリストメールでスケジュール設定が可能に
【Sales Cloud / Lightning Platform】動的アクションが標準オブジェクトに対応（ベータ）、およびカスタムオブジェクトのデスクトップ向け動的アクションと動的フォームが正式リリース
【Lightning Platform】レコードの削除をトリガとするフロー
【Lightning Platform】多要素認証（旧名：2要素認証）の強化と SMS のサポート
【Service Cloud】 Service 設定アシスタント
【Service Cloud】 Einstein ボットの日本語への対応

まずは、リストメールのスケジュール設定についてです。

今までは、キャンペーンメンバーに対するメールの一括送信は「今すぐ送信」しかできなかったため、例えば月曜早朝の業務開始前など時間帯を指定しての送信には、一旦対象となるリードや取引先責任者をレポートで抽出して、条件を付与するアップデートを行った上で、リードや取引先責任者側の一括メール送信機能を使用する必要がありましたが、今回のリリースから、キャンペーンからのリストメールでもスケジュール機能が使用できるようになりました。

キャンペーン画面の「キャンペーンメンバー」リストから、[▼] をクリックするとメニュー一覧に [リストメールの送信] が表示されます。

リストメールの送信画面で、本文を作成し（一般的には予めテンプレートを作成しておいて選択します）、右下の [送信] ボタンの右 [▼] をクリックすると [後で送信] が表示されます。

日時を指定して保存をすると、指定した時間の送信がスケジュールされます。

スケジュールの変更は右下のメニューから行います。

リードや取引先責任者の一括メール送信と同様に、送信者名義に組織のメールアドレスを使用することはできません。
送信設定を行ったユーザの [私の設定] で指定した [私のメールアドレス] で固定になりますのでご注意ください。

一つ気になったのが、スケジュール設定を保存して未配信のメール送信を取り消す方法についてです。

Classic ではメニューを見つけられたのですが、Lightning ではどうやっても設定ができませんでした。

ヘルプでは以下のように記載があるのですが・・・

営業担当向けの後で送信する設定
https://help.salesforce.com/articleView?id=email_schedule_send_later.htm&type=5

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

営業担当がスケジュール済みメールを管理する、オブジェクトのホームページまたは Salesforce ホームページに移動します。
ギアアイコンをクリックし、[編集ページ] を選択します。
[後でメールを送信 - 保留中リスト] コンポーネントをページに追加して、変更を保存します。
[後でメールを送信 - 保留中リスト] コンポーネントでは、まだ送信されていないスケジュール済みメールのリストが作成されます。

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

この [後でメールを送信 - 保留中リスト] コンポーネントをアプリケーションページビルダーで追加できませんでした。
もしかするとコンポーネントの追加が間に合っていないのかもしれません。
しばらくは管理者が一時的に Classic に切り替えて、設定メニューの [監視] - [一括メール送信] メニューからキャンセル手続きを行う必要がある模様です。

最適なタイミングでのリストメールの送信
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_sales_productivity_email_schedule_list_email.htm

[後で送信] を使用したメールのスケジュール
https://help.salesforce.com/articleView?id=email_schedule_send_later_parent.htm&type=5

一括メール送信キュー: Salesforce による一括メール送信の状況の監視
https://help.salesforce.com/articleView?id=email_my_massmail_q.htm&type=5

続いては、動的アクションと動的フォームのリリースについてです。

それぞれレコードの特定条件によって、アクションや項目の表示を切り替えるというもので、機能自体は Summer '20 においてカスタムオブジェクトに限定してベータリリースされていました。

Summer '20 の際の記事でも取り上げておりますので、よろしければご覧ください。

2020.08.20 「Salesforce - Summer '20 新機能をチェック（２）：Sales Cloud & Lightning Platform 編」
https://csminfo.uhuru.jp/hc/ja/articles/900002240546

この時はベータリリースということもあり、日本語版リリースノートにも記載がなく、英語版の記事のみが提供されていましたが、今回 Winter '21 にて部分的に正式リリースとなり、かつ取引先や商談などの標準オブジェクトでもベータリリースの形ですが部分的に提供が開始されました。

リリース状況を表にすると以下の通りになります。

カスタムオブジェクトのデスクトップ向けはいずれも正式リリースになりました。
今回ベータで追加されたのが、標準オブジェクトの動的アクション、およびカスタムオブジェクトのモバイル向け動的アクションになります。

標準オブジェクトで動的アクションが使用できるようになった、ということは、「商談でフェーズが最終交渉になったときに限定して承認申請ボタンを表示する」ことが可能になった、ということです。

Lightning ページビルダーにて、商談のレコードページ編集画面を開き、[動的アクションを有効化（ベータ、デスクトップのみ）] をチェックします。

[アクションを追加] ボタンが表示されるので、クリックして表示したいアクションを追加していきます。
[承認申請] については「アクションの表示を設定」にて条件を設定します。

今回は先ほど述べたとおり「フェーズが "最終交渉" の場合」と指定します。
他の項目は常時表示とするため、条件を指定しないままにします。

商談のフェーズが「価格交渉」の場合は [承認申請] ボタンが表示されません。

「最終交渉」に変更して [フェーズを完了としてマーク] をクリックして確定させると [承認申請] ボタンが表示されました。

動的アクションの機能自体はベータ版とほぼ変わっていないので、上記の Summer '20 の記事がそのままご参考になるかと存じます。

[見積申請] アクションの表示条件の選択 (正式リリースとベータ)
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_forcecom_general_choose_show_submit_button.htm

動的アクションの新しい柔軟性をデスクトップ (正式リリースおよびベータ) とモバイル (ベータ) でフルに活用
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_lex_dynamic_actions_highlights_panel.htm

動的フォームについては、正式リリースにあたって機能に少々ブラッシュアップが行われています。

Summer '20 のベータリリースでは、動的フォームで使用する項目を一旦すべてページレイアウトに含めておく必要がありました。
今回の正式リリースでは、Lightning ページビルダー上でレイアウトセクションと項目を追加する機能が追加され、条件分岐で表示を切り替えたい部分だけ後からページビルダーで柔軟に設定することが可能になりました。

Summer '20 のベータで提供された、既存のページレイアウトを動的フォームにアップグレードする方法も残されています。

既存のページレイアウト設定状況に応じてどちらを取るか（もしくは併用するか）選択すると良いと思います。

動的フォームでレコードの詳細を分割 (正式リリース)
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_forcecom_lab_dynamic_forms_ga.htm?edition=&impact=

引き続いて、最近恒例となった Lightning フローの強化についてです。

毎回リリースのたびにブラッシュアップが行われているフロー機能ですが、 Winter '21 でも大きな改善がありました。

なんと、遂に「レコードの削除をトリガとするフロー」が実装されました！

レコードの削除前に実行するフローのトリガ
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_forcecom_flow_fbuilder_trigger_flow.htm

今まではレコードの作成や更新に関連してフローを起動することはできましたが、削除をトリガとするフローだけは不可能で、こればかりは Apex コーディングの出番となっていました。

今回「レコード削除をトリガとするフロー」の実装により、コーディングフリーで設定できる箇所がまた拡張されました。

改めて各種自動化プロセスで設定できる範疇を、操作とタイミングごとにまとめてみました。
（実は Salesforce のセミナーで受講した内容のほぼ丸写しなのですが・・・）

※ レコード保存前フローについては、更新の対象はトリガしたレコード自体に限定され、リレーションを参照して更新することができません。

削除をトリガとするフローでは、起動のタイミングは削除前に限定されます。
とはいえ、削除後にアクションを実行させたい場合は、フローの中で「トリガした $Record の削除」アクションを設定し、その後の段にアクションを指定すれば大丈夫です。

削除前にフローを実行するということは、「削除してはいけないレコードを削除しないように条件設定する」ということも可能になります。

自分が所有するレコードは、プロファイルでオブジェクト権限をはく奪しない限りはフルアクセスが許容されているため、「大事なレコードを誤って削除しないようにする」施策って、実は今まで標準機能では提供が無かったのです。

（入力規則はあくまでも「保存時に発動」で、「削除時に発動」はできませんので）

これにより、特定の条件を持つレコードは所有者やシステム管理者でも削除できないように、フローで縛りを掛けることができることができるようになりました。

私が担当しているお客様でも、レコード名に「【※絶対に削除しちゃダメ！】」って付けて運用している方が数件いらっしゃるので、忘れないうちに「フローで解決できますよ！」って案内したいと思っております。

そういえば、以前のカスタマーサポート通信でも、レコード削除時に発動するフローを、疑似的に Lightning アクションから Visualforce ページに遷移して呼び出す、という設定をご案内していました。そう、Summer '20 で「レコード変更フロー」が実装されたときにご案内したものです。

2020.09.18 「Salesforce - Summer '20 新機能をチェック（４ - 最終回）：Community Cloud & 開発者編」
https://csminfo.uhuru.jp/hc/ja/articles/900002719043

これ、今なら Visualforce なしに改修できますね。

近いうちに「改訂版」をお送りしますので、しばしお待ちくださいませ。

続いては多要素認証の強化と SMS による認証のサポートについてです。

今までは「2要素認証（2FA）」と呼ばれていた、「ID とパスワードだけではなく、他の認証要素もプラスしてセキュリティを強固にする」機能が、「二つで充分ですって？いや、それでも足りないです、じゃあ名前変えちゃいましょう」とばかりに、「多要素認証（MFA）」に名称が変更されました。

Salesforce 複数要素認証の FAQ
https://help.salesforce.com/articleView?id=000352937&language=ja&mode=1&type=1

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

MFA と 2FA の違いは何でしょうか?

2 要素認証 (2FA) の概念はよく知られているかもしれません。MFA と 2FA はともに、ID を証明する複数の認証要素の提供をユーザに要求することで、不正アクセスから保護します。これらの唯一の違いは、ログインに必要な要素の数です。MFA は 2 つ以上の要素を要求し、これにより、認証メカニズムのさまざまな組み合わせが可能になります。一方、2FA は 2 つの要素のみを要求する MFA の一部です。

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

多要素認証を強化した理由は、昨今の COVID-19 に起因してリモートワークの比重が高まったことを受け、各ユーザの端末や各々のアカウントのレベルまでセキュリティを堅牢にする必要によるものであることは明らかです。

引用した FAQ にも次のように記載があります。

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

世界はいま大変なことになっています。MFA は本当に優先すべきものなのでしょうか?

わかっています。何でもない時でも変化に対応するのは大変です。COVID-19 の世界的流行により、サイバー犯罪が増加していることを踏まえ、Salesforce ユーザアカウントを保護し、顧客データを守るための最も簡単で効果的な方法として MFA を優先することをお勧めします。今すぐ MFA への移行ができない場合は、ご利用中の Salesforce 商品に対応する MFA ソリューションについて調べておき、今後の MFA プロジェクトのロードマップを用意してください。最初の一歩として最適なこの FAQ には、その他のリソースへのリンクも掲載されています。

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

今まで多要素認証に触れてこなかったお客様にも、わかりやすい形で多要素認証の導入をサポートするウィザードが設定画面のホームに追加されています。

設定ホームの左メニュー上部に追加された「多要素認証アシスタント」をご参照ください。

1 か所での多要素認証の実装の促進
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_mfa_assistant.htm

併せて、多要素認証の「確認コードを受信する方法」に、SMS （ショートメッセージサービス：スマートフォンの電話番号と紐づいた端末にテキストメッセージを送信する機能）が追加されました。

従来「パスワード認証に加えてメールで確認コードを受信する」のが多要素認証で一般的に用いられてきましたが、メールの場合「メールサービスのアカウントとパスワードを知っていれば誰でも参照できる」ため（特に G Suite などクラウドベースの場合端末を問わずにアクセス可能）、特定の端末を「物理的に所有している」ユーザに限定して確認コードを送りたいというニーズがありました。

今までは Salesforce Authenticator というアプリをスマートフォンにインストールして、端末を指定して確認コードを送信する仕組みを取ってきましたが、SMS がサポートされたことにより、アプリをインストールすることなく特定のスマートフォンに確認コードを送ることができるようになりました。

有効化には以下の設定が必要です。

組織設定の [セキュリティ] - [セッションの設定] で、[ユーザはテキスト (SMS) で ID を検証する] をチェックします。

併せて [他の方法が登録されている場合、メールによる ID 検証を防止する] をチェックすることで、ユーザに携帯番号が登録されている場合、メールでの確認コード送信が行われないようになります。

但し、ユーザによってはメールでも確認コードが受信できるようにしておきたいというニーズがあると思います。

その場合は、権限セットでシステム権限 [メールベースの ID 検証オプション] を割り当てることで、システムで上記のような設定をしても、SMS とメールのどちらで確認コードを受信するかを選択できるようになります。

SMS、メール、Salesforce Authenticator アプリケーション経由での確認コードの受信
https://help.salesforce.com/articleView?id=000332387&type=1&language=ja&mode=1

とはいえ、SMS は Salesforce によると「あまり推奨できない認証要素」だそうです。

先ほどの FAQ から引用します。

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

MFA の第 2 要素としてメールまたは SMS を使用できますか?

すべての認証要素が同様に作成されるとは限りません。メールや SMS テキストメッセージは MFA の第 2 要素として許可されません。メールのログイン情報は侵害される可能性があり、テキストメッセージはインターセプトされる可能性があるためです。

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

やはり「Salesforce Authenticator を導入し、インストールしたモバイルデバイスにて PIN や生体認証を有効化する」のがベストプラクティスなようです。

もちろん「多要素認証がないよりある方がまし」なのは言うまでも無いので、Salesforce Authenticator のロールアウト完了までの繋ぎとしては、SMS 認証は充分有効性があるはずです。

最後に、Service Cloud の機能強化についてです。

今回の大きなトピックは「Service 設定アシスタント」の提供になります。

Service Cloud の最大の難点は、「導入手順が非常に煩雑」という点だと思われます。
メールとケースのルーティング、エージェントの優先度、コンソール設定、メールテンプレート、ナレッジ、必要に応じてメール以外のチャネルやチャットボットの設定など、挙げていくと気が遠くなりそうです。

今回のリリースでは、その設定をある程度「お任せ」で出来るようになりました。
これは実に大きな機能改善だと思います！

設定のホーム画面に [Service 設定アシスタント] が登場しました。
早速 Service Cloud アプリケーションを有効化しましょう。

数分間待機すると「使用開始」ボタンが表示されます。

「使用開始」をクリックすると、まず最初に表示されるのが「サービスをパーソナライズ」、よく見てみるとこれは Service Cloud 設定の「いろはの "い"」とも言える「メール to ケース」の設定ですね。

「サポート窓口のアドレスを入れてください、ルーティングアドレスを生成するのでプロバイダに共有してください」と、案内もシンプルにわかりやすくなりました。

メール to ケース設定が終わると、「サービスの設定」ホーム画面に「推奨設定」メニューが表示されるようになります。

あとはここから各種設定を行っていきます。

各種設定の中には、サービス向け Lightning フローをお任せで設定してくれる、というものもあります。

最近の目を見張る数々の機能追加もあるものの、やはり他のプロセス自動化設定（ワークフロールールやプロセスビルダーなど）に比べるとまだまだ敷居が高いので、お任せで作ってもらったフローの設定画面を見たり、または設定をコピーして自分でカスタマイズしたりすることは、フローの学習にも非常に役立つと思われます。

Service Cloud 環境でフローを知りたいユーザの方、是非 Service 設定アシスタントをお試しになってはいかがでしょうか。

Service 設定アシスタント: ゼロから数分でコンソールを設定
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_service_setup.htm

サービスの設定と Service 設定アシスタントを知る
https://help.salesforce.com/articleView?id=console_lex_service_setup.htm&type=5

Service Cloud の導入の敷居が下がったことで、多くのユーザが Service Cloud の様々な機能、特にチャットボットなど「メール以外のサービスチャネル」に触れることになりますが、このタイミングで Einstein ボットがついに英語以外のいくつかの言語に対応することになりました。

今回日本語と中国語（簡体字および繁体字）が正式サポートされ、ロシア語、オランダ語、ポルトガル語（ブラジル）がベータリリースされました。

今回は時間が足りず実際の設定を手元では行えませんでしたが（やっぱりこればかりは時間がそれなりに掛かるのです・・・）、Salesforce のセミナーを受講してデモを拝見したところ、部分的には未対応なところ（例えば「はい / いいえ」に対応せず「Yes / No」と入力する必要がある、など）もあったものの、コミュニケーションを妨げるような制限もなく、実にスムーズに動作していました。

せっかくの機会なので、カスタマーサポート通信でも「Einstein ボットを日本語で試してみた」特集を近日お送りしたいと思っております。

Einstein ボットがより多くの言語に対応
https://releasenotes.docs.salesforce.com/ja-jp/winter21/release-notes/rn_einstein_bots_language_updates.htm

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

Summer '20 から間を空けずにリリースされたので、Winter '21 は軽微なものになると予想していましたが、なかなかどうしてボリューム感のあるリリースとなりました。

スペースの関係上限られた内容となりましたが、未案内の新機能も含めて、是非リリースノートでご確認を頂ければと存じます。

個人的にはやはり「削除をトリガとするフロー」の実装に注目しましたが、一番インパクトがあるのがやはり「Service Cloud 設定アシスタント」ではないかと思われます。

設定の大変さを理由に Service Cloud の導入に二の足を踏んでいるお客様が少なくないと聞きますので、そういった方に今回のリリースは大きな福音となるのではないでしょうか。

ご不明点や「この機能をもっと掘り下げてほしい」ご要望ございましたら是非お知らせください。

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

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

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

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

コメント