“ケース”の検索結果
-
(2022年12月) Salesforceの運用に関する重要なお知らせ
この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート動画で更新内容を学ぶhttps://play.vidyard.com/arncwSGbAMswMWhjpMtnTw?全ての資料をダウンロードして学ぶダウンロードはこちら記事で更新内容を学ぶ本記事は「Salesforceの運用に関するお知らせ」の12月号となります。こちらの記事では、メンテナンス情報や技術情報、セキュリティ関連情報の構成で、特に重要な更新情報をピックアップしてご紹介いたします。必要なアクションをお客様にいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。2022年12月のトピックはこちらになります。本記事では、前月との差分である赤字の部分と、特に重要な情報をピックアップしてご紹介します。2023年 2月に予定している Spring ’23 新機能に関する情報です。バージョンアップに向けて、現在赤字部分の情報を公開しております。日本語版は準備中ではございますが、既にリリースノートもご覧いただけるようになっておりますのでご確認をお願いいたします。関連リンクバージョンアップに備えましょうSpring ’23 Pre-ReleaseSpring ’23 Release NotesSalesforce Sandbox Preview Instructions続いて、Winter’23 リリースノートの更新情報です。11/28以降の更新内容の中から、管理者様に把握しておいていただきたい内容をピックアップしています。Confirm Browser Version for Gmail IntegrationGmailインテグレーションとの連携に必要な最小のブラウザバージョン(ver.97)についての情報が追加されました。DevOps CenterDevOps Centerが英語版で正式リリースされた旨が追加されました。ICU ロケール形式の有効化リリース更新の時期がSpring '24に延期となりました。関連リンクWinter '23 リリースノート - リリースノートの変更次に、IE11のサポート終了についてです。先月と内容は変わりませんが重要な情報のため再掲載しております。Salesforceでは2022年内でIE11へのサポートを終了しておりますため、現在もIE11をご利用中のお客様はこちらの情報のご確認をお願いいたします。関連リンクLightning Experience でサポートされるブラウザおよびデバイスすべてのブラウザに関する推奨事項と要件Lightning Platform における IE11 サポート終了について続いて、MFAに関する内容です。Salesforce 多要素認証に関する FAQのナレッジの英語版が12/7に更新されています。関連リンクTrailblazer Community:多要素認証(MFA)コミュニティ 日本Salesforce 多要素認証に関する FAQ多要素認証(MFA)設定マニュアル ダウンロード多要素認証 (MFA) 適用ロードマップMFA特設ページEmployee Community license のユーザーにおける自動有効化/強制適用から除外する方法について追記されておりますので、当該ライセンスをご利用のお客様はご確認をお願いいたします。続いて、インフラ強化に関するアップデートです。インスタンスリフレッシュは、アップグレードされた新しいインフラストラクチャで構成されているインスタンスにお客様の組織を移動することで、パフォーマンスレベルを維持することを目的としています。今後の予定として、本番組織ではなく、Sandbox環境において2023年2月5日にインスタンスリフレッシュが予定されています。スライドに記載されているインスタンスにてSandboxをご利用のお客様は、「インスタンスリフレッシュメンテナンス」の公開ナレッジをご確認いただき、ご準備をお願い致します。Salesforce アプリケーションからのメールを受信できるようにするの公開ナレッジに更新がございます。HyperforceのメールリレーのIPアドレスとして、「KOR」と「SWE」のIPアドレスが追加されています。続いてリリース更新に関するアップデートのご紹介です。こちらは、次期バージョンのSpring '23のリリース更新になります。強制適用されるものが8件あります。関連リンクExperience Cloud サイトで Apex によって取得されるナビゲーションメニューへのユーザアクセス権限の適用コンテンツ盗聴保護を有効化ユーザの個人情報のより強力な保護の有効化Visualforce ページのクロスサイトスクリプティングを防止するための <apex:inputField> 要素の label 属性のエスケープメンテナンス計画の頻度の項目からメンテナンス作業ルールへの移行 Experience Cloud ゲストユーザに詳細なフロー権限が必要 ユーザコンテキストでの REST API を介したフローの実行SAML シングルサインオンフレームワークを更新そして、自動有効化されるものが2件ございます。この中で、必ず把握しておいていただきたいものは「拡張ドメインの有効化」と「Sring '23での一部のユーザのMFAの自動有効化」です。拡張ドメインは後ほどご紹介しますので、ここでは[Sring '23での一部のユーザのMFAの自動有効化]についてご紹介します。2022年2月より、契約上、ユーザインターフェースからSalesforceへログインする場合はMFAが必須になりましたが、システム上の制限はされていない状態です。今回、12月13日にMFAの自動有効化に関するメールを受け取られた組織を対象に、Spring '23でMFAを自動有効化します。まだ、MFAの設定をされていない場合は、早急にご確認いただけますよう、お願いします。なお、どうしてもSpring '23リリースまでに対応が間に合わない場合は、早めに弊社テクニカルサポートへご連絡ください。関連リンク拡張ドメインの有効化Spring '23 での一部のユーザの MFA の自動有効化こちらはSpring '23で有効化される予定だったリリース更新が延期されるという情報です。「ICUロケール形式を有効化」はSpring '24に延期します。「ケースメール通知のシステムアドレスとしてデフォルトの No-Reply アドレスを使用」は、Summer'23に延期します。「Visualforce JavaScript Remoting API の JsonAccess アノテーション検証の有効化」はWinter '24に延期します。ここからは、Spring '23で強制適用される重要なリリース更新についてです。まずは、「SAML シングルサインオンフレームワークの更新」に関する内容です。こちらは以前からご紹介させていただいておりますが、このリリース更新が強制適用されると、 SAMLによるシングルサインオンの動作に影響を与える可能性がございますため、Sandboxでリリース更新を有効にしていただき、動作の事前確認をお願い致します。関連リンクSAML シングルサインオンフレームワークのアップグレード (リリース更新)サービスプロバイダとして Salesforce を使用した SAML シングルサインオンSAML ID プロバイダとしての SalesforceSalesforce 組織または Experience Cloud サイト間の SAML SSO の設定シングルログアウト続いて、拡張個人情報管理についてです。この設定は、従来の「個人情報を非表示」設定に置き換わるものです。内容は、ポータルやコミュニティのユーザーなどの外部ユーザーが、他のユーザーの個人情報にアクセスするのを防ぎます。有効にすると、今後追加する項目は個人情報として分類され、外部ユーザには表示されなくなります。システム管理者は、項目セットを使用して、どの項目を個人情報として分類して非表示するかの設定ができます。Experience Cloudサイトをご利用のお客様は、ページ右側の「お客様への依頼 」の手順をご確認ください。関連リンク外部ユーザへの個人ユーザ情報の表示の管理個人ユーザ情報のポリシーとタイムライン ユーザの個人情報のより強力な保護の有効化 (リリース更新).Prepare for Enhanced Personal Information Management Enablement Prior to Spring ’23Protect External User PIISecuring Experience Cloud groupこちらはリリース更新とは異なりますが、Salesforceからメールを送信しているお客様にとって重要な内容となりますので、ご紹介します。全てのユーザ様が、Salesforceに直接ログインしている組織では、Spring’23のリリース以降、未検証のメールアドレスからのメール送信はできなくなりますので、ご注意ください。関連リンクSpring ’23 Release Notes - Verify Your Email Address to Send Email Through SalesforceSpring '22 「 Salesforce メール確認 」という件名の認証メールについて続いて、拡張ドメインです。拡張ドメインの有効化はSpring'23以降、自動有効化と強制適用を段階的に実施します。Spring'23では、事前に自動有効化の対象から除外するオプションが無効な組織に対して、拡張ドメインが自動有効化されます。現時点で拡張ドメインの影響調査が完了していない場合などは、自動有効化対象外とするためのオプションを有効化をお願いします。また、Summer '23リリースでは、その時点で拡張ドメインが未適用のすべての組織に対して、拡張ドメインを有効化します。Summer ‘23では、事前の除外申請はできません。そのため、もしどうしても間に合わないという場合には、リリース直後に無効化をする形でご対応をお願いします。関連リンクEnhanced Domains Timeline拡張ドメイン拡張ドメインに関する考慮事項Salesforce ドメイン (「私のドメイン」 と拡張ドメイン) の変更に備えた準備拡張ドメインを使用する理由My Domain and Enhanced Domains Quick Reference Guideサクセスナビ - 拡張ドメインの有効化とその準備 拡張ドメインの段階的な適用について、こちらの図にまとめておりますので、ご参考にしてください。こちらは、フローに関する今後のロードマップです。ご存知の管理者様も多いかと思いますが、ワークフロールールおよびプロセスビルダーは将来的にサポート終了になる予定です。現在は、ワークフロールールの新規作成ができない状態ですが、次期バージョンであるSpring '23では、プロセスビルダーの移行ツールがサポートされる予定です。また、将来変更される可能性がございます、現時点では、Summer '23でプロセスビルダーの新規作成はできなくなる予定です。ワークフロールールやプロセスビルダーは、多くのお客様にご利用いただいている機能と考えております。サクセスナビにフローへの移行ページを公開しておりますので、本件について初耳だという場合には、ますはサクセスナビをご一読お願いします。続いて、機能の廃止です。来年の6月、コミュニティライセンスのユーザ様はSalesforceモバイルAppへアクセスができなくなります。来年6月以降はブラウザからExperience Cloudサイトへアクセスするようにしてください。なお、対象となる具体的なライセンス種類がナレッジにまとまっていますので、Experience Cloudのご契約があるお客様は、ご確認をお願いします。関連リンクSalesforce Mobile App Community License Access Retirement「Salesforce Platform APIバージョン 21.0~30.0 の廃止について」です。こちらは、影響度の大きい更新の一つですので、毎月ご紹介しています。来年2023年6月をもちまして、APIバージョン21.0~30.0 は利用不可になる予定です。本件に関して、12月14日に製品コミュニケーションメールが送信されており、また機能廃止に関するダイジェストもメールで送信されていますので、そちらも併せてご確認いただき、早めのご対応をご検討ください。関連リンクSalesforce Platform API バージョン 21.0 ~ 30.0 の廃止Salesforce Event Log File BrowserEventLogFile オブジェクトの API Total Usageイベント種別12月度分の更新情報は以上となります。最後までご覧いただき、ありがとうございました。
-
(2022年10月) Salesforceの運用に関する重要なお知らせ
この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート動画で更新内容を学ぶhttps://play.vidyard.com/TGeXbhV1YTFFpio7J5rXSC全ての資料をダウンロードして学ぶダウンロードはこちら記事で更新内容を学ぶ本記事は「Salesforceの運用に関する重要なお知らせ」の10月号となります。こちらの記事では、メンテナンス情報や技術情報、セキュリティ関連情報の構成で、特に重要な更新情報をピックアップしてご紹介いたします。必要なアクションをお客様にいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。2022年10月のトピックはこちらになります。本記事では、前月との差分である赤字の部分と、特に重要な情報をピックアップしてご紹介します。Winter ‘23のバージョンアップが、10/16に実施されました。新機能に関するウェブセミナーが、11/8~11にスケジュールされています。新機能ウェブセミナーの申し込みページへのリンクより、お申し込みができるようになっていますので、奮ってご参加ください。関連リンクWinter'23プレリリース環境のサインアップサイトWinter’23 リリースノート(日本語)Salesforce Sandbox プレビュー手順リリースサイトRelease in a BoxリリースモジュールRelease Overview DeckFeature MatrixThe 360 Blogバージョンアップに備えましょうWinter '23 新機能リリース続いて、Winter '23リリースノートの更新情報についてです。9月分と10月分の更新の中で、重要なものをピックアップしています。Spring '23 での一部のユーザの MFA の自動有効化 (リリース更新)先月の「Salesforceの運用に関する重要なお知らせ」では、ユーザ数が100名未満の組織において、Winter '23のリリース更新画面にMFAの自動有効化が表示される予定である旨お伝えしました。今回の変更点は、100名未満の条件は使用しなくなった旨が追記されています。そのため、100名以上のユーザ数がいる組織の管理者様も、必ずリリース更新画面をご確認いただけますよう、お願いします。リリース更新にMFAの自動有効化が表示されていたら、Spring '23に自動有効化が行われる予定なので、その前にSalesforceに直接ログインするユーザ様に対するMFAの設定が完了していることをご確認お願いします。Review Hourly Send Limits for Single Emailsメールコンポーザー(=メールアクション)を使って、外部へメール送信をする場合の、時間毎の新たな制限がついかされたという内容です。今まで、Salesforceの画面から、手動で送信するメールについては、特に制限はありませんでしたが、2022年9月22日以降に新規作成された組織については、1時間毎に250件までという制限ができました。なお、既存の日次送信制限(5000件)は変わりません。My Domain Login Page Was Changed[私のドメインの画面に、認証プロバイダーや証明書を使用してログインができるような設定をしている場合に、ログイン ページの表記に変更が加わったという内容になります。変更前後の画面は、リリースノートでご確認いただけます。より大量の予測をさらにすばやく保存をするというCRMAの機能の正式リリース大規模な予測の書き戻しが有効になっている時の、デフォルトの制限に関する情報が更新されました。今まで200万だったものが500万に変更されました。Chatter Free and Chatter External Users Are Automatically Excluded from MFA Auto-Enablement and Enforcement皆様ご存知の通り、Chattr FreeやChatter Extrnal UserはMFAの対象外です。そのため、MFAの自動有効化や強制適用の対象にはならない旨が追加されました。関連リンクSpring '23 での一部のユーザの MFA の自動有効化 (リリース更新)Review Hourly Send Limits for Single EmailsMy Domain Login Page Was Changedより大量の予測をさらにすばやく保存 (正式リリース)Chatter Free and Chatter External Users Are Automatically Excluded from MFA Auto-Enablement and Enforcement次は、IE11のサポート終了に関するお知らせです。こちらはこれまでのご案内と変更はありませんが、重要な内容なので再掲載しています。Microsoft社がIE11のサポートを終了したことを受けて、Salesforceも今年一杯でIE11のサポートを終了します。IE11をご利用中のお客様は、サポートされているブラウザへの移行をお願いします。関連リンクLightning Experience でサポートされるブラウザおよびデバイスすべてのブラウザに関する推奨事項と要件Lightning Platform における IE11 サポート終了について続いてはLightning Syncに関する情報です。こちらも新たな情報はありませんが、重要な内容のため再掲載となります。Microsoft社は2022年10月から、Exchange Onlineの基本認証の廃止をアナウンスしています。そのため、Lightning Syncの接続方法として、サービスアカウントを使用している場合には、今月中に接続方法の移行が必要です。対応方法など詳細につきましては、関連リンクをご確認ください。関連リンクReview Microsoft Announcements on Basic Authentication Retirement for Exchange OnlineMicrosoft Office 365 での Lightning Sync サービスアカウント接続方法についてそして、MFA関連のリソースの更新情報です。Salesforce 多要素認証に関する FAQ のナレッジが、英語版のみ10/7に更新されています。また、多要素認証 (MFA) 適用ロードマップ のナレッジが、英語版のみ9/28に更新されています。関連リンクTrailblazer Community:多要素認証(MFA)コミュニティ 日本Salesforce 多要素認証に関する FAQ多要素認証(MFA)設定マニュアル ダウンロード多要素認証 (MFA) 適用ロードマップMFA特設ページロードマップの具体的な変更点は、Marketing CloudのInteligence(Datrama)の強制適用が10/6に実施されました。関連リンク多要素認証 (MFA) 適用ロードマップMFAのナレッジの変更点は、以下5点です。#1:ナレッジに、自動有効化と強制適用についての説明のセクションが追加されました#2:U2Fセキュリティキーに関するセクションが削除されました#3:リカバリーコードを主要な検証方法として使用すべきではない旨が追記されてます以下は、パートナー様向けの情報です。#4:パートナーがお客様のユーザアカウントを使用する場合の MFA の取り扱いについて追記されてます#5:1 つのユーザアカウントを複数のパートナーが使用する場合のガイダンスが追記されました。詳細は関連リンクに纏められておりますので、パートナーの皆様はご確認お願いします。関連リンクHow to Satisfy the MFA Requirement for the Partner Admin Shared Login Use Case続いてはインフラ強化に関する情報です。最初にインスタンスリフレッシュについてです。インスタンスリフレッシュは、アップグレードされたインフラストラクチャで構成されているインスタンスにお客様の組織を移動することで、パフォーマンスレベルを維持することを目的としています。今後の予定として、本番組織ではなく、(主に日本以外のお客様の)Sandboxにおいて2022年11月6日と12月18日にインスタンスリフレッシュが予定されています。上記スライドに記載されているインスタンスにてSandboxをご利用のお客様は、関連リンクをご確認いただき、ご準備をお願い致します。関連リンクインスタンスリフレッシュメンテナンス続いて、「Salesforce アプリケーションからのメールを受信できるようにする」のナレッジに更新がありました。ARINで使用されているIPアドレス範囲に新しい範囲が追加されていますので、Salesforce 組織からのメール受信をIPアドレスでフィルタされているお客様はナレッジをご確認ください。また翻訳版ナレッジの更新が完了していないため、詳細につきましては英語版のナレッジをご確認ください。関連リンク許可すべき Salesforce の IP アドレスとドメインHyperforce 上の Salesforce サービスへの中断しないアクセスを維持するSalesforce アプリケーションからのメールを受信できるようにする続いて今後自動適用が予定されているリリース更新をご紹介します。Spring'23で自動適用されるリリース更新は、現時点で13個が予定されています。関連リンクユーザの個人情報のより強力な保護の有効化Experience Cloud サイトで Apex によって取得されるナビゲーションメニューへのユーザアクセス権限の適用コンテンツ盗聴保護を有効化拡張ドメインの有効化ICU ロケール形式の有効化リリース更新の中には、お客様組織おけるログインの動作や使用されるURLについて変更が行われる更新、またお客様のカスタマイズについても動作に変更が加わる可能性がある更新がございます。そのため、事前にお客様組織における影響を確認するためにも、リリース更新の内容をご確認いただき、Sandboxにて動作確認/テストを実施いただくことを推奨しております。今回はこれらのリリース更新のなかで、特にご認識いただきたい更新を2つご紹介します。関連リンクVisualforce JavaScript Remoting API の JsonAccess アノテーション検証の有効化Visualforce ページのクロスサイトスクリプティングを防止するための <apex:inputField> 要素の label 属性のエスケープSpring '23 での一部のユーザの MFA の自動有効化メンテナンス計画の頻度の項目からメンテナンス作業ルールへの移行Experience Cloud ゲストユーザには詳細なフロー権限が必要SAML シングルサインオンフレームワークのアップグレードケースメール通知のシステムアドレスとしてデフォルトの No-Reply アドレスを使用ユーザコンテキストでの REST API を介したフローの実行1つ目は「SAML シングルサインオンフレームワークの更新」です。こちらは以前にもご紹介いたしましたが、このリリース更新が自動適用されると、 SAMLによるシングルサインオンの動作に影響を与える可能性がございますため、Sandboxでリリース更新を有効にしていただき、動作の事前確認をお願い致します。関連リンクSAML シングルサインオンフレームワークのアップグレード (リリース更新)サービスプロバイダとして Salesforce を使用した SAML シングルサインオンSAML ID プロバイダとしての SalesforceSalesforce 組織または Experience Cloud サイト間の SAML SSO の設定シングルログアウト2つ目は拡張ドメインです。こちらも以前からご紹介しておりますが、最新のブラウザ要件に準拠することを目的として、Salesforce 組織のドメイン形式を更新します。Experience Cloud のような外部公開しているURLを含む複数のURLが更新されるため、Sandbox で拡張ドメインを有効化することによる事前確認を推奨しており、併せて自動適用前に本番環境へ適用することも推奨しております。影響度の高い更新となりますため必ずご確認いただけますと幸いです。関連リンクSalesforce ドメイン (「私のドメイン」 と拡張ドメイン) の変更に備えた準備拡張ドメインを使用する理由My Domain and Enhanced Domains Quick Reference Guide拡張ドメインの有効化とその準備 拡張ドメインの有効化続いて、機能の廃止についてです。まずは、Marketing Cloudに関するもので、Thunderhead が組み込まれた従来版の Interaction Studio 製品の廃止です。こちらは2023 年 3 月 1 日に廃止が予定されています。関連リンクMC Interaction Studio Thunderhead Retirement続いて、「Salesforce Maps ライブ追跡のサードパーティインテグレーション」です。こちらは機能の契約期間によって廃止日が変わりますのでご確認ください。関連リンクSalesforce Maps ライブ追跡のサードパーティインテグレーションの廃止について新たな情報ではございませんが、赤枠に記載の Salesforce Platform APIバージョン 21.0~30.0 の廃止について、影響度の大きい更新の一つですので改めてご紹介させていただきます。API バージョン21.0~30.0は、既にSummer’22 でサポート終了となっておりましたが、今後は来年2023年6月をもちまして利用不可とすることを予定しております。お客様の利用状況や開発内容によっては、対応に時間がかかる場合もございますので早めの対応を推奨しております。確認方法や対応方法につきまして、ナレッジなどのコンテンツをご用意しておりますのでご確認ください。関連リンクSalesforce Platform API バージョン 21.0 ~ 30.0 の廃止Salesforce Event Log File BrowserEventLogFile オブジェクトの API Total Usageイベント種別10月度分の更新情報は以上となります。最後までご覧いただき、ありがとうございました。
-
この記事で学べることなぜAccount Engagementフォームを活用するのかAccount Engagementフォーム関連機能の設定方法この記事のゴールこの記事のゴールは「見込み客獲得・フォローのためのフォーム設定の完了」です。そのために、以下3ステップで進めていきます。Account Engagementのフォームを活用する目的を理解するフォーム関連機能の概要と自社で利用する機能を理解する設定を実施するなぜフォームを活用するのかフォームを活用する目的は大きく2つです。1.新規見込み客情報を取得するため問い合わせ・資料ダウンロード・イベント申し込みなどのフォームを設置し見込み客の会社名、役職、メールアドレスなどの情報を取得します。それによりアプローチ可能な見込み客の総数を増やすことができ、最終的な受注件数の増加に繋がります。2.Web行動が追跡できる見込み客を増やすためAccount Engagementのフォームを通過しCookieと紐付くことで、どの見込み客が自社のどのWebページを見たのかなど、Web上の行動を追跡できるようになります。それにより見込み客の興味関心に合わせたアプローチが可能となります。※プロスペクトとCookieの紐づけについての詳細はこちらの記事をご覧ください。サクセスナビ記事:プロスペクトとCookieの紐づけを理解しましょうこれらの目的のため、以下の視点でフォームを設置できる箇所がないかを検討してみましょう。・すでに自社Webサイトに公開済みの問い合わせフォームなどをAccount Engagementに切り替える問い合わせフォームなど、すでにあるフォームをAccount Engagementに切り替えることも重要です。これにより、ただ見込み客情報を入手するだけなく、見込み客がアクティブプロスペクトとなり、Web上の行動を追跡できるようになります。・新たな入り口(ゲート)を増やすたとえば、自社Webサイトで公開されているお役立ちコンテンツや資料はありませんか?これらをゲート付きコンテンツ※にすることで、新規見込み客を獲得する入り口(ゲート)を増やすことができます。※ゲート付きコンテンツ:閲覧する際にフォーム入力が必要なコンテンツ。新規見込み客獲得の手法として、ホワイトペーパーダウンロードなどで用いられる。具体的な利用シーンとしては以下が挙げられます。問い合わせや資料請求フォームの設置ホワイトペーパーダウンロードの設置イベントの申込みページの設置フォームを活用する目的や活用のイメージがついたら、次はそれを実現する機能を見ていきましょう。フォーム・ランディングページ・フォームハンドラー見込み客獲得のため、Account Engagementではフォーム・ランディングページ・フォームハンドラーの機能を活用します。それぞれの機能の概要を理解し、自社でどのように活用できるか検討していきましょう。○各機能の特徴フォーム問い合わせや申込みなどのシーンで見込み客の情報を取得するための入力フォームです。取得したい項目を任意で設定し、既存のWebページやAccount Engagementで作成したランディングページに設置して使用します。ランディングページAccount Engagement上でコーディング不要で作成できるWebページです。イベント申し込みや資料ダウンロードページなど、マーケティング担当者が一時的に公開したり、随時更新を行うWebページで活用されます。ランディングページ内でイベントや資料などに関する情報を掲載し、ページ内に設置したフォームの入力を促すといった使い方が一般的です。フォームハンドラー外部のフォームをAccount Engagementと連携させるための機能です。すでに自社サイトに設置済みのHTMLフォームをそのまま流用し、見込み客の情報をAccount Engagementに転送できます。既存Webページのデザインやレイアウトを維持したまま利用できます。○利用機能の選び方フォームの実装方法と利用機能の組み合せは3種類です。自社の要件にあった方法を選択しましょう。簡易的なWebページを作成し、フォームを設置する→フォーム+ランディングページ既存Webページに新たにフォームを追加、もしくは既存フォームをAccount Engagementフォームに置き換える→フォームのみ既存のWebページおよびフォームのデザインを変えずにAccount Engagementに情報を送信する→フォームハンドラーフォーム活用のポイントや自社で利用すべき機能は理解できたでしょうか?Account Engagementの機能を用いて見込み客獲得のための入り口を設けることも重要ですが、加えて見込み客のフォーム登録を検知し、リアルタイムに通知や営業フォローを行なう仕組みを作ることも重要です。獲得した見込み客をフォローする仕組みフォームを通じて問い合わせやイベント申込みをした見込み客は、今その瞬間自社への興味関心が高い見込み客であり、タイムリーにフォローを行うことで商談化の可能性がより高くなります。そのために、Account Engagementは誰に、どのように割り当てや通知を行うかを設定することができます。これを活用してタイミングを逃さずにフォローを行うための仕組みを作りましょう。○誰に割り当てるか割り当て先の設定方法は4つあります。見込み客がフォームを通過したらまず社内の誰に割り当てるのが最適か、自社の運用に最も合う割り当て先を選択しましょう。おすすめは「ユーザへの割り当て」です。マーケティングチームや営業マネージャーなど特定の個人に一度割り当てをしてから手動で再振り分けをするケースが一般的です。またその見込み客がすでにSalesforceにリード/取引先責任者としてレコードがある場合、そのレコードの所有者に直接通知を出すことも可能です。○どのように通知を行うか指定された割り当て先に対して通知する方法は2つあります。おすすめは「SalesforceのToDo発行」です。SalesforceレポートでToDoの対応状況を一覧で確認でき、営業担当が漏れなくフォローしているかがわかります。フォーム通過した見込み客をフォローするための仕組みや方法について理解できましたでしょうか?次はいよいよ設定を行っていきましょう!設定方法フォームhttps://play.vidyard.com/Ro3TdP13h5LrnPxLyadouQ詳細かつ最新の情報は以下のサイトをご確認くださいヘルプ記事:フォームの作成ヘルプ記事:フォームのトラブルシューティングとFAQランディングページhttps://play.vidyard.com/W8tnT3s5cKxwAae6PEjXnL最新の情報は以下のサイトをご確認くださいヘルプ記事:ランディングページ用レイアウトテンプレートの作成フォームハンドラーhttps://play.vidyard.com/1RJh4g7AtsPbK4uNfNJ152詳細かつ最新の情報は以下のサイトをご確認くださいヘルプ記事:フォームハンドラーヘルプ記事:フォームハンドラのトラブルシューティングフォームを通過した見込み客のフォロードリル:フォーム通過したプロスペクトを自動で特定の担当者に割り当てる学習ツールより詳しく知りたい方は、エキスパートコーチングのオンデマンド動画をご視聴ください。Premier Success Planをご契約のお客様は、動画視聴後1対1のフォローアップセッションにお申し込みいただけます。エキスパートコーチング:フォームとランディングページの活用まとめ無事にフォームの設置と見込み客フォローのための設定は完了できましたでしょうか?ご不明点やエラーの解消が必要な場合は、弊社テクニカルサポートにお問合せください。弊社サポートエンジニアが貴社のSalesforce/Account Engagement環境を確認の上、具体的な手順をご案内いたします。ナレッジ記事:Salesforce カスタマーサポートへの問い合わせフォームを設置したら、次はさらに効果を高めるためのノウハウを学びましょう!「活用7ステップ」全体に戻りたい場合はこちら
-
この記事で学べること脅威検知機能の概要脅威検知アプリケーションの設定方法トランザクションセキュリティによる管理者への通知設定イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング:セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング:イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとは脅威検知は、リアルタイムイベントモニタリングに含まれるログとなります。脅威検知機能の概要脅威検知機能はイベントモニタリングに含まれる機能の一つであり、統計および機械学習の手法を駆使してSalesforce組織に対する脅威を検知します。この機能により、組織内で発生しているアクティビティに対して、不審なもの・普段とは傾向が異なるものがないかどうかが自動で分析され、万が一異常な傾向があった場合には「脅威検知イベント」としてその内容をログに記録します。また、同じイベントモニタリングに含まれるトランザクションセキュリティ機能と組み合わせることで、脅威検知イベントが作成された際に管理者に対してメールやアプリ内通知で知らせることもできます。このように、AIの力を借りることでシステム管理者が蓄積されたログを逐一分析することなく、組織に対する脅威を確認する手助けを行ってくれます。設定は簡単ですので、ログを分析できる要員がいない組織でも有効な機能です。脅威検知機能にて検知できる機能は以下の4種類です。クレデンシャルスタッフィングクレデンシャルスタッフィングは、盗取したログイン情報を使用する一種のサイバー攻撃です。「パスワードスプレー」「クレデンシャル漏洩」ともいいます。攻撃者は、脆弱なウェブサービスに対するサイバー攻撃や、過去に流出した情報などから大量のユーザ名とパスワードを取得します。そして、取得したログイン情報を使用して、Salesforce などの Web アプリケーションに大規模な自動ログイン要求を仕掛け、ログイン出来るアカウントがないかどうか調査します。もし万が一ユーザ名とパスワードを使いまわしているユーザがいた場合、ユーザアカウントに不正にアクセスされてしまいます。セッションハイジャックセッションハイジャックは、ログイン中のユーザのセッションを乗っ取り、そのユーザに成りすましてアクセスを行う攻撃です。通常ウェブページにおいてログイン処理が正常に行われると、ユーザのクライアントはセッショントークンを受け取り、次回以降ログイン後の状態でアクセスが出来ます。攻撃者はそのセッショントークンを窃取して、クライアントのセッションを乗っ取ろうとします。万が一セッションが乗っ取られた場合、攻撃者はトークンを窃取されたユーザに成りすましてウェブページへアクセス出来るため、ログイン後にしかアクセスできないような機密情報にアクセス出来てしまう可能性があります。(注意) イベントモニタリングライセンスの有無にかかわらず、Salesforceのすべてのお客様はクレデンシャルスタッフィングおよびセッションハイジャックが発生した場合に、影響を受けたユーザに対してセッションの切断やID 検証、強制パスワード変更といった軽減措置が実施されます。ただし、これらの軽減措置はシステムによって自動で実行されるものであり、対象組織の管理者はその措置が発動されたかどうかを確認することは通常出来ません。イベントモニタリングの脅威検知機能により、これらの不正なアクティビティがイベントログとして記録されるため、お客様の組織に対して不正なアクセスがあったことを表面化させる(認知する)ことができ、システム管理者がその内容を確認することが出来るようになります。レポートの異常過去90日分のユーザのレポート生成とその周辺アクティビティの傾向を元に、ユーザーが普段とは異なる傾向でレポートを実行またはエクスポートしたかどうかを調査します。もしユーザのレポートアクティビティが普段とは異なる傾向であった場合、脅威検知イベントとしてその内容がログとして記録されます。システム管理者は生成されたログにより組織内の異常な行動について感知することができ、ログ内容を確認することで検知された行動が本当に悪意のあるものであったかどうかを確認していくことができます。API 異常レポートの異常と同じく、過去90日分のユーザのAPI生成とその周辺アクティビティの傾向を元に、ユーザーが普段とは異なる傾向でAPIを利用していないかどうかを調査します。脅威検知アプリケーションの設定方法脅威検知機能には、アプリケーションランチャーからアクセスができる専用のアプリケーションが用意されています。この脅威検知アプリケーションにアクセスし、組織内で発生した脅威検知イベントを確認するためには、以下の手順を実施して管理ユーザに表示できるようにしておく必要があります。イベントマネージャを使用して、4種類の脅威検知イベント (CredentialStuffingEvent, SessionHijackingEvent, ReportAnomalyEvent, ApiAnomalyEvent) のストリーミングとストレージを有効にします。詳細な手順はこちらの記事をご確認ください。Salesforce ライセンスに関連付けられた権限セットを作成します。権限セットについてはこちらの記事をご確認ください。権限セットの [システム権限] ページを編集し、[脅威検知イベントを表示] 権限を有効にします脅威検知アプリケーションを管理するユーザにこの権限セットを割り当てます。脅威検知アプリケーションを使用する各ユーザプロファイルの [タブの設定] を編集し、5 つのタブの表示を指定します。5 つのタブは、[セッションハイジャックイベントストア]、[クレデンシャルスタッフィングイベントストア]、[レポート異常イベントストア]、[API 異常イベントストア]、[脅威検知フィードバック] です。たとえば、システム管理者は通常 UI を使ってあらゆる機能にアクセスするため、システム管理者プロファイルでは 5 つのすべてのタブの表示を [デフォルトで表示] に設定します。脅威検知管理者プロファイルを作成した場合も、同じ表示を設定します。標準ユーザがフィードバックを表示できないようにする場合は、標準ユーザプロファイルの [脅威検知フィードバック] の表示を [タブを隠す] に設定します。[設定] で、[クイック検索] ボックスに「アプリケーションマネージャ」と入力し、Lightning Experience アプリケーションマネージャに移動します。脅威検知アプリケーションの右側にあるドロップダウンボックスで [編集] を選択し、このアプリケーションを編集します。もし [タブの選択] セクションに手順.5で設定した 5 つのタブが含まれていない場合は、適宜 [選択されたタブ] へ移動させます。[プロファイルへの割り当て] セクションで、脅威検知アプリケーションを表示可能にするプロファイルを選択し、設定を保存します。トランザクションセキュリティによる管理者への通知設定イベントモニタリングに含まれる「トランザクションセキュリティ」機能を利用し、脅威検知イベントを対象としたトランザクションセキュリティポリシーを作成することによって、新たに脅威検知イベントが生成された際に管理者に対してメールやアプリ内通知によってアラートをあげることができます。これにより、管理者は脅威検知アプリケーションの内容を確認し、新たな脅威が発生していないか定期的に確認する必要がなくなります。以下の例では、セッションハイジャックイベントが生成された際に、管理者に対してメール通知およびアプリケーション内通知を行うポリシーを条件ビルダーを用いて作成します。[設定] で、[クイック検索] ボックスに「トランザクション」と入力し、トランザクションセキュリティポリシーに移動します。(初回のみ) トランザクションセキュリティ画面の [有効化] ボタンをクリックします。新しくトランザクションセキュリティポリシーを作成するため、[新規] ボタンをクリックします。GUI操作でポリシーを作成していく場合は [条件ビルダー] を、予めトランザクションセキュリティ用に作成したApexクラスを指定する場合は [Apex] を選択します。(今回は条件ビルダーでの作成方法で解説します)ポリシー作成画面より、以下の条件を設定し、[次へ] をクリックします。[行動]:セッションハイジャックイベントストア[条件ロジック]:すべての条件に一致 (AND)※今回、設定する条件は1つのみなのでロジックどれでもOKです[条件]: “スコア” >= “0”アクション設定画面にて、以下の条件を設定し、[完了] をクリックします。[アクション]:なし[通知]:メール内通知・アプリケーション内通知のチェックをON[受信者]: 脅威検知イベントの通知を受け取る管理者を指定[名前]:Session Hijacking Trigger Alert※作成したポリシーの内容が分かる名前を任意につけてください[状況]: 有効ポリシーが有効な状態で、脅威検知機能により新たにセッションハイジャックイベントが生成された際には、以下のようなメール通知・アプリケーション内通知が指定された管理者に対して送信されます。各々のイベントが発生した場合、前述の通りクレデンシャルスタッフィングおよびセッションハイジャックについては既にシステムによって自動で対処は完了していますが、再度同様の攻撃を受け続けないためにも、該当ユーザに対して使いまわしているパスワードがないかどうかのヒアリングや、利用端末に対するウイルスチェックの実施などを行うことで、根治対処を行うことも重要となります。同様に、レポートの異常やAPI 異常についても該当ユーザへのオペレーション内容の確認やイベントモニタリングで生成されたログの確認を行うことで本当に脅威となるアクティビティであったかどうか確認を実施します。これらの調査については、以下のヘルプページが用意されておりますので合わせてご参照ください。セッションハイジャックの調査クレデンシャルスタッフィングの調査レポートの異常の調査API 要求の異常の調査機械学習アルゴリズムへのフィードバック脅威検出イベントが生成された後は、その検知内容が適切であったかどうか管理者によって機械学習アルゴリズムに対してフィードバックを送信することができます。不正なアクセスを正しく検知できていた(正検知)という場合と、通常の業務内容などによって発生した検知であり、不正なアクセスではなかった(誤検知)という場合の両方のケース対して送信が可能になっており、こまめにフィードバックを行うことで脅威検出機能の検知精度を高めることができます。詳細はこちらのヘルプをご確認ください。フィードバックを送信したい、誤検知となった脅威検出イベントへアクセスし、右上の [Provide Feedback] をクリックします。指定した脅威検出イベントの内容について Malicious(悪意あり)、Suspicious(疑わしい)、Not a Threat(脅威ではない)、Unknown(不明)の4つから選択し、保存ボタンを押してください。学習ツールHelp - 脅威検知Help - 脅威検知イベントの表示とフィードバックの提供Help - 拡張トランザクションセキュリティTrailhead - 拡張トランザクションセキュリティまとめ脅威検知機能により、Salesforce組織に発生した脅威を顕在化させることができ、組織の管理者はこれらに気付くことで追加の対応や対策を検討するきっかけを得ることが出来るようになります。ただし、本機能の活用に当たってはログの有効化やトランザクションセキュリティポリシーの活用など、いくつか事前に準備を行っておくことが重要となりますので、本記事をきっかけに対応を進めていただけると幸いです。
-
この記事で学べること適切なお問い合わせ先を知ることができますお問い合わせの回答を早くもらうために知っておくべきポイントを把握できますお問い合わせ先Salesforceを使っていると、色々わからないことや相談したいことが出てくると思います。そんな時に誰に相談しますか?「弊社営業担当者に聞いてみる」というのも一つの方法ではありますが、次回のミーティングまで待っているのは時間が勿体無いです!以下に、質問内容に合わせたお問い合わせ先を纏めました。[お問い合わせ先]列のリンクをクリックすると、具体的なお問い合せ方法を確認することができますご質問内容お問い合わせ先・設定方法がわからない・エラーの解消方法を知りたいテクニカルサポートにお問い合わせください。https://www.youtube.com/embed/5pG3bH-LuU0一部、お問い合わせ窓口が異なる製品がございます。ナレッジ「Salesforce カスタマーサポートへの問い合わせ」の[他製品のお問い合わせ窓口] 欄をご覧ください。例:Heroku/Mulesoft/Tableau/Slack - Support for Slack App/Social Studio/Marketing Cloud Intelligence (旧称Datorama)開発者サポートについては以下をご参考ください。Premier、Premier Plus、および Signature Success: 開発者サポート・メンテナンスや障害情報について知りたいTrustサイト をご参考ください。※不明点などある場合は、Salesforce テクニカルサポートにご連絡ください。・他の企業での対応方法や活用アイデアを知りたい・具体的な質問ではないけど、誰かに相談したいTrailblazer Communityにご相談ください・契約内容について確認、相談したい・社名変更があった・新たな製品に興味がある・ライセンスや請求に関するご相談弊社営業担当者までご連絡ください・Trailheadについてのご質問Trailhead のアカウント等については Trailhead Help より「Trailhead」を選択してお問い合わせください。個別の Trailhead モジュールのハンズオン Challenge に関する内容はTrailblazer Community を利用してください。日本語のグループ: Japan Trailhead (日本)Japan Trailhead (日本) ・エキスパートコーチング (アクセラレータ)に関するご相談ヘルプ&トレーニングでのお申込み手順をご確認ください。・Salesforceの認定資格、トレーニングに関するご相談jtraining@salesforce.com へメールにて連絡してください。・AppExchangeからインストールしたパッケージに関するご相談パッケージの開発元のベンダー様窓口をご確認ください。※判断が難しい場合は、Salesforceテクニカルサポートにご相談ください。・パートナーとしての製品お問い合わせ細則がございますので、資料をご確認ください。JP Partner Case Submission Manualここからは、テクニカルサポートへお問い合わせをする時のポイントについてご紹介します。テクニカルサポートへお問い合わせをする時のポイントSalesforceでは、複数のチーム(テクニカルサポートや開発部門)が協力して、お客様からのお問い合わせに対応しています。お客様の疑問点や問題を早期に解決するためには、お客様のご協力も必要です。以下は、テクニカルサポートへお問い合わせをいただいてからお客様へ回答をお届けするまでの一般的な流れになります。※図をダブルクリックすると、大きな図をご覧いただけます以下に、早期解決のためのポイントを纏めています。問題の切り分けシステム管理者の皆様は、現場の方からの様々なお問い合わせを受けてらっしゃると思います(上図の①)また、別システムと連携をしている場合などは、システム側から障害通知を受け取ることもあるでしょう(上図の②)設定変更に関する疑問や、仕様の確認が必要なこともあるでしょう(上図の③)このように、様々なお問い合わせがあると思いますが、サポートへお問い合わせをする前に確認いただきたいポイントがあります。発生している問題は、お客様が開発したカスタムコードによるものか?この場合、まずは開発者様へお問い合わせをお願いしますAppExchangeからインストールしたパッケージに関するものか?パッケージの開発元へお問い合わせをお願いします※判断できない場合は、テクニカルサポートへご相談可能ですテクニカルサポートへお問い合わせする際、必要な情報1. お問い合わせ内容を伝えますお問合せ内容の詳細に加えて業務影響やお客様環境へのログインアクセス許可をあわせてご連絡いただく事で、貴社における問題の緊急度をサポート部門、開発部門と円滑に共有する事ができます。発生事象事象の詳細説明・本当はどうなるはずで、現在どういう状況ですか・事象が発生している組織IDとユーザ名を教えてください発生日時事象が発生した日時・現在も発生している場合は、最初に発生した日時を教えてください・できるだけ細かい単位(日付のみではなくできれば時間まで)教えてください再現手順事象を意図的に発生させるための操作方法・サポートエンジニアがこの操作方法を実行して調査を行います・ログイン後の画面からの具体的な操作方を教えてくださいスクリーンショット事象発生時のスクリーンショット・再現手順で再現しない場合に、スクリーンショットを元に調査を行います各種ログデバッグログなどを取得できる場合は、そのログを添付してください2. 業務影響を伝えます業務停止有無 どのような業務(アプリケーション)に、どのように影響していますか?ユーザ数 何名ほどのユーザが影響を受けていますか? 回避有無 回避策はありますか。ある場合はどのような方法ですか? 3. 希望する解決期限を伝えます問題の複雑さ・難易度によって回答のスピードは異なります。期限までの回答を保証するものではありませんが、お客様の状況を鑑みてベストエフォートにて調査を行います。回答希望日いつまでの回答を希望しますか?理由その期限までに回答が必要な理由を教えてください期限を超えた場合の影響その期限を超えた場合にどのような業務影響がありますか?4. 可能な場合、ログインアクセス許可を設定しますログインアクセス許可付与の有無ログインアクセス許可を付与した場合はその旨を明記します組織IDログインアクセス許可を設定した組織IDを教えてくださいユーザ名ログインアクセス許可を設定したユーザ名を明記します。・特定ユーザのみで事象が発生している場合、そのユーザとシステム管理者両方のログインアクセス許可が設定されていると、調査はスムーズに進みますログインアクセス許可の設定方法は「ログインアクセスの許可」を参照してください5. お問い合わせの重要度を設定しますテクニカルサポートへのお問い合わせは、発生している問題の重要度によって分類されます。重要度についてはお問い合わせの重要度についての説明(ナレッジ)をご確認ください。その他パスコードプレミアのお客様には、会社毎にパスコードが発行されています。プレミアのお客様がお電話でお問い合わせする時に入力が必要になりますので、お手元にパスコードのご用意の上、お電話をお願いします。指定連絡先(Designated Contact)「指定連絡先(DC)」という言葉を聞いたことありますか?(「なぜ突然指定連絡先の話が出てきたのか?」と疑問に感じるかもしれません)その答えは、「指定連絡先(DC)」はサポートへお問い合わせをしたり、各種プレミアサービスをご依頼いただく権限を持っている方です。お問い合わせの調査をする際、お客様組織の設定や使用状況などについてヒアリングをさせていただく場合があります。そのためには、Salesforceに関する知識およびお客様組織の環境設定について十分な知識をお持ちであるシステム管理者とのやり取りが不可欠です。その点で、「指定連絡先(DC)」はSalesforce や組織の環境について十分な知識をお持ちのため、適任です。「指定連絡先(DC)」以外のお客様からのご質問の場合、調査に必要な権限や情報が不足しているために、社内のシステム管理者へお問い合わせいただくようにとの回答になる場合がございます。(時間が勿体ないですね!)このように、Salesforceをご利用いただくには、組織に最低1名の「主指定連絡先(プライマリDC)」の登録が必要です。(「主」ということから分かる通り、組織には複数の「指定連絡先(DC)」を設定することができます)「主指定連絡先(プライマリDC)」については、ご契約時に、弊社営業からの指定にて、あらかじめ主管のシステム管理者様をプライマリDCに設定させていただいております。お心当たりのない場合は、ご自身が「指定連絡先(DC)」になっているかを確認してくださいご自身が「指定連絡先(DC)」か「主指定連絡先(プライマリDC)」かを確認する際は、Salesforceヘルプの指定先と管理(ナレッジ)をご確認くださいSalesforce に問い合わせできる方を指定連絡先(DC)のみに限定したい一般ユーザー(Salesforce の管理をされている方以外)の方は Salesforce へ問い合わせるのではなく、自社のヘルプデスクに問い合わせる運用をされていませんか?プレミア(およびシグネチャー)をご契約いただいている組織では「指定連絡先(DC)」のみヘルプ&トレーニングサイトからケースを起票できるように制限することが可能です。制限した場合、指定連絡先(DC)以外の方が「お問い合わせを作成」ボタンを押下すると、「ヘルプデスクへお問い合わせください」のテキストメッセージが表示されてケースが作成されません。製品単位の制限はできません。(例えば、Sales cloud は制限する、Marketing cloud は制限しないという設定はできません。)表示するテキストメッセージは任意の文字を設定可能です。(最大 120 文字程度)本設定を希望される場合には、 主指定連絡先(プライマリDC)またはシステム管理者からテクニカルサポートへご依頼ください。(変更には主指定連絡先(プライマリDC)またはシステム管理者の承認が必要です。)サポートマネージャへのケースエスカレーションエスカレーションは、コールセンターではよく使われる言葉で、現在の担当者での対応が難しい場合に上位エンジニアやマネージャーに対応を交代することです。過去にサポートへお問い合わせいただいた経験のあるお客様は、お問い合わせ詳細画面に「ヘルプが必要」ボタンが表示されているのを見たことがあるかもしれません。Salesforceでは、現在対応中のお問い合わせの対応について、当社がお客様の期待にお応えできなかった場合、テクニカルサポートマネージャーへのケースのエスカレーションの手順で上位者へエスカレーションしていただく事ができます。「ヘルプが必要」ボタンは、Success Plan およびお問い合わせの重要度に応じて、お問い合わせが作成されてから一定の時間が経過してから表示されます。お客様からのエスカレーションが不要なよう努めて参りますが、場合によってご活用いただければと存じます。学習ツールお問い合わせクイックリファレンス(ナレッジ)コミュニティを通じてSalesforce活用のヒントを得る(サクセスナビ)Salesforceヘルプの指定先と管理(ナレッジ)テクニカルサポートマネージャーへのケースのエスカレーション(ナレッジ)まとめ(チェックリスト)営業担当者以外の問い合わせ/相談先があることを理解しました問い合わせを作成する時に必要な情報を理解しました自分が組織の「指定連絡先(DC)」であるかの確認しました
-
この記事で学べることデータセット作成の手順この記事のゴールデータセットの作成完了データセットとはCRM Analyticsではダッシュボードを作成する場合に、まずはダッシュボードに表示するデータが必要です。この元となるデータの塊を 「データセット」と呼びます。データセットは行と列を持つデータで、ダッシュボードで見たいデータに応じて、必要なレコードと項目を選別してデータセットを作成します。データセットは以下2つの方法で作成が可能です。・レシピを利用してデータセットを作成する・csvデータをアップロードして作成する今回はレシピを利用して、Salesforceのデータを使ったデータセットの作成方法をご紹介します。csvをアップロードしてデータセットを作成する方法はCRM Analytics ドリル:CSVファイルの取り込み方法を参照ください。データセットの作成手順では、Salesforceのデータを使ってデータセットを作ってみましょう。手順は以下の2つのステップです。データを接続するレシピを利用して、データセットを作成する手順を追って設定しましょうデータを接続するまず、Salesforceの環境のデータをAnalytics環境へ持ってくる接続の設定です。Analytics Studioを開き、左のタブにある [ データマネージャ ] を開きます。 [ 接続 ] を選択し、 [ SFDC_LOCAL ] の▼をクリックし、 [ オブジェクトを編集 ] をクリックします。ダッシュボードで利用したいオブジェクトと項目をチェックし、 [ 保存 ] します。必要なオブジェクトの保存が完了したら、 [ SFDC_LOCAL ] の▼をクリックし、 [ 今すぐ実行 ] をクリックします。これにより接続したオブジェクトのデータをAnalyticsの環境に同期します。このままでは、 [ 今すぐ実行 ] を押した時点のデータを同期し、その後データ更新されません。今後も定期的にデータをSalesforce環境からAnalytics環境に同期される様にするため、データ接続の同期スケジュールを設定します。 [ SFDC_LOCAL ] の▼をクリックし、 [ スケジュール ] をクリックします。以下の画面が表示されるため、データを同期する感覚をスケジュール指定します。例)画像は月〜金のAM7:00にデータ同期を行う設定です。これでSalesforceの環境からデータをAnalytics環境へ持ってくることができました。レシピを利用して、データセットを作成する続いてAnalytics環境に接続したデータから、ダッシュボードで使うためのデータセットを作成します。今回は取引先情報を付与した商談データセットを作成してみましょう。補足:レシピとはレシピは、データに対して様々な加工を指定し、最終的にデータを出力できる機能です。レシピ上で、入力データを指定し、そのデータに対して、どの順番でどの様に加工を行うという一連の流れを指定できます。レシピにデータを追加Analytics Studioを開き、左に表示される [ データマネージャ ] ボタンをクリックします。 [ レシピ ] をクリックし、 [ 新規レシピ ] をクリックします。画面中央の [ 入力データを追加 ] から、 [ Opportunity(商談) ] をチェックし、必要な項目を指定します。ポイント:今回は取引先情報を含む商談のデータを作成します。そのため、商談1行がデータセットの1行にあたりるため、 [ Account(取引先) ] ではなく、 [ Opportunity(商談) ] をチェックします。 [ 関連オブジェクト ] のタブを選択し、 [ Account(取引先) ] の右の [ +結合 ] を選択して [ 次へ ] を選択します。取引先データを付与した商談データの設定がレシピ上に出力されました。レシピの [ 結合 ] の機能を使い、商談データのAccountIDに対して、取引先データのIDでマッチングをかけ、商談に対して取引先名などの取引先情報を項目として追加している設定が自動で設定されました。データに取引先のデータが含まれているかはプレビューで確認できます。レシピからデータセットを出力ではデータの加工が終わったので、データをデータセットで出力する設定を追加します。 [ 結合0 ] の [ + ] をクリックし、 [ 出力 ] をクリックします。出力の設定画面が出力されるため、以下を指定し、 [ 適用 ] をクリックします。 [ データセットの表示ラベル ] :データセットの表示名称を指定します。データセットAPI参照名 :データセットの一意の名前です。既存のデータセットの名称と重複すると既存のデータが上書きされるので注意ください。アプリケーションの場所 :データセットをどのアプリケーションに出力するかを指定ください。 [ 保存して実行 ] をクリックし、レシピの名称を指定して [ 保存 ] をクリックします。レシピのデータ加工内容が保存され、データセット作成処理が実行されます。データマネージャ画面にもどり、 [ ジョブ監視 ] をクリックして、データセット作成の進捗を確認します。作成時にエラーがある発生した場合、エラー等が出力されます。レシピをスケジューリングレシピを使って作ったデータセットはレシピを実行した時点のデータでデータが作られています。データ接続と同じ様にレシピもスケジュール設定をすることで、データが自動的に更新されるよう設定します。 [ データマネージャ ] の [ レシピ ] をクリックし、スケジューリングするレシピの▼をクリックします。 [ スケジュール ] をクリックします。スケジュールを曜日と時間ベースに設定することもできますが、今回は [ イベントベース ] のタブをクリックします。 [ Salesforce ローカル接続が同期されます。 ] を選択します。イベントベースは指定のイベントが実施されたら連動して実行するという設定が可能です。表記の設定にすることで、Salesforceローカル接続とデータが同期されたら、指定のレシピも再実行されるという設定となります。これが、基本的なデータセット作成の手順となります。同様に所有者のユーザ情報を紐づける方法は、CRM Analytics ドリル:ユーザ情報を紐付けるを参照ください。より詳しい設定の内容は以下の参考情報から学習を進めていきましょう。学習ツールレシピの操作やより詳しい設定方法を知りたい方には、以下のコンテンツがおすすめです。レシピの「基本」から、実践的なユースケースに沿った設定方法が詰まっております。ぜひ参照いただきレシピをマスターしましょう。CRM Analytics ドリル作るとわかる!CRM Analytics レシピ エキスパートコーチング「レシピを使ったデータ準備」(個別セッション)PremierまたはSignature Success Planをご契約のお客様はSalesforceエキスパートとの1 対 1 のセッションにてレシピでのデータ作成方法の基礎を学ぶ事ができます。セッションの詳細はリンク先の概要をご確認ください。まとめこちらの記事ではデータセット作成の以下の基本的な操作方法をご理解いただきました。データを接続するレシピを利用して、データセットを作成するデータセットを作成することで、データセットは何かというイメージがついたのではないでしょうか。では続いてデータセット作成時のポイントをご紹介します。活用ステップ全体に戻る場合は、こちら
-
Tableauをご利用いただき(もしくはご検討いただき)ありがとうございます!この記事では、Tableauの埋め込み分析 (Embedded Analytics) に関して、費用面と技術面の概要を解説させていただきます。記事の執筆時点から内容に変更がある可能性もございますので、詳細な最新情報はこちらから営業担当までお問い合わせいただき、この記事はあくまでも参考情報としてご確認いただけますと幸いです。また、全体を通してTableau Cloudのご利用を前提とした内容になっております。Tableau Serverの場合も基本的な概要は同じですが、一部異なる部分もありますので、詳細は営業担当までお問い合わせください。はじめに早速ですが、Tableauで作成したダッシュボードは、Webアプリに埋め込むことができ、エンドユーザーにTableauのパワフルなビジュアルアナリティクスの機能を提供することができます。Tableauの公式サイトでも埋め込み分析についての紹介がありますので、まずはこちらをご覧ください。Tableau 埋め込み分析 顧客にデータで価値を提供する埋め込み分析なお、埋め込み分析は登場人物が多いため、Tableauをご契約いただく「Tableauにとってのお客様」をX社とし、X社が提供するWebアプリを使用する「X社にとってのお客様」をA社、B社、C社...(またはエンドユーザー)とさせていただきます。1. 費用面の概要Tableauの埋め込み分析を提供するために、まずX社がエンドユーザーの分も含めてTableauのライセンスを契約する必要があります。そのパターンは大きく分けて以下の3つが挙げられます。ユーザーライセンス使用量ベースのライセンス(Tableau Cloudのみ)コアライセンス(Tableau Serverのみ)1-1. ユーザーライセンスユーザーライセンスは、Tableauのダッシュボードを利用する人数分だけライセンスが必要になります。なお、エンドユーザーに付与できるライセンスはダッシュボードを編集できるExplorerと、ダッシュボードを閲覧できるViewerの二種類で、データソースの準備から行うことができる最上位のCreatorは付与することができません。たとえば、Tableauのダッシュボードを編集するエンドユーザーが100人、閲覧するエンドユーザーが1000人いる場合は、シンプルにExploere×100、Viewer×1000のライセンスを、X社が契約する必要があります。1-2. 使用量ベースのライセンス使用量ベースのライセンスは、ユーザーではなく使用量に基づいた新しいライセンスモデルです。エンドユーザーがダッシュボードを閲覧するなどの特定のアクションを実行すると、あらかじめ購入していた「分析インプレッション」のプールが消費されていくという形になっています。たとえば携帯電話のデータ通信の料金プランで、月額3,000円で20GBまで通信でき、20GBを超えてしまったら追加購入が必要になるというプランがよくあると思いますが、そのイメージに近いかもしれません。エンドユーザーのアクセス頻度が低い場合、ユーザーライセンスよりも使用量ベースのライセンスの方が投資対効果を得やすいと考えられます。使用量ベースのライセンスについては、こちらのブログ記事もご参照ください。1-3. コアライセンスコアライセンスは、Tableau Serverのみで提供しているライセンスモデルです。Tableau ServerはX社自身でTableauのプラットフォームを構築/運用いただくことになりますが、コアライセンスはそのTableau Serverのコア数に基づいて費用が発生します。この場合ユーザー数は無制限になりますので、たとえばX社のWebアプリ上のTableauによる分析機能をD社が新たにトライアルで利用したいといった場合に、追加コストなしでユーザーを追加することができます。しかし、Tableau Serverのコア数に対してユーザー数(厳密には同時アクセス数)が多すぎると、スペック不足になってしまう恐れもあるため、必要なコア数を慎重に見積もる必要があります。2. 技術面の概要TableauのダッシュボードをX社のWebアプリに埋め込むためには、主に以下の3つを考慮しながら、X社側で開発する必要があります。ダッシュボードを埋め込む方法WebアプリとTableauの認証の連携(シングルサインオン)エンドユーザーのデータをセキュアに管理する方法2-1. 埋め込む方法TableauのダッシュボードをTableau Cloudにパブリッシュすると、URLを取得することができます。このURLを以下のAPIで呼び出すことで、Webアプリにダッシュボードを埋め込みます。Tableau Embedding API v3埋め込むだけでなく、“Tableau”と記載されたツールバーを非表示にしたり、Webアプリのボタンからダッシュボードにフィルターをかけるような連携をさせたりすることもできます。また、REST APIも利用することで、Webアプリにログインしているユーザーが利用できるTableauのダッシュボードの一覧を、サムネイル化して並べて表示するようなことも可能です。※無料のTableau Publicを埋め込む場合、“Tableau”の記載があるツールバーを非表示にすることはできません。以下のアニメーションでは、エンドユーザーがWebアプリにサインイン後、ダッシュボードのサムネイル一覧から見たいダッシュボードをクリックして表示し、Webアプリ側のフィルターボタンでダッシュボードに表示される地域をUSに絞っています。ダッシュボード自体はTableauで作成したものをAPIで呼び出しており、ダッシュボード以外の部分はWebアプリ側で実装しています。どのようなコードを書けばいいのかについては、Tableau Embedding Playgroundも参考にしてみてください。※2023年5月時点で上記のPlaygroundは正式リリース前のDeveloper Previewとなっております(参考Twitter)2-2. WebアプリとTableauの認証の連携(シングルサインオン)認証を連携せずにTableauのダッシュボードをWebアプリに埋め込んだ場合、ユーザーがWebアプリにサインインしてTableauのダッシュボードが埋め込まれた画面を開くと、Tableauのサインイン画面が表示されてしまいます。これでは二度手間となり、ユーザーフレンドリーではない体験になってしまうため、基本的にはシングルサインオン(SSO)できるように開発する必要があると言えます。SSOを実現する方法は主に以下の二つが挙げられます。外部のIDプロバイダー (IdP) を利用する(詳細はこちら)Connected Apps(接続済みアプリ)Connected Appsの場合は外部のIdPが不要で、WebアプリとTableauをJSON Web Token (JWT)の連携によって認証します。いずれの場合も、Tableauのダッシュボードを閲覧する人は、Tableau側にユーザーとして登録されている必要があります。Tableau側のユーザー登録は、Tableau Cloudの管理画面から以下のようなGUIで登録できます。また、CSVファイルのインポートや、REST APIでも登録できます。REST APIで自動化する場合はX社側での開発が必要になります。※REST APIのライブラリはこちら(Python)なお、Tableau Cloudの場合、多要素認証(MFA)が必須となっていますが、2023年5月時点では、埋め込み分析の場合はMFAを免除可能となっております。詳細はこちらのFAQの「MFA 要件が免除されているユースケースを自動有効化や適用からどのように除外できますか?」をご確認いただき、営業担当までお問い合わせください。2-3. エンドユーザーのデータをセキュアに管理する方法X社がWebアプリに埋め込んだTableauのダッシュボードをA社、B社、C社に展開する際、誤ってA社が他社のデータを閲覧できてしまうと、大問題になってしまいます。そのような事態を防ぐために、Tableau上で各社のデータを適切に出し分ける方法は主に以下の二つが挙げられます。各社のデータやダッシュボードをプロジェクト単位で分割して個別管理各社のデータやダッシュボードを分割せずに行レベルセキュリティで動的に表示を切り替える各社のデータやダッシュボードをプロジェクト単位で分割して個別管理Tableau Cloudでは、プロジェクトと呼ばれるフォルダのようなものを自由に構成でき、その中にワークブックやデータソースを格納することができます。このプロジェクトを各社ごとに作成し、その中に各社のワークブックやデータソースを格納することで、ワークブックやデータソースを各社ごとに分けて管理することができます。また、各プロジェクトごとに誰がアクセスできるようにするかパーミッションを設定することも可能です。参考:プロジェクト管理画面のUIこの場合、ダッシュボードのデザインが同じであってもURLは各社ごとに異なるため、A社のユーザーならA社のURL、B社のユーザーならB社のURL、C社のユーザーならC社のURL、という形でURLを出し分けるようにWebアプリ側で実装いただく必要があります。また、例えばエンドユーザーの企業数が100社を超えるような規模になってくると、ワークブックやデータソースを100社分用意したり、ダッシュボードの更新時に100社分のワークブックを更新したりすることになり、手作業では限界があります。REST APIのPublish WorkbookやUpdate Workbook Connectionなどを利用して開発すれば、ワークブックやデータソースの複製および接続先の変更を自動化できる可能性もありますが、X社がご利用中のDBやその構成によっては実現が難しい場合もありますので、事前の検証をお願いします。特に接続先の変更については、APIで実現できない場合、ワークブックやデータソースのファイル自体のXMLを直接修正するという方法もありますが、サポート対象外になりますので、自己責任で実施いただく必要があります。※REST APIのライブラリはこちら(Python)各社のデータやダッシュボードを分割せずに行レベルセキュリティで動的に表示を切り替える行レベルセキュリティでは、同じダッシュボードをA社のユーザーが見るとA社のデータのみが表示され、B社のユーザーが見るとB社のデータのみが表示され...ということが実現できます。設定方法はヘルプや解説動画をご参照ください。行レベルセキュリティの懸念点としては、すべてのエンドユーザー企業のデータを同じテーブルで保持するため、データ量が増大しパフォーマンスが悪化する可能性があります。パフォーマンスについては様々な要因が絡むため、実際の環境で検証いただくことを推奨いたします。おわりに以上がTableauの埋め込み分析 (Embedded Analytics) に関する費用面と技術面の概要となります。繰り返しになりますが、技術面については各種APIを使用するため、X社側での開発が必要になります。開発支援を行うTableauのプロフェッショナルサービスやパートナー企業をご紹介することも可能です。その点も含めて、より詳細な内容や最新情報については、こちらから営業担当までお問い合わせください。最後までお読みいただきありがとうございました。引き続きTableauのご利用もしくはご検討のほど、よろしくお願い致します。