“ダッシュボード”の検索結果
- すべて
- おすすめリソース紹介
-
Sales
Cloud - Account Engagement(旧 Pardot)
-
Service
Cloud - Experience Cloud
- CRM Analytics
- Quip
- Engagement
- Intelligence
-
Commerce
Cloud - Tableau
- Sales Program
- MuleSoft
- Trusted Services
- Slack
- Data Cloud
- AI(人工知能)
- Digital Wallet(利用量の管理)
-
セキュリティ・
開発・運用 -
ユーザグループ・
コミュニティ - Premier Success Plan
- コーポレートサイト
- 特集
-
(2023年11月) Salesforceの運用に関する重要なお知らせ
この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート動画で更新内容を学ぶhttps://play.vidyard.com/376fAEBj9VvX8Qxs6i5EXd全ての資料をダウンロードして学ぶダウンロードはこちら記事で更新内容を学ぶ本記事は「Salesforceの運用に関するお知らせ」の11月号となります。こちらの記事では、メンテナンス情報や技術情報、セキュリティ関連情報の構成で、特に重要な更新情報をピックアップしてご紹介いたします。必要なアクションをお客様にいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。2023年11月のトピックはこちらになります。本記事では、前月との差分である赤字の部分についてと、特に重要な情報をピックアップしてご紹介します。まずは、Winter '24リリースノートの更新情報です。今月は10月16日以降の更新情報の抜粋です。先月まで、現行動作に影響を与える可能性がある更新をピックアップしていましたが、今月から資料に「注目」欄を追加しました。こちらに「⚪︎」がついている情報は、Data Cloud や AI と言った 今 Salesforce が注力して開発を進めている機能です。ぜひご注目ください。プロンプトビルダーでパーソナライズされたセールスメールの生成 (パイロット)プロンプトビルダーで、パーソナライズされた営業メールを生成する機能のパイロット版に関するリリースノートが追加されました。プロンプトビルダーで生成 AI を使用して項目値を入力 (パイロット)プロンプトビルダーで、生成AIを使用して項目値を入力する機能のパイロット版に関するリリースノートが追加されました。REST API で Apex アクションの例外が発生した場合のロールバックの適用 (リリース更新)本リリース更新の強制適用時期が、Spring '24からSpring '25に延期されました。メールのサービス返信を使用した顧客ケースの迅速な解決 (正式リリース)Service Cloud Einsteinに含まれる機能で、今まではチャットのみ対応していた「サービス返信」の機能を、メールで利用可能になった旨のリリースノートが追加されました。Develop from Anywhere using Code Builder (Generally Available)コードビルダーの正式リリースに関するリリースノートが追加されました。コードビルダーは、Webブラウザーからアクセスできる 統合開発環境(IDE)です。APIのオプションをお持ちのProfessional Edition、もしくはEnterprise Edition 以上のご契約であれば、管理パッケージをインストールしてご利用いただけますので、ぜひお試しください。会話マイニングレポートの作成時にメールの会話を含める (正式リリース)日本では未提供ですが、サービスインテリジェンスのアドオンを持つService Cloudのお客様がご利用可能な機能である「Einstein 会話マイニング」で、Winter '24から、メールのやり取りを元にしたレポートの作成が正式リリースされました。今回のリリースノートの変更では、そのレポートの対象となるのはメール to ケースで作成されたケースのみであることが明記されました。Migrate to New Data Cloud Permission SetsData Cloud をご利用中のお客様向けの情報です。2023年11月6日から、既存の Data Cloud 標準権限セットの名称が変更され、接頭辞 "Legacy"が追加されました。また、それに伴い、2023年11月8日から、新しい標準権限セットが作成されています。両者の違いは、 新しい標準権限セットは、データ スペースを認識する機能のオブジェクトから"すべて表示"と"すべて変更"権限が削除されています。これにより、データ スペース内のデータ セキュリティの強化をサポートすることができます。Refine Access with Data Spaces Feature PermissionsData Cloud のセキュリティ・データ・スペースの強化に関するリリースノートを追加しました。Data Cloud のデータ スペース内のデータ セキュリティが強化されることで、CRMの アクセス コントロールとの整合性が向上し、すべてのアクセス方法にわたってデータ スペースのセキュリティが実施されます。Prepare for Google Chrome’s Phasing Out of Third-Party Cookies and Its Potential Impact to Open CTI入電対応をしているコールセンターで影響が出る可能性がある、Google社側の変更についてです。Google社 では、 Privacy Sandbox イニシアチブが進行中です。その影響で、 ご利用中のOpen CTI の実装に3rd Party Cookie が利用されている場合に、2024年1月以降影響が出る可能性がございます。11月16日に、本件に関するメールをシステム管理者様に送信しております。メールがお手元に届いている場合には、CTIベンダーへ影響有無の確認をお願いします。Use a Session Token Instead of a Cookie for Lightning Apps on Third-Party Sites開発者様向けの情報です。Lightning OutやSalesforceとOutlookのインテグレーションなど、Lightningアプリがサードパーティのコンテキストにある場合に、認証Cookieをセッショントークンに置き換えるための新しいセッション設定に関するリリースノートが追加されました。Create From Lookup ChangesWinter '24以降、クイックアクションが有効なコンポーネント等からURL遷移するためのファンクションを使用した際、デフォルトではモーダルが閉じられなくなりましたが、本動作は、Sandbox にのみ適用されることを明記しました。Find Answers to Business Questions with Data Cloud Reports今まで、Data Cloud のオブジェクトのレポートを作成することはできませんでしたが、Winter '24で正式リリースされた旨のリリースノートが追加されました。Highlight and Share Key Data Cloud Metrics in Dashboards今まで、Data Cloud のオブジェクトのダッシュボードを作成できませんでしたが、Winter '24で正式リリースされた旨のリリース ノートが追加されました。Connect to Your Data Cloud Instance Automatically During SetupData Cloudの設定に関する変更点です。Salesforce と Data Cloud インスタンス間の接続を手動で作成する必要がなくなったことに関するリリース ノートが追加追加されました。Find Solutions and Consultants Faster on AppExchange JapanAppExchange(日本版)のサイトで、ビジネスニーズや業種などの新しいフィルターオプションを利用可能になった旨のリリースノートが追加されました。Einstein を使用して AI が生成した簡潔な販売概要を取得 (ベータ)Einstein for Sales アドオンを持つ Unlimited Edition 以上の Sales Cloud をご契約のお客様で使うことができる「Einstein セールス概要」の機能を利用可能になる新しいタイムラインを記載しました。具体的には、取引先と商談の Einstein セールス概要は現在ベータ版を提供中、取引先責任者とリードのセールス概要は、Winter ’24 の後半で利用可能になる予定です。Hyperforce インスタンスでの拡張された利用状況総計値の使用プラットフォームイベントと変更イベントの公開や配信に関する拡張された利用状況総計値を、Hyperforce で利用可能であることを示すリリースノートが追加されました。Discover Hidden Insights on Reports with CRM Analytics2023年9月以前にCRM Analytics を有効にしていた場合、標準の Sales Cloud Einstein 権限セットのいずれかに割り当てられているユーザーは Einstein Discovery for Reports にアクセスできるようになりました。Enable ICU Locale Formats (Release Update)ICUロケール形式を有効化というリリース更新についてです。本リリース更新は、Spring '24で全ての組織に対してICUロケール形式が有効化される予定でしたが、Spring '24からSpring ’25 にかけて段階的に進められることになりました。(Spring ’25 のリリースを以て、全組織でのICUロケールの有効化は完了となります)ICUロケール形式の自動有効化の30日から60日前に、お客様へメールでアナウンスが送付される予定となっていますので、お手元に届きましたらご確認ください。また、[設定]画面にある[ユーザーインターフェース]から [Enable ICU locale formats as part of the scheduled rollout]の チェックボックスをオフにすることで、Spring ‘25まではICUロケールの適用を延期することが可能です。以上が、10月16日以降のリリースノート更新情報からの一部抜粋です。関連機能をご利用のお客様は上記リンクより詳細をご確認ください。また、すべての更新情報をご覧頂く場合は、更新情報一覧のリリースノート(英語版)をご覧ください。続いて多要素認証(MFA)に関する更新情報です。MFAに関する公開情報に「Salesforce 多要素認証に関する FAQ」と「多要素認証 (MFA) 適用ロードマップ」がございますが、この2つの公開情報について10月20日に更新が行われていますのでご紹介します。関連情報オンラインコミュニティSalesforce 多要素認証に関する FAQ 多要素認証 (MFA) 適用ロードマップサクセスナビ:MFA(多要素認証)設定設定マニュアルサクセスナビ:MFA特設ページ多要素認証が Salesforce によって自動有効化された後のアカウントのアクセス再取得 (Salesforce Platform 上に構築された製品)まずはMFAの自動有効化と強制適用のロードマップに関する更新情報です。Core Platform 製品につきましては、Spring '24のリリースまで自動有効化を実施して、Summer '24のリリースからは強制適用を段階的に実施する予定となっていましたが、非常に多くのお客様に MFA を導入いただいている現状を鑑みて、Core Platform 製品については 強制適用は実施しないこととなりました。今後は MFA を使用していないお客様組織については、組織内に表示されるメッセージ等でお知らせさせて頂く「通知モデル」へと移行する予定です。通知モデルの詳細については Spring'24 のリリースノートにて確認頂ける予定になっていますのでお待ち下さい。続いて、MFAのFAQに関する更新情報を4つご紹介致します。上記ページの1行目の更新ですが、こちらは Core Platform 製品における MFA 強制適用の予定がなくなった件です。続いて、2行目の更新ですが、MFAの適用免除に関するユースケースが説明されているセクションの名前が変更になったというものです。セクション内の記載自体には更新はございません。次に3行目の更新ですが、MFAの適用準備に関する情報がFAQに記載されていましたが、その情報が「MFA ロールアウトに成功するための変更管理」という別のページに纏められたことをお知らせしております。そして4行目の更新ですが、多要素認証と2要素認証の違いに関する情報が記載されていましたが、該当セクションが削除されたことをお知らせしております。続いて、インフラ強化に関する更新情報です。まずはインスタンスリフレッシュに関する更新情報です。11月5日と19日にインスタンスリフレッシュが計画されていましたが、実施済みとなっています。また、主に海外のお客様にご利用いただいているインスタンスですが、上記スライドに記載されている「NA」で始まるインスタンスにおいて、12月3日にインスタンスリフレッシュが予定されています。インスタンスリフレッシュに関する準備につきましては、解説動画をサクセスナビよりご視聴いただけますので、該当するお客様は内容をご確認いただけますようお願いします。関連リンクインスタンスリフレッシュメンテナンスインスタンスリフレッシュ、組織移行、継続的サイト切り替えって?インスタンスリフレッシュの概要と準備続いて許可すべきIPアドレスとドメインに関する更新情報です。このスライドでは3つの公開情報をご紹介していますが、2つ目にございますHyperforceに関する公開情報に更新がございますのでご紹介致します。こちらの公開ナレッジは10月20日に2つの更新が行われています。1つ目は、Hyperforce上でStreaming APIを利用する場合は、APIバージョンが37以降でなければならないという要件が追加されたというものになります。2つ目の更新なのですが、「一時的な既知の問題」というセクションにHyperforceでまだ利用できない機能/製品に関する情報が記載されており、いくつかの機能/製品についてHyperforceで利用可能となる時期が最新情報で更新されました。関連リンクSalesforceのIPアドレスとドメインで許可するHyperforce 上の Salesforce サービスへの中断しないアクセスを維持するSalesforce アプリケーションからのメールを受信できるようにする続いて、次期バージョンであるSpring ‘24で適用予定のリリース更新のご紹介です。リリース更新の変更箇所は2点です。ICUロケール形式の有効化について適用時期が変更となり、Spring '24からSpring '25の間に段階的に自動有効化されることとなりました。詳細は、機能の廃止セクションにてご紹介いたします。関連リンクWinter '24 リリースノートの更新情報組織のプロファイル設定を優先するために EmailSimple 呼び出し可能なアクションを有効化 (リリース更新)商談の暗黙的な子共有を保存しないことによる取引先共有の再適用の迅速化の実現 (リリース更新)ICU ロケール形式の有効化 (リリース更新)サクセスナビ : ICUロケール形式の有効化Visualforce JavaScript Remoting API の JsonAccess アノテーション検証の有効化 (リリース更新)Apex RestResponse ヘッダーの RFC 7230 に基づく検証の適用 (リリース更新)REST API で Apex アクションの例外が発生した場合のロールバックの適用 (リリース更新)こちらのリリース更新は特に変更ございません。それぞれのリリース更新の詳細説明については割愛させていただきますが、Spring'24でも複数のリリース更新が適用されるため、公開情報をご確認の上、適用に向けたご準備をお願い致します。関連リンクゲストユーザーによる承認申請の編集または削除の防止 (リリース更新)ナレッジの Lightning 記事エディターと記事のパーソナライズを有効化MFA の自動有効化の続行: お客様の組織に適用されるタイミングと方法の確認 (リリース更新)拡張ドメイン適用までの今後のロードマップについては、変更はございません。旧URLにアクセスした際のリダイレクトがWinter'25で停止となる旨を通知する製品コミュニケーションメールが12月4日に管理者様に送信されます。詳細は製品コミュニケーションメールの内容をご確認ください。関連リンク拡張ドメインの有効化とその準備拡張ドメインのスケジュールチェックリスト続いて、その他の更新です。こちらでは、「Salesforce からメールを送信するためのメールアドレスの検証」についてご紹介します。現在のSalesforce ではメールアドレスが未検証であるユーザは、Salesforce からメールが送信できない動作となっています。この動作はシングルサインオン、SSOをご利用中の組織には適用されていませんでしたが、Spring’24のリリースを以って、SSOをご利用中の組織にも本動作が適用される予定となっています。SSOを利用している、メール送信を行う必要がある、メールアドレスが検証されていない、この3つの条件を満たす場合には、メールアドレスの検証が必要になりますので、本件に関する対応をご計画ください。本件に関する詳細はサクセスナビ「Salesforce からメールを送信するためのメールアドレス検証」に情報を纏めておりますので、ご確認ください。リリースノートの更新でもご紹介しましたGoogle Chrome のサードパーティー Cookie の廃止が Open CTI に影響を与える可能性についての詳細です。お客様の Open CTI ソリューションが AppExchange パートナーによって提供または実装されている場合は、影響範囲について開発元へご相談ください。その他詳細については、リリースノートを併せてご確認ください。関連リンクGoogle Chrome のサードパーティー Cookie の廃止が Open CTI に影響を与える可能性続いて機能の廃止に関する情報です。JDKロケール形式はSpring '24で全ての組織に対してICUロケール形式が有効化される予定でしたが、Spring'25のリリースまでに段階的に廃止を進める予定に変更となりました。Spring '24からICUロケール形式の有効化が段階的に進められ、Spring ’25 のリリースを以て、全組織でのICUロケールの有効化は完了となります。ICUロケール形式の自動有効化の30日から60日前にお客様へメールでアナウンスが送付されますのでご確認ください。また、[設定]にある[ユーザーインターフェース]から [Enable ICU locale formats as part of the scheduled rollout] チェックボックスをオフにすることで、Spring ‘25まではICUロケールの適用を延期することが可能です。詳細はサクセスナビ「ICUロケール形式の有効化」をご覧ください。続いてIndustry Cloudの有償オプションであったインテリジェントフォームリーダーの廃止です。現在のご契約が終了すると本機能が利用できなくなりますため、新しい機能であるインテリジェントドキュメントリーダーへの切り替えをご検討ください。次にオンライン寄付のプラットフォームであるElevateの機能廃止についてです。本機能をご利用のお客様向けに、代替ソリューションへの切り替え方法が公開ナレッジに記載されていますのでご確認ください。最後にその他の情報です。本動画や資料に関するアンケートがございます。ぜひみなさまの率直なご意見をお聞かせください。いただいたご意見をできるだけ反映し、より良いものにしていきたいと考えておりますので、ご協力いただけますと幸いです。11月度のアップデートは以上となります。最後までご覧いただき、ありがとうございました。
-
この記事で学べること 商談スコアの更新履歴を保存する設定方法概要商談スコアの更新履歴の取得は以下に役立ちます。商談開始から完了までどういうスコア遍歴をしているか、幅が広すぎる更新が多すぎないかなどが確認でき、スコアの特徴や信用度を決める時に役立ちます。スコアの活用時、スコアが良くなったのか、悪くなったのかなど、変化量を取得する時に役立ちます。商談スコアは、項目更新履歴では更新履歴を取得できません。商談スコアの履歴をカスタムオブジェクトに保持して評価する方法をご紹介します。なお、本設定を一定期間だけではなく、常時有効化する場合は、商談数によってはストレージを圧迫する可能性があるためデータの削除方針もご検討ください。設定手順商談オブジェクトに以下項目を作成します。(商談完了時のスコアを保存しようにて作成済みの場合不要です)「商談スコア(コピー)」項目 :商談スコアを数式参照する数式項目商談スコア履歴を保存するカスタムオブジェクト「商談スコア履歴」を作成します。自動化機能のフローを活用し、毎日自動的にスコア変化を取得します。商談のレポートを作成し、スコアの変化量を一覧で表示します。1.項目の作成設定>オブジェクトマネージャ>商談>項目とリレーション>新規のボタンから以下項目を作成します。なお、この項目は、Einstein 商談スコアリングの設定で、分析対象項目から外すことをお勧めします。(商談完了時のスコアを保存しようにて作成済みの場合不要)「商談スコア(コピー)」項目作成「数式」項目とし、商談スコアを参照させます。(数式:OpportunityScore.Score)※フローで商談スコアを直接参照できないため、数式項目を作成します。image.png2.カスタムオブジェクト「商談スコア履歴」の作成設定>オブジェクトマネージャ>新規ボタン>カスタムオブジェクトから、新規オブジェクトを作成します。表示ラベル、オブジェクト名を設定します。レコード名の表示ラベルと型を入力:データ型で「自動採番」を選択し、表示形式と開始番号も指定します。追加の機能:「レポートを許可」にチェックし、必要に応じて、他の内容もチェックします。「カスタムオブジェクトの保存後、新規カスタムタブウィザードを起動する」にチェックをします。「保存」を押します。新規カスタムタブウィザードが立ち上がるので、タブの内容や表示の設定を実施します。カスタムオブジェクト「商談スコア履歴」作成後、以下項目を追加作成します。(設定>オブジェクトマネージャ>「商談スコア履歴」>項目とリレーション>新規 から作成します)「商談」項目:データ型「主従関係」:商談への参照項目「商談スコア」項目:データ型「数値」小数点の位置=0:最新のスコア格納用項目「変更前スコア」項目:データ型「数値」小数点の位置=0:変更前のスコア格納用項目以下のような項目構成になったらカスタムオブジェクトの準備完了です。2.フローの作成毎日定時に商談スコアをチェックし、「商談スコア履歴」の最新履歴のスコアから変更がある場合は、最新の商談スコアを履歴保存します。1日に複数回スコアが更新された場合は、最終更新値のみが履歴に残ります。具体的には以下のような処理を作成していきます。毎日定時に「商談スコア」が1以上の商談に対して、フローを起動自商談の過去の商談スコア履歴レコードの有無を確認履歴なしの場合、商談スコア履歴を作成履歴ありの場合、最新履歴の商談スコアと現在の商談スコアに差異があれば履歴作成では早速作成していきましょう。設定>フロー>新規作成 から新規フローの画面を立ち上げます。「スケジュールトリガフロー」を選択します。「スケジュールを設定」を選択し、以下を設定します。開始日:いつから履歴を保存するかを指定開始時刻:何時に履歴を取得するかを指定頻度:「毎日」を指定「完了」を選択「オブジェクトを設定」を選択し、スコアが1以上の商談を対象にして、処理を実行するよう指定します。オブジェクト:「商談」を指定条件の要件:「すべての条件に一致(AND)」を選択項目:「1.項目の作成」 で作成した「商談スコア(コピー)」項目を指定演算子:「以上」を選択値:「1」を入力「完了」を選択「+」から「レコードを取得」を選択します。商談に紐づく「商談履歴」の最新レコードを取得する設定を行います。表示ラベル、API参照名:「履歴レコードを取得」、「get_history」を入力オブジェクト:「商談スコア履歴」を指定します。※「2.カスタムオブジェクト「商談スコア履歴」の作成」で作成したオブジェクト名を指定商談スコア履歴レコードの絞り込み:条件の要件:「すべての条件に一致」を選択項目:「2.カスタムオブジェクト「商談スコア履歴」の作成」で作成した「商談」項目を指定演算子:「次の文字列と一致する」を指定値:「$Record」>「商談ID」の順に選択します。商談スコア履歴レコードの並び替え並び替え順:「降順」を選択並び替え:「作成日」(CreatedDate)を選択「完了」を選択「+」から「決定」を選択します。取得した履歴のレコードの有無と、スコアが変化しているかをチェックし分岐をさせます。表示ラベル、API参照名:任意の文字列を設定結果の順序:一番上を選択表示ラベル:「履歴なし」と指定結果のAPI参照名:任意の文字列を指定結果を実行する条件の要件:リソース:「get_history(商談スコア履歴)」を選択し、カーソルを外します。演算子:「null」を選択値:「$GlobalConstant.true」を指定「結果の順序」の「+」から1つ分岐設定を増やし、以下の設定をします。結果の順序:2つ目を選択表示ラベル:「商談スコアに変化があり」と指定結果のAPI参照名:任意の文字列を指定結果を実行する条件の要件:リソース:「$Record」>「商談スコア(コピー)」の順に選択演算子:「次の文字列と一致しない」を選択値:「get_history(商談スコア履歴)」>「商談スコア」の順に指定「結果の順序」の「デフォルトの結果」を選択し、以下設定をします。表示ラベル:「変化なし」と指定「完了」を押します。以下のように分岐ができます。「商談スコアに変化があり」の「+」から「レコードを作成」を選択します。レコードを作成画面が開くので、以下を設定します。表示ラベルl、API参照名:任意の文字列を指定作成するレコード数:「1」が選択されていることを確認レコード項目の設定方法:「個別のリソースおよびリテラル値を使用」を選択オブジェクト:「商談スコア履歴」を選択商談スコア履歴の項目値を設定:以下を設定項目:「変更前スコア」を指定、 値:「get_history(商談スコア履歴)」>「商談スコア」 の順で選択項目:「商談」(主従関係項目)を指定、 値:「$Record」>「商談ID」の順で選択項目:「商談スコア」を指定、 値:「$Record」>「商談スコア(コピー)」の順で選択「完了」を押す続いて、「履歴なし」の+を選択して、「要素に接続」を押しますすると以下のような画面になるので、先に作成したレコードを作成要素(画像では「履歴作成」)の「+」を選択します。これで作成完了です。全体像は以下のようになります。画面上部の「デバック」ボタンを押してテストをして見ましょうデバック画面で、「ロールバックモードでフローを実行します」に必ずチェックをして実行します。※チェックしない場合、実際にレコードが作成されます。任意の商談1件のみテスト実行さるため、処理内容とエラーがないことを確認します。十分テストし、フローを「有効化」したら設定は完了です。3.レポートの作成履歴が取得できた後は、商談スコア履歴のレポートを作成し、変化量を一覧化します。以下の流れでレポートを作成します。レポート>新規レポート>商談スコア履歴が関連する商談のレポートを選択します。アウトラインの「列」の「▼」から「行レベルの数式を追加」を設定します。列の名前:スコア変化形式:数値数式:商談スコア履歴の「商談スコア」項目 ー「変更前商談スコア」項目アウトラインを指定します。グループ:フェーズ、取引先名、商談名を指定します。項目列:商談スコア(商談スコア履歴の項目)、完了予定日、スコア変化(上記行レベルの数式を追加で作成した項目)など検索条件を設定します。商談状況:進行中商談スコア履歴の作成日:期間を絞る(過去30日など)最終スコア:空白と一致しない対象適宜、完了予定日などで期間を絞るおつかれさまでした。上記レポートをもとに、ダッシュボードでスコアの変化量を一覧化して確認できます。上記以外にも、以下などで活用してみてください。商談スコアが初めてついた対象を一覧化してスコア確認(レポートでの検索条件で変更前スコアが空白の対象を抽出)一定の基準以上のスコア変化があった対象を一覧化して営業活動に利用(レポートでの検索条件でスコア変化量が一定数以上を抽出)参考:フローやレポート・ダッシュボードの学習リソース今回設定に利用したフローやレポートダッシュボードの機能をもっと知りたい方は、以下のリソースをご活用ください。フローをいちから学びたいフロー初心者向け学習リソースまとめ:フローの機能を学ぶことができるコンテンツのまとめ記事になります。エキスパートコーチング ▶フローによる プロセスの自動化:エキスパートがフローの使い方をご案内いたします。PremierまたはSignature Success Planをご契約のお客様はSalesforceエキスパートとの1 対 1 のセッションにお申し込みいただくことが可能です。レポートダッシュボードをもっと学びたい以下2種類の動画にて活用方法を解説しております。また、PremierまたはSignature Success Planをご契約のお客様は動画の内容でご質問がある場合は、Salesforceエキスパートとの1時間のフォローアップセッションをリクエストいただくことが可能です。(動画は誰でも閲覧可能です)エキスパートコーチング ▶レポート&ダッシュボード クイックスタートエキスパートコーチング ▶ レポート&ダッシュボード レベルアップ活用ステップ全体に戻る場合は、こちら
-
この記事で学べること運用開始までにやるべきことの全体像これらに取り組むべき理由この記事のゴールこの記事のゴールは「運用開始までにやるべきことを理解する」ことです。そのために、以下3ステップで進めていきます。セキュリティに関する情報/多要素認証運用開始までに押さえておきたい7つのステップなぜこれらを押さえることが重要なのかセキュリティに関する情報/多要素認証私たちSalesforceは、お客様のデータ保護に真摯に取り組んでおります。セキュリティ脅威がますます一般的になってきている昨今、 お客様が顧客情報やビジネスを守っていくためには、 より強力なセキュリティ対策を実装いただくことが極めて重要になります。本パートでは、導入初期に必ずご理解いただきたい、セキュリティに関する3つのご検討事項をご紹介いたします。1.社内のデータアクセスレベルの制御攻撃者の標的になるリスクを回避する鍵となるのは、まず自社のSalesforceユーザのデータアクセスを保護することです。Salesforceでは、項目レベル、レコードレベル、オブジェクトレベル、組織レベルで様々なアクセスの制御、データの保護のための機能を提供しております。この機能を利用することで、お客様は利用ユーザのSalesforceへのログインを制御したり、ログインした後の操作や、データの表示についても、各ユーザに適切なレベルのデータアクセスを付与することが可能です。お客様によるデータの保護を実現するための具体的な機能や設定方法については、SalesCloud アドミン基礎のエキスパートコーチングでの学習がおすすめです。まずは動画(Chapter3: ユーザと権限管理)で概要をご確認の上、詳しくはエキスパートコーチングのフォローアップセッションにお申し込みください。※フォローアップセッションはPremierまたはSignature Success Planをご契約のお客様限定となります。2.ユーザのログイン制御 〜多要素認証(MFA) 〜利用ユーザに合わせたデータの保護をしたとしても、そもそもID・パスワードが漏れてしまうと、情報漏洩してしまうリスクがあります。ユーザの皆様に多要素認証(MFA)をご利用いただくことで、Salesforceへのログイン制御をし、安全に製品をご利用いただけます。多要素認証(MFA)の設定手順に関しては、本サクセスナビ内のMFAページにて詳細をご確認ください。3.セキュリティに関する情報のご提供 〜Trustサイト〜Salesforceの「Trust サイト」では、メンテナンス・システム障害についてリアルタイムにお客様へお知らせしています。気になったタイミングでTrustサイトをご確認頂くことも可能ですが、情報発信のタイミングでメールで自動通知を受け取ることもできます。とりわけSalesforceのシステムを管理するお立場の方は、ぜひご登録ください。参考)Salesforce Trustユーザガイドその他、セキュリティ関連でのお問い合わせについては、弊社テクニカルサポートでもご対応させていただきます。テクニカルサポートの活用方法に関しては、次節でお伝えしてまいります。セキュリティに関する3つのご検討事項を押さえたら、いよいよ運用開始に向けて準備に入っていきましょう。運用開始までに押さえておきたい7つのステップSales Cloud導入を成功に導くにはいくつかの押さえておきたいステップがあります。本記事では、運用開始までに取り組んでおくべきことの概観をご説明します。①事前準備、②計画、③実装、④運用準備と大きな流れがあり、より具体的には以下7つのステップに分解されます。<はじめに> これからの検討内容を理解するこれからSales Cloudの運用を開始するにあたって必要な検討内容や、Salesforceの活用リソースを学んでいきます。 Salesforceの特徴を理解 これからの検討内容を整理 活用リソースの種類と使い方を理解<基本理解> 基本構造・機能を理解するSales Cloudはカスタマイズ性が高いため、担当者にWeb開発などの専門的な知識がなくとも、現場のニーズに適合したシステムを構築、改修することが可能です。まずはSales Cloudの仕組みの概観を掴みながら、以下3つの基本的な内容を押さえていきましょう。 基本構造と基本的な用語の理解 カスタマイズの方法 データの分析機能の理解※ 設定・構築パートナーに実装作業を依頼するなどで、直接設定作業に関わらない場合でも、基本構造・機能をご理解いただくことで、Sales Cloudと日常業務のつながりがイメージしやすくなり、効率の良い構築・運用を行うことができます。<計画策定> 活用のゴールを明確化するSales Cloudでデータを活用し、ビジネスの成長に繋げていくためには、[何を実現したいのか?そのためにどんなデータを収集するのか?]といった「ゴール」を明確にすることが重要です。ゴールが明確でないと、入力の手間だけが増えてしまい、結果、期待していた効果に繋がらなくなってしまう可能性があります。ゴールを定め、そのゴール達成のために最適なデータ分析をすることで、より速く的確な戦略や打ち手を導き出せることになります。まずは、自社がSales Cloudを導入して実現したい事は何か?を明確にしましょう。 運用開始に向けて必要な役割の明確化 実現したいことの明確化 運用開始に向けた計画を策定<要件定義> 管理するデータを検討する活用のゴールが決まったら、次は可視化のためにSales Cloud上でどのようにデータを構成するか整理していきましょう。ここでは、自社で管理するデータの検討と、必要な設定を定義するためのポイントについて学習し、自社に合った設計をしていきます。 目標達成のためにやるべきことを計画 商談の流れの整理 必要な設定の理解<実装> データの取り込み・可視化を行う要件定義を終えたら、いよいよ実装を行います。自社にとって最適な入力画面を整え、必要なデータを取り込んだら、可視化の準備をしていきましょう。目標に対する進捗を管理するため、『レポート・ダッシュボード』を設計します。 実装時の注意点の理解 データの取り込み データの可視化(レポート・ダッシュボード)<運用検討> 運用に向けた準備をする実装を終えたら、利用者への展開に向けた運用の準備に入ります。ツールができあがっても、それを実際に利用するユーザーが、運用方法や正しい使い方を理解していなければ、使いこなしていくことは困難です。運用開始前に検討すべきポイントを理解し、ユーザーに伝えていきましょう。 運用ルールの策定 ユーザートレーニングの実施 運用テストと修正<運用開始> 運用後に必要なポイントを理解する効果を出すツールにするためには、運用開始後も継続的に利用ユーザーの活用状況をチェックし、定期的に改善を行う事が重要です。 定着に向けたプランニング 継続的な改善の実施 活用状況のチェックなぜこれらを押さえることが重要なのかそれでは、なぜこれらを押さえることが重要なのでしょうか。これらの検討が抜け漏れてしまうと、下図のように「現場が使ってくれない」や「使っているけど効果がでない」といった状況に陥りやすくなってしまいます。例えば、Sales Cloudを何のために利用するのかがはっきりせず、ただ情報の記録だけを行ってもビジネス成果は創出できません。また利用ユーザーとしても、自分たちの業務にどんなメリットがあるのかが理解できなければ、活用は進みません。これらの課題を未然に防ぎ、Sales Cloud導入を成功に導くため、本ステップを含むはじめてガイドの7つのステップを漏れなく学習し、実践していきましょう。まとめ運用開始前に必要なステップは理解できましたか? 以下の順序で運用開始に向けた準備を進めていきましょう。<はじめに> これからの検討内容を理解する<基本機能> 基本構造・機能を理解する<計画策定> 活用のゴールを明確化する<要件定義> 管理するデータを検討する<実装> データの取り込み・可視化を行う<運用検討> 運用に向けた準備をする<運用開始> 運用後に必要なポイントを理解する次の記事:活用リソースの種類と使い方を理解しましょう「活用7ステップ」全体に戻りたい場合はこちら
-
この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、パファーマンス分析のために、確認したいケースごとにどのログのどの項目を参照することにより、ボトルネックやチューニングのポイントを確認することができるか理解できます。イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング:セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング:イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとはここでは、パフォーマンス分析用のログとしてイベントモニタリングのログを対象に説明しています。パフォーマンス監視の重要性生産性向上を実現するために導入したせっかくのシステムもレスポンスが悪く利用にストレスがあると利用が促進されない場合があります。パフォーマンスはシステムを利用するにあたって重要な要因です。しかしパフォーマンスは様々な要因で劣化してしまいます。例えば、大量データの取り扱い、データベースのインデックス、冗長なロジックのコード、またお客様環境においてもネットワークやクライアントの環境によってもパフォーマンス劣化が発生します。そのため継続的なパフォーマンスの監視はシステムの導入を成功に導くために重要なポイントとなります。イベントモニタリングによるログの取得多くのイベントログに要求の完了にかかった CPU 時間 (CPU_TIME)が記録されます。また、APEX実行に関するログにはデータベースのパフォーマンスに係る数値(DB_TOTAL_TIME)が記録されます。パフォーマンスの問題が発生した際は、イベントログから要求の完了に係ったCPU時間とデータベースの処理にかかった時間を比較することで、パフォーマンス上の問題が独自のコードの部分にあるかデータベースレイヤのどちらにあるか、またはクライアント環境に起因するものか判断することが出来ます。また、大まかに処理に時間がかかった部分を判断した上で、デバッグログの設定をしていただく事でより具体的にどの処理に時間を要したか、効率よく確認をしていく事が可能となります。ヘルプ : デバッグログの設定取得するべきイベントログファイル以下にパフォーマンスに関する調査において参考となるイベントログファイルおよびその項目について例示をします(表中黄色いハイライト部分は、ログ対象のイベントを特定する項目です)。各イベントログファイルの内容については以下をご参照ください。SOAP API開発ガイド:EventLogFile でサポートされているイベント種別Lightning ページビューイベント種別Lightning Experience および Salesforce モバイルアプリケーションでイベントが発生したページに関する情報を表します。Lightning ページビューイベントは、ユーザがアクセスしたページ、そのページにユーザが滞在した時間、ページの読み込み時間を追跡します。Summer ‘22のリリースで、EFFECTIVE_PAGE_TIME_DEVIATION、EFFECTIVE_PAGE_TIME_DEVIATION_ERROR_TYPE、および EFFECTIVE_PAGE_TIME_DEVIATION_REASONの3項目が追加されました。これらの項目によりページのロードに時間がかかる原因の特定が容易になります。項目名説明PAGE_URLユーザが開いた最上位の Lightning Experience ページまたは Salesforce モバイルアプリケーションページの相対 URL。ページには、1 つ以上の Lightning コンポーネントを含めることができます。複数のレコード ID を PAGE_URL に関連付けることができます。EFFECTIVE_PAGE_TIMEページを読み込んでからユーザがページの機能を操作できるようになるまでにかかった時間 (ミリ秒) を示します。実効ページ時間は、複数の要素 (ネットワーク速度、ハードウェアパフォーマンス、ページの複雑さなど) の影響を受けます。60 秒を超える有効なページ時間が検出された場合、この項目の値は null に設定されます。EFFECTIVE_PAGE_TIME_DEVIATION逸脱が検出されると EFFECTIVE_PAGE_TIME_DEVIATION はtrueを記録します。デフォルト値はfalseです。EFFECTIVE_PAGE_TIME_DEVIATION_REASONページ読み込み時間の逸脱の理由が記録されます。値の意味についてはLightning ページビューイベント種別からAPI version v55.0以降をご確認くださいEFFECTIVE_PAGE_TIME_DEVIATION_ERROR_TYPEこのフィールドはEFFECTIVE_PAGE_TIME_DEVIATION_REASONにPAGE_HAS_ERRORが記録された場合に入力されます。入力されうる値はCUSTOMまたはSYSTEMとなります。・CUSTOM : 顧客システムまたはネットワークに起因するエラー・SYSTEM : セールスフォースに起因するエラーLightning パフォーマンスイベント種別Lightning Experience および Salesforce モバイルアプリケーションのパフォーマンスのトレンドを追跡します。レコードに対するユーザアクションに関する所要時間が把握できます。項目名説明UI_EVENT_SOURCEレコードに対するユーザアクション(作成/編集/削除/参照など)。この項目の値は、ユーザのアクションが 1 つのレコードに対して実行されたか複数のレコードに対して実行されたかを示します。たとえば、read は (レコード詳細ページなどで) 1 つのレコードが参照されたことを示し、reads は (リストビューなどで) 複数のレコードが参照されたことを示します。DURATIONページ開始時刻からの時間 (ミリ秒)。Apex 実行イベント種別実行された Apex クラスに関する詳細が含まれます。項目名説明URI要求を受信しているページの URI。NUMBER_SOQL_QUERIESイベント中に実行された SOQL クエリ数。IS_LONG_RUNNING_REQUEST要求が実行時間が長い組織の同時 Apex 要求の上限にカウントされるか (true)、否か (false) を示します。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU使用率にカウントされません。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。EXEC_TIMEエンドツーエンドの Apex 実行時間 (単位: ミリ秒)。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。Apex REST APIイベント種別すべての Apex REST API 要求に関する情報を取得します。項目名説明URI要求を受信しているページの URI。ROWS_PROCESSED要求で処理された行数。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU使用率にカウントされません。DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されているアクティビティ量を示します。DB_BLOCKSデータベースで発生しているアクティビティ量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。Apex SOAP イベント種別Web サービス API コールに関する詳細が含まれます。項目名説明CLASS_NAMEApex クラス名。クラスが管理パッケージの一部である場合、この文字列にはパッケージ名前空間が含まれます。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。Apex トリガイベント種別組織で起動されたApexトリガに関する詳細が含まれます。項目名説明TRIGGER_ID起動されたトリガの 15 文字の ID。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。EXEC_TIMEエンドツーエンドの Apex 実行時間 (単位: ミリ秒)。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。非同期レポート実行イベント種別非同期レポート実行イベントは、スケジュールされたレポート要求に対して作成されます。このカテゴリには、ダッシュボードの更新、非同期レポート、スケジュールレポート、分析スナップショットが含まれます。項目名説明REPORT_ID実行されたレポートの 15 文字の ID。ROW_COUNT非同期レポート実行イベントで処理された行数。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_BLOCKSデータベースで発生している活動量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。実行時間が長い同時 Apex 制限イベント種別組織の同時実行制限に達した後に Salesforce によって終了された、組織内の実行時間が長い同時 Apex 要求に関する情報が含まれます。確立された Apex コンテキストが 5 秒間実行される要求は、実行時間が長い同時要求の組織の制限に含まれます (非同期要求は制限に含まれません)。実行時間が長い要求数が 10 (組織のデフォルトの制限) を超えた場合、その他の実行時間が長い要求は終了されます。項目名説明REQUEST_URISalesforce によって終了された実行時間が長い Apex 要求の URI。継続コールアウトサマリーイベント種別トランザクション中に実行されたすべての非同期コールアウト、その応答状況コード、実行時間、および対象の URL エンドポイントに関する情報が含まれます。項目名説明URLコールアウトエンドポイント URL。継続で使用された HTTP 要求数によっては、この項目に最大 3 個のスペース区切り値が含まれる可能性があります。DURATION合計継続時間 (ミリ秒)。外部のカスタム Apex コールアウトイベント種別Salesforce Connect のカスタムアダプタを介した外部データコールアウトを表します。項目名説明ENTITYアクセスされる外部オブジェクトの名前。ACTIONコールアウトによって実行されるアクション(query/upsert/delete)。ROWS_FETCHEDコールアウトによって取得された行の数ROWS結果セットの総レコード数FETCH_MS外部システムからクエリ結果を取得するのに要した時間 (ミリ秒)。THROUGHPUT1 秒間で取得されたレコード数。EXECUTE_MSSalesforce がクエリの準備および実行に要した時間 (ミリ秒)。TOTAL_MSクエリの準備、実行、およびクエリ結果の取得に要した時間 (ミリ秒)外部の OData コールアウトイベント種別Salesforce Connect の OData 2.0 および OData 4.0 アダプタを介した外部データコールアウトを表します。項目名説明ENTITYアクセスされる外部オブジェクトの名前。ACTIONコールアウトによって実行されるアクション(query/upsert/delete)。ROWS_FETCHEDコールアウトによって取得されたレコードの数。コールアウトによって取得されたレコードは、大きな結果セットのサブセットである場合がありますROWS結果セットの総レコード数FETCH_MS外部システムからクエリ結果を取得するのに要した時間 (ミリ秒)THROUGHPUT1 秒間で取得されたレコード数。EXECUTE_MSSalesforce がクエリの準備および実行に要した時間 (ミリ秒)TOTAL_MSクエリの準備、実行、およびクエリ結果の取得に要した時間 (ミリ秒)レポートイベント種別ユーザがレポートを実行したときの動作に関する情報が含まれます。このイベント種別には、レポートのエクスポートイベント種別のすべての活動とその他の活動が含まれます。項目名説明REPORT_ID実行されたレポートの 15 文字の ID。ROW_COUNTレポートイベントで処理された行数。行数が多く、かつ AVERAGE_ROW_SIZE も大きい場合は、ユーザが詐欺目的で情報をダウンロードしている可能性があります。たとえば、競合他社に転職する前にすべてのセールスリードをダウンロードする営業担当などがこれに該当します。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されている活動量を示します。DB_BLOCKSデータベースで発生しているアクティビティ量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。フロー実行イベント種別合計実行時間、インタビューの数、エラーの数などの詳細を含む、実行されたフローに関する情報が含まれます。項目名説明FLOW_VERSION_ID実行されたフローバージョンの ID。FLOW_LOAD_TIMEフローのメタデータの読み込みにかかった時間 (ミリ秒単位)。TOTAL_EXECUTION_TIMEすべてのフローインタビューの開始と終了にかかった合計時間 (ミリ秒単位)。Wave パフォーマンスイベント種別Analytics パフォーマンスのトレンドを追跡するのに役立ちます。項目名説明RECORD_IDTableau CRM オブジェクトの Salesforce ID。TAB_IDユーザインターフェースの特定の [分析] タブの ID。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU時間にカウントされません。RUN_TIME要求にかかった時間 (ミリ秒単位)。EPT体験ページ時間 (ミリ秒単位)。Visualforce 要求イベント種別Visualforce 要求に関する詳細が含まれます。要求はブラウザ (UI) から実行できます。項目名説明PAGE_NAME要求された Visualforce ページの名前。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されている活動量を示します。DB_BLOCKSデータベースで発生している活動量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。コンソールイベント種別Salesforce コンソールのパフォーマンスと使用に関する情報が含まれます。サイドバーコンポーネントで [コンソール] タブが開かれるたびに、コンソールイベントがログに記録されます。それ以外は、Salesforce Classic の場合と同様に、[コンソール] タブが開かれると、通常のレコードの詳細の表示イベントが記録されます。項目名説明COMPONENT_IDコンポーネントの 15 文字の ID。CONSOLE_IDコンソールの 15 文字の ID。RECORD_IDコンソールに関連付けられたレコードの 15 文字の ID。CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、(開発者が制御できない)他の動作が行われます。この時間はすべて、CPU時間にカウントされません。DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。RUN_TIME要求にかかった時間 (ミリ秒単位)。学習ツールSOAP API開発ガイド:EventLogFile でサポートされているイベント種別ヘルプ : デバッグログの設定トレイルヘッド:Lightning Experience のパフォーマンスの最適化ヘルプ:技術要件とパフォーマンスのベストプラクティスまとめパフォーマンス分析に関するログは、イベントモニタリングのログに記録され、対象のログと項目を確認することにより、パフォーマンス問題がどこで発生しているのか、またどこがボトルネックになっているのか確認することができます。この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、パファーマンス分析のために、確認したいケースごとにどのログのどの項目を参照することにより、ボトルネックやチューニングのポイントを確認することができるか理解できます。
-
連載:『営業改革のコンパス~規模に応じたトランスフォーメーションの最適設計~』vol.11
前回Vol. 10 に続いて、上記の図「営業改革プロジェクトの標準的なプロセス」からステップ2 チーム結成・メンバーの選定以降を解説していきます。ステップ2 チームの結成・メンバーの選定 「営業が強い」とされる組織であればあるほど、経営者や営業担当役員など上層部が強い意志を持って、オーナーとして関与しない限り、改革をやり遂げられません。実際、「営業改革を実施する」と号令を発するプロジェクト・オーナーは、経営トップや役員が多いようです。その後、多くの企業では経営企画部や営業推進部からプロジェクト・リーダーやメンバーが選出され、プロジェクト・チームが作られます。メンバーは専任で選ばれる場合もあれば、兼任の場合もあります。理想的なのはメンバーがプロジェクトに専念できる形ですが、コアメンバーでない限り、兼任メンバーとして各部門長やリーダーが集まり、営業改革の具体的な方向性を議論し、現場浸透を推進する役割を担うことが多いのが実態です。営業改革のコアメンバーは5名ほどで、10名を超える企業はまれです。なお、兼任者がプロジェクトにかけている工数は、だいたい1週間に6時間程度(2時間×3日、もしくは3時間×2日)で、数カ月続けることが多いようです。この中で、営業業務の調査・整理、営業プロセスの作成やフェーズの定義、トレーニング計画の立案などをおこなっています。では、具体的にどのような人物がチーム・メンバーに選定されているのでしょうか。プロジェクトや営業現場の経験があるか、ITリテラシーや分析能力はどうかなど、さまざまな選定基準が考えられますが、多数のプロジェクトを見る中で、成功している事例には次のような特徴が見られました。まず、プロジェクト・リーダーですが、力強く周囲を巻き込んでいくタイプ、淡々と仕事を進めるタイプ、現場に積極的に出ていくタイプ、メンバーの後ろで見守るタイプなど、リーダーシップスタイルそのものは千差万別でした。ただ、共通するのは「絶対に成功させるんだ」という熱い思いを持ち、ブレない強さを持っていること。どのプロジェクト・リーダーも、現場の反発やITシステムのトラブルなどの諸問題に直面したときに、メンバー任せにするといった中途半端な対応をとらず、日々現場で顧客を相手に頑張っている営業担当者の立場で考え、優先順位を決めて行動していました。ステップ3 方針決定、ビジョンやゴールの設定、価値観のすり合わせプロジェクトの重要なポイントとなるのが、「方針決定、ビジョンやゴールの設定、価値観のすり合わせ」です。ここがまさに改革方針の決定段階であり、営業改革をすることで、「具体的にどのような営業スタイルになるのか」「これまでできなかった何が実現できるようになるのか」「自分たちにどのようなメリットがあるのか」を明確にしていきます。改革方針は企業の置かれた状況によって大きく変わってくるでしょう。プロジェクト発足のきっかけは似たようなものであったとしても、改革の方針や道筋は企業によってさまざまだと思います。基本的な「見える化」と呼ばれる営業現場の透明性の確保については、どの企業も最初にあたりまえのように出てくるキーワードですが、業界内の順位、顧客からの評価、ビジネスモデル、自社特有の営業風土やこれまでの取り組みの歴史によってその後のアプローチは変わってきます。自社の営業はどうあるべきなのか、そのために必要なスキルはなんなのか、数年後の自社の営業像をすり合わせます。まさに新たな営業部門の「価値観」が決められる段階です。この段階で行ういくつかの施策をご紹介します。・顧客インタビュー改革の方向性のヒントは顧客にあります。これまで長期にわたって取引をしていただいている顧客や、つい最近取引を開始していただいた顧客、逆に離れてしまった顧客などに、「なぜ自社を選んだのか」「改善点はどこか」「営業に求めることはどのようなところがあるのか」をヒアリングしていきます。・営業現場のインタビューと業務調査営業現場のインタビューと業務調査の目的は大きく2つ。「業務の実態を把握し、改善点を見つけること」で現在の営業担当者やマネージャーの業務を実態調査、改善策につなげる。「現場のリーダーを見つけること」で改革を進めていく中で力になってくれる候補をリストアップしていきます。・ビジョン設定を目的としたワークショップ顧客インタビューや営業現場のインタビューと業務調査の後は、あるべき営業の姿や新しい業務フローなどを作る過程に入ります。この段階で現場を巻き込んだワークショップ形式で新しいアイデアを集めることをお勧めいたします。ワークショップにはたくさんのやり方がありますが、ここでは重要と思われるワークショップをご紹介します。ワークショップ1:カスタマージャーニーマップワークショップ顧客視点で自社のWebサイトや提案書を見てみると、改善すべき顧客との接点や、スピード感が足りない所などがわかります。営業として顧客に対面する前の段階で、顧客はどのように自社を見ているのかをあらためて見直すきっかけにもなるでしょう。ワークショップ2:営業プロセスの標準化、フェーズ作成ワークショップ顧客の立場になって自社を見つめた後は、自社の業務フローや営業プロセスについて考えます。「新規顧客と既存顧客」「直接販売と間接販売」などで考慮すべき点があれば、そのフローや注意点を書き出します。その上で案件のフェーズと確認項目を決めます。その内容は営業マニュアルを作成する際に活用し、ある程度の期間実行した後に現場の意見を反映しながら修正していきます。ワークショップ3:KPIダッシュボード作成ワークショップ営業部門が新しい営業スタイルを実行し、きちんと結果に結びついているかを確認するのがダッシュボードです。いわゆる分析ツールで、経営者向け、営業マネージャー向け、営業担当者向けなどに最適化することができ、目標の達成状況や、抜け漏れなどを確認することが可能になります。・営業の業務整理、ルールの作成、その他ワークショップの結果を反映した業務フロー図の作成を行います。最終的に、「営業がやるべき仕事とそうでない仕事」「新しい組織構成」などにも踏み込む必要があるでしょう。事例で取り上げた企業では、かなりの割合でこの業務整理を行い、営業から事務作業を減らし、顧客への時間を増やしていました。次回は、営業改革プロジェクト ステップ④情報プラットフォーム(ITシステム)選定以降について解説していきます。公開は10/18(木)を予定しております。著者:田崎純一郎(たさき じゅんいちろう)セールスフォース・ドットコムセールスイネーブルメントシニアディレクター————————————————完全版eBookをダウンロード提供中本連載『営業改革のコンパス~規模に応じたトランスフォーメーションの最適設計~』第3章(Vol. 10〜13の記事)は、完全版のeBookにまとめています。ぜひ、下記からダウンロードしてお読みください。【 第3章 ダウンロードはこちら 】Vol. 6~9の記事は第2章の内容になります。第2章のeBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。【 第2章 ダウンロードはこちら 】Vol. 1〜5の記事は第1章の内容になります。eBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。【 第1章 ダウンロードはこちら 】連載記事<第1章>Vol. 1 営業改革で解決したい課題は何か - 営業組織の規模と営業改革テーマVol. 2 営業マネジメント50人の壁 ― 営業支援システムの導入率からみる営業組織の課題Vol. 3 営業組織の規模によって異なる課題感 ― データの収集と活用Vol. 4 現場が見えなくなる中規模組織Vol. 5 使いこなせていない51名以上の営業組織は「営業案件の可視化やパイプライン管理ができていない」<第2章>Vol. 6 営業活動は不完全情報ゲームVol. 7 営業を“群衆”ではなく“組織”に -情報を使って160時間の使い方を最適化Vol. 8 営業情報は製品中心ではなく「顧客データを中心」にフロントとバックをつなげるVol. 9 作ったものを売る営業から、売れるものを作る会社へ<第3章>Vol. 10 営業改革プロジェクトでは、どんな困難に直面するのか?Vol. 12 情報プラットフォーム(ITシステム)選定 ~ 組織変更の実施、教育・社内トレーニングVol. 13 KPI、データ分析と活用 ~ 定着化と展開<関連セミナーご案内>Salesforceでは、営業改革をサポートするウェブセミナーをご用意しています。あらゆる企業規模・業界において営業マネージャーの方々がどのようにSalesforceを活用すべきかをご紹介します。ぜひご活用ください。https://successjp.salesforce.com/article/NAI-000042
-
Salesforceのレポートのスキルを身につけるには実践あるのみ。色々なレポートの作り方をマスターできるドリルをご用意しました。これをやればレポートマスター間違いなしです。是非ご活用ください!レポートを表示するレポートの表示を変更するすべての取引先を抽出するすべての取引先レポートの表示列に業種項目を追加する、表示列から評価項目を削除する列を取引先/都道府県(請求先)/作成日の順に並び替える複数行のデータを作成日を基に降順に並び替えるデータを絞り込む検索条件を指定してデータを絞り込む私が担当する取引先を抽出する作成日が今年の取引先を抽出する作成日が2019年1月10日から2019年3月10日の取引先を表示する都道府県(請求先)が東京都の取引先を抽出する都道府県(請求先)が東京都と神奈川県の取引先を表示する電話番号が03から始まる取引先を抽出する都道府県(請求先)が東京都と神奈川県で、電話番号が03から始まる取引先を抽出するレポートの実行画面上で条件に都道府県(請求先)が神奈川県の取引先を追加する検索条件で「または」「かつ」を使用してデータを絞り込む都道府県(請求先)が東京都または電話番号が03から始まる取引先を抽出する都道府県(請求先)が東京都かつ電話番号が03から始まるか、都道府県(請求先)が大阪府の取引先を表示する日付情報を使用してデータを絞り込む過去1週間のうちに更新された取引先を抽出する先月に更新された取引先を抽出する今年に入って更新されていない取引先を抽出する値が空白「である」「でない」条件を使用してデータを絞り込む電話番号が入力されていない取引先を抽出する電話番号に何らかの値が入力されている取引先を抽出する関連レコードの有無によってデータを絞り込む今月作成された活動がある(=紐づく)取引先だけを抽出する活動が1件もない(=紐付かない)取引先だけを抽出するデータをまとめるグループ化してレポートを見やすくする商談の完了予定日ごとにグルーピングする完了予定日と商談所有者で商談をグルーピングする完了予定日ごとにグルーピング後、集計期間を日付から年月形式(yyyy年mm月)に変更するグループ化して集計する完了予定日で年月にグルーピング後、各年月の合計金額を集計する完了予定日とフェーズでグルーピングし、各年月ごとフェーズごとの合計金額を集計する完了予定日で年月にグルーピング後、各年月の受注金額の最大値を集計する完了予定日で年月にグルーピング後、完了商談に占める成立/不成立商談の件数を集計する列を商談所有者、行を完了予定日でグルーピングして商談金額の合計を集計後、レコード件数を非表示にする完了予定日が2018年と2019年の商談を使用し、成立商談(=受注商談)の合計金額を同月比較できるようにグルーピングを工夫する行と列でグループ化する行を商談所有者、列を完了予定日でグルーピングして商談件数を集計する行を商談所有者と成立フラグ、列を完了予定日でグルーピングして商談件数を集計する行を所有者ロールと商談所有者、列を完了予定日と成立フラグでグルーピングして商談件数を集計する列を所有者ロールと商談所有者、行を完了予定日でグルーピングして成立件数と成立金額の合計を集計するグループ化した集計値同士で計算する商談所有者ごとの成約率(=成約商談件数/完了商談件数)を算出する商談所有者とフェーズで商談をグルーピング後、商談の合計金額を集計する。各フェーズの金額が、その所有者の合計金額に占める割合を算出する完了予定日が2018年と2019年の商談を使用し、成立商談(=受注商談)の合計金額の前年同月比を算出するバケット項目を使用して柔軟にグループ化する取引先の都道府県(請求先)を8地方区分にグルーピングする取引先の都道府県(請求先)を関東地方とその他にグルーピングする取引先の従業員が2000名以上を大企業、2000名未満をその他にグルーピングする商談の金額を0-50万/50万-100万/100万-200万/200万以上にグルーピングする商談のフェーズ1/2/3を商談初期、4以降をその他にグルーピングするグラフを使用する作成したレポートをグラフで表示する取引先所有者ごとの取引先件数(=レコード数)を積み上げ縦棒グラフで表示する。また取引先を都道府県(請求先)ごとに色分けする取引先所有者ごとの取引先件数(=レコード数)を縦棒グラフで表示する。また任意の値かつ赤色で基準線を表示する商談所有者ごとの商談件数(=レコード数)を縦棒グラフで表示する。また商談の金額を折れ線グラフとして追加する商談所有者で商談をグルーピングする。また商談の合計金額が50万円以下を赤、100万円以下を黄、それ以上を緑で表示する取引先所有者で取引先をグルーピングする。実行したレポートをダッシュボードに追加するその他の機能を使用する作成したレポートを別名でコピーする取引先所有者で取引先をグルーピングする。実行したレポートを別名保存する作成したレポートをエクスポートする取引先所有者で取引先をグルーピングする。実行したレポートをExcel形式でエクスポートする作成したレポートを定期的にメール配信する取引先所有者で取引先をグルーピングする。実行したレポートが毎週月曜日の午前9時に自分に配信されるように登録するレポートドリル(Quip版)はこちらレポート作成の応用編として『レポートを使いこなす裏ワザ 総集編』が公開されました。同タイトルの人気記事シリーズをわかりやすくまとめた資料です。ぜひお役立てください。
-
https://play.vidyard.com/2ws17oUCrGYkdTDs4vJfRv動画で紹介した各リンクは以下よりご確認いただけますSandbox プレビュー(ナレッジ)はこちらCSG公式XアカウントはこちらSalesforceの運用に関する重要なお知らせ(サクセスナビ記事)はこちら新機能Trailblazers分科会「リリースノートと仲良くなろう!読み方のコツ」はこちらオンラインコミュニティ「新機能Trailblazers分科会」へ遷移します。ご利用のSalesforceユーザーID・パスワードによるログインが必要です。「新機能Trailblazers分科会」にご参加いただいていない方は、ログイン後こちらから参加申請をお願いします。この記事で学べること次期バージョンアップに備える方法について知ることができますリリースノートの読み方のポイントを知ることができますSalesforceのバージョンアップって何?みなさまは、Salesforceのバージョンアップ(メジャーリリースと呼ばれる事もあります)について、ご存知ですか?普段の生活で、おそらく頻繁に利用しているインターネットの検索画面やカレンダーの画面などが突然変わる事に気づいた経験はあると思います。それと同じように、Salesforceも定期的に(年3回)バージョンアップ(進化)しています。例えば、2023年6月6日時点のバージョンは、Spring’23 でした。次のバージョンアップ(2023年6月11日)で、Summer'23になります。Salesforceを昔からご利用のお客様は、Classicの画面をご存知だと思います。Classicの時は、画面左上にロゴが表示されていたので、「あ。ロゴが変わった。バージョンが変わったのかな」と気付くこともあったかもしれません。Classicはこんな感じでした。懐かしいですね!Lightning Experienceでは、ログイン後、ホーム画面が表示される前にロゴが表示されるように変わりました。「知らないうちにバージョンアップが行われているなんて、何事だ!!」と怒らないでください。バージョンアップの日程は、バージョンアップの約1年前からTrust サイトのシステム状況ページ に公開されています。(詳細は、Salesforceのメンテナンスを知ろうをご確認ください)Sandboxプレビューって何?Salesforceには、年3回バージョンアップがあることをご紹介しましたが、じゃあ「どんな新機能が出てくるのか?」「便利になるのか?」「自分たちが使っている機能に影響はあるか?」など、色々事前に知りたいことがあると思います。システム管理者の方であれば、ユーザから「なんか画面変わりました・・・?」と聞かれて、慌てて調べる・・・という状況は避けたいですよね?Sandboxプレビューは、本番環境がバージョンアップをする前に、事前にプレビューができるサービスのことです。Sandboxプレビューの詳細については、Sandbox プレビューによる早期アクセス(Trailhead)をご確認くださいプレビューで何するの?じゃあ、プレビューでは、具体的に何ができる/何をすればいいのでしょうか。プレビューに参加する目的バージョンアップでは、新しい機能が追加されたり、既存機能が拡張されたりします。契約している製品に関する情報をリリースノートで確認して、実際の業務で使えそうな便利機能があれば事前に動作確認ができます。使い方の説明動画や資料を作成し、事前にユーザに共有することもできますね!また、開発をしている組織のシステム管理者の方は、バージョンアップ後に自分たちが開発した機能がきちんと動くか気になると思います。そんな時は、プレビュー対象のインスタンスにSandboxを作成しておく(※)ことで、本番のバージョンアップ前に、お客様が開発した機能の動作の事前検証を行っていただくことができるのです!(※)Sandboxプレビューの詳細については、システム管理者宛の製品コミュニケーションメールでお知らせします。製品コミュニケーションについては、製品およびサービスに関するお知らせ(ナレッジ)をご確認ください。 Salesforceでは事前検証していないの?Salesforceでは、本番環境のバージョンアップ前に各種テストに加えて、 Apex ハンマーというプロセスによってすべての Apex テストを自動的に実行します。(ハンマープロセスは組織を選択して実行するため、すべての組織で実行されるわけではありません)Salesforceでは、バージョンアップ前に、検出されたすべての問題を修正するよう努めています。詳細は、Apex 単体テストの開始(Trailhead)をご確認ください。お客様によるテストが必要な理由お客様固有の開発がバージョンアップの影響を受けていないか/想定どおりの動作をしているかを確認できるのは、お客様しかいません!テストをする際は、業務をする上で特に重要な機能を優先して確認をすることを推奨します。テストが必要な開発の例:Apexクラス、トリガ、Visualforceページ、Lightningコンポーネント、外部システムとの連携機能などテストで問題が見つかった場合は、同様の問題が既に報告されていないかをKnown Issuesサイトで確認します。同様の問題が無い場合は、早めに弊社テクニカルサポートへお問い合わせをいただくことで、本番環境がバージョンアップする前に対応ができる可能性が高くなります。※お問い合わせを頂く際は、事前に、その問題がSalesforceのバージョンアップによるものか、お客様のカスタムコードによるものかの切り分けをしていただけますよう、お願いします。詳細は、お問い合わせをする時のポイント (サクセスナビ)をご確認ください。さて、開発をしている組織にとって、Sandboxプレビュー期間を活用した事前テストが重要である点について、ご理解いただけましたでしょうか。ここからは、事前テストをする上で欠かせないリリースノートの読み方についてご紹介します。開発をしていない組織のシステム管理者の方も、リリースノートを参照して、便利な機能がないか確認しましょう!リリースノートの読み方Salesforceのバージョンアップ毎に公開されるリリースノートでは、製品の機能強化や新機能について簡潔に説明しています。リリースノートの種類リリースノートには、HTML 版とPDF 版があります。HTML版:検索や絞り込みで、必要な情報に最短でたどり着くことができます。また、使用される言語はブラウザの設定によって決まります。言語を変更するには、下部にスクロールして [言語を変更] をクリックし、言語を選択します。PDF版:全体を俯瞰して確認することができます。iPadなどのタブレットにダウンロードして、読書のような感覚でページをめくりながら新しい機能を探したいときにいいですね。HTML版の場合、以下で絞り込みができます環境Salesforce ClassicLightning ExperienceモバイルエディションEnterprise EditionUnlimited Edition など機能の影響有効(ユーザ)有効(システム管理者/開発者)システム管理者が有効化する必要ありSalesforceに連絡して有効化製品エリアセールスサービス などリリースノートに記載されている機能はすべて自動で使えるようになりますか?いいえ。機能毎に異なります。バージョンアップ直後に自動で(すべてのユーザ、もしくはシステム管理者や開発者のみに対して)有効化されて使えるようになるものもあれば、(ユーザが使えるようにするために)システム管理者が手動で有効化しなければならないもの、機能を有効化するためにサポートへご連絡を頂く必要があるものなどがあります。これらの情報はリリースノートの機能が使用可能になる方法と状況に纏められています。なお、機能によっては、バージョンアップ(直後ではなく)徐々に機能が有効化されて使えるようになるものもあります。その場合、対象機能のリリースノート詳細画面にその旨記載されます。リリースノートの日本語版リリースノートは、ほぼ毎週のように更新されており、更新内容はリリースノートの変更に追記されます。中にはリリース予定の機能の延期や(リリースノート公開時点では記載がなかった)新機能が追加されたり、機能に関する説明が追加されたりすることがあります。順次翻訳されますが、最新情報は英語のリリースノートを確認するようにしてください。※リリースノートの更新情報は、「Salesforce の運用に関する重要なお知らせ」(サクセスナビ)の中で、重要なものを抜粋してお知らせしていますので、ぜひご覧ください。リリースノートの内容リリースノートは、以下のような構成になっています。Salesforceをご利用中のすべてのお客様に関係する内容(みなさまにご覧頂きたい内容です)サポートされるブラウザSalesforce 全体 など製品/機能毎の内容(ご契約/ご利用中の製品/機能をご確認ください)Analyticsコマースカスタマイズ などリリース更新(みなさまにご覧頂きたい内容です)セキュリティに関する情報を含んでおり、期限が来ると強制的に有効化されるものがあります。リリースノートの使い方リリースノートのボリュームは年々増加しており、そのすべてを確認することは、日々の業務で多忙なシステム管理者のみなさまにとっては難しいと思います。まずは、上記太字にある(みなさまにご覧頂きたい内容)と(ご契約/ご利用中の製品/機能)について確認をしてください。その際、不明点が出てきたら、弊社テクニカルサポートへお問い合わせいただくことで理解の促進にお役立ていただくことができます。また、「知らないだけで、何か活用出来る機能は無いか確認したい」という場合は、機能が使用可能になる方法と状況から探して頂くのがお薦めです。機能が使用可能になる方法と状況には、提供予定の機能がリリースノートの構成に沿って纏まっています。そのため、自分でリリースノートを検索しようにも、「どのようなキーワードで検索すればよいかわからない」という方に最適です。一覧から興味のある機能や聞いたことがある機能を見つけたら、リンクをクリックして詳細説明を確認します。そして、「実際に試してみたい!」という時には、プレビュー中のSandboxでテストをすることができます!リリースノートの確認ポイントサポートされるブラウザSalesforceを利用するためにはブラウザが必要です。自社で利用しているブラウザが記載されているか(引き続きサポート対象であるかを)確認します。Salesforce全体すべてのユーザが毎日使っているであろう「検索」や(契約製品関わらず)使うと便利な「Salesforceアンケート」や「Your Accountアプリケーション」といったSalesforceのオススメ機能の更新情報が含まれます。未使用の便利機能が見つかる可能性がありますので、ぜひチェックしてみてください。AnalyticsAnalyticsには、「CRM Analytics」に関する情報だけでなく、みなさまお使いの「レポートとダッシュボード」の情報も含まれます。こちらも必見の内容です。カスタマイズ(コーディング不要な)ポイント&クリックでカスタマイズできる設定(「Lightningアプリケーションビルダー」など)が含まれます。こちらも多くのお客様にてご利用いただいている(Salesforceとしてもご活用いただきたい)機能に関する情報のため、確認することをおすすめします。開発Lightningコンポーネント、Apex、API、Sandboxなど、開発をしている場合は必見です。この情報と[リリース更新]を元に既存の開発機能に影響するものはないか確認し、テストを行います。モバイルモバイルアプリケーションやMobile Publisherをご利用のお客様はご確認ください。リリース更新特定の時期に強制的に適用される変更や設定変更の情報を記載しており、必読です。セキュリティ・性能・操作性に関わるデフォルト動作の変更や設定変更が含まれるため、[テスト実行]に対応している更新については、事前にSandbox環境で有効化し、その変更が自組織に与える影響範囲の確認をなるべく早めに実施することを推奨します。学習ツールSalesforce リリース準備状況戦略(Trailhead)Advanced Salesforce Release Readiness Strategies(Trailhead)メジャーリリースにおけるテストの考え方(Trailblazer Community)まとめ(チェックリスト)開発をしている場合に、本番環境のバージョンアップ前に、Sandboxプレビューを活用し、事前にテストをすることの重要性を理解しました。リリースノートをすべて確認するのは困難なので、すべてのお客様に共通する内容、現在使用している製品や機能に関する内容、リリース更新を中心に確認しましょう
-
Salesforceへ安全にアクセスするために知っておくべき情報〜多要素認証
最終更新日:2022/6/08昨年来の働き方改革や昨今のウィズコロナ時代のリモートワークの増加など、これまでと違った条件下での業務遂行を必要とされる声をあちこちで伺う機会が増えてきました。これまでの就業環境と変わることで関心が高まっているのが「 Salesforce への安全なアクセス」。特にサイバーセキュリティに関わる事案やニュースを日本でも目にする機会が増えてきており「安全性と利便性を確立する上で Salesforce で何ができるのか?」そんなご質問も増えてきている実感があります。そこで今回システム管理者の皆さまに、安全なアクセスを実現するために知っておいていただきたい情報をまとめました。ぜひこちらのサイトを定期的にご確認いただき、安全で安心できる業務環境を構築していきましょう。1.安全なアクセスを実現するための Salesforce とお客様の役割Salesforce に対する安全なアクセスと一言でいっても、その安全なアクセスは製品として何ができるのかなどの「提供されているもの」と、その製品をどう使うのかなど「提供されているものをどう使うか」の視点は欠かせません。この視点を、Salesforce が責任を持って提供すべきものと、お客様が責任を持って確認・判断・実行すべきもの、で表現したのが「Salesforceのセキュリティパートナーシップ」です。Salesforce がその提供する製品において安全なアクセスを実現するための機能を提供し、その機能の利用を判断いただけるような情報を提供し、ある場合にはその機能を標準設定(デフォルト)として提供するなどの提供者としての責任を果たしつつ、お客さまにおいて、それぞれのコンプライアンス基準やセキュリティ基準に準拠した機能を検討・適用・監視・維持していただく活動を通じて、始めて持続的な安全なアクセス環境が実現できる。そんな相互の協力が不可欠な取り組みを表現しています。2.境界防御の先にあるクラウド時代のセキュリティを考慮する [*2] [*3][*4]昨今のサイバー攻撃の方法の多様化や範囲の拡大の影響を考えると、最新のセキュリティ制御機能の理解と評価がお客さまにとってセキュリティ管理の上で重要性を増していることは間違いありません。特に業務システムのクラウドシフトが進むにつれて、従来の境界防御モデル (Firewall や VPN などで「信頼できる接続」によって社内・社外の境界を設けて、不正侵入や情報漏えいを防ぐモデル)だけでは安全性を担保しきれない環境に変わりつつあります。海外では今年 4 月に米国東海岸の 45% の住民に燃料を供給するパイプラインの操業がハッキングにより停止に追い込まれる事例が発生し、日本でもランサムウェアや VPN 環境での情報漏えいなど境界防御だけでは防ぎきれない事例が報告され始めています。この「すべてのユーザ・デバイス・アプリケーション・ネットワークが安全と言えず攻撃される可能性がある」状況に対応する「ゼロトラストモデル」が提唱され、それぞれの要素が脅威にさらされている前提でその防御のための対策が注目され始めており、Salesforce ではその対策要素の一つである IAM(Identity and Access Management) の強化を通じてお客さまに安全なアクセス環境を提供する取り組みを推進しており、その具体的な施策として多要素認証 (MFA : Multi Factor Authentication) の適用を利用規約上必須とし、推進しています。 この取組みの重要性は Salesforce とお客さまだけの関係において重要というものではなく「お客さまの顧客」、例えばCommunity Cloud や Commerce Cloud を通じて提供しているサービス利用者にあたる「お客さまの顧客やパートナー」向けにも安全性と利便性を両立したサービスを提供する手段として注目され始めています。また、多要素認証の推進については Salesforce の外に目を向けても、世間のトレンドとなりつつあります。例えば、先般アメリカではバイデン大統領が 2021/5/12 に連邦政府のサイバーセキュリティ対策として多要素認証及び暗号化を採用する大統領命令に署名をしました。併せて、Google 社が多要素認証のデフォルト化を検討したり、 Twilio 社も必須化のアナウンスを出すなど、海外のトレンドとしては多要素認証のデフォルト化が進んでいます。スプートニク 日本ニュース 2021年6月8日 通常の過失:職員のミスでコロニアル・パイプラインがクラッキングSecurity Magazine 2021年5月13日 President Biden signs executive order to strengthen U.S. cybersecurity defensesSecurity Magazine 2021年5月10日 Google wants to enable MFA by defaultTwilio BLOG 2020年12月3日 Twilio Account Login Change: Mandatory Two-Factor Authentication一方、日本においても 経済産業省が全国の企業におけるサイバー攻撃実態や被害事例とりまとめた情報に記載されているようなリスト型攻撃による不正ログイン事案の継続的発生とその対応策としてのセキュリティ強化策の示唆や、“ID・パスワードのみ利用可能な会員制サイトやクラウドメールアカウント等が、流出したID・パスワードのリストを利用した「リスト型攻撃」により不正ログインされる事案が継続的に発生”“ログイン機能に二段階認証や二要素認証を導入することでウェブサイトへのアクセスに関わるセキュリティを強化したり、個人情報の機微度に応じて分割して管理し、データへのアクセス権別に設定するなどのシステム構造の見直しが大切に。”情報処理推進機構の“情報セキュリティ 10大脅威 2021”の組織向けの第2位 標的型攻撃による機密情報の窃取にて指摘されている状況は、3位・4位・8位・10位の脅威と複合して、窃取されたユーザID・パスワードによる不正アクセスリスクは「信頼できるネットワーク環境下」においても増加しており、ログインユーザの保護の簡易かつ効果的な方法の一つとして多要素認証に注目が集まってきています。“企業や民間団体そして官公庁等、特定の組織から機密情報等を窃取することを目的とした標的型攻撃が継続して発生している。攻撃者は新型コロナウイルスの感染拡大による社会の変化や、それに伴うテレワークへの移行という過渡期に便乗し、状況に応じた巧みな手口で金銭や機密情報等を窃取する。”日本経済新聞 2020年8月24日 記事 VPN脆弱性対応、日本企業に隙「ゼロトラスト」不可欠日本経済新聞 2020年8月25日 記事 VPN情報流出、懸念されるリスクは?経済産業省 2020年6月12日 報告書 昨今の産業を巡るサイバーセキュリティに係る状況の認識と、今後の取組の方向性についての報告書を取りまとめました より 昨今の産業を巡るサイバーセキュリティに係る状況の認識と今後の取組の方向性について(概要版)(PDF形式:1,057KB)情報処理推進機構 2021年3月25日 情報セキュリティ 10大脅威 2021 併せて、弊社の外部ブログにも多要素認証の重要性について記事を投稿させて頂いております。こちらも併せてご参照下さい。不正ログインを99.9%防止「多要素認証」の重要性 3.現在の利用状況と利用可能なセキュリティ制御機能を理解し評価するSpring’ 22 時点で Salesforce が多要素認証の機能を提供可能な製品は、次の製品を含む、Salesforce Platform 上に構築あれたすべての製品: Sales Cloud、Service Cloud、Analytics Cloud、B2B Commerce Cloud、Experience Cloud、Industries 製品 (Consumer Goods Cloud、Education Cloud、Financial Services Cloud、Government Cloud、Health Cloud、Manufacturing Cloud、Nonprofit Cloud、Philanthropy Cloud)、Marketing Cloud—Audience Studio (旧 DMP)、Marketing Cloud—Pardot、Platform、Salesforce Essentials、Salesforce Field Service、パートナーソリューションB2C Commerce CloudHerokuMarketing Cloud—DatoramaMarketing Cloud—Email Studio、Mobile Studio、Journey BuilderMarketing Cloud—SocialMuleSoft Anypoint PlatformQuip 製品Tableau Onlineです。[*1]他のすべての Salesforce 製品でも積極的に多要素認証の機能の開発に取り組んでおり、他の製品で 利用可能になった時点でリリースノートにてお知らせする予定です。多要素認証やセキュリティ強化の対象となった機能については、各製品のリリースノートやヘルプ記事などを通じてその機能概要の説明や設定方法をご案内しておりますが、特に注力している多要素認証の概要や設定になどに関する情報はウェブセミナーや Trailblazer Community などを通じて英語だけでなく日本語でのガイダンス資料やデモ動画を提供し、お客さまの理解や評価に役立つ情報発信に努めています。参考リソースをご参照いただきご活用いただければと思います。4.適用・展開を計画する最新のセキュリティ管理と機能をお客さま環境に適用・展開する方法は、「製品機能の理解」「セキュリティ管理の現状把握」「適用タイムラインの決定」を行う事前準備、事前準備に基づいて「特権的ユーザ数の最小化」「パイロットユーザへの適用」「パイロットユーザからの学び」を行う試行段階、試行段階の教訓を踏まえた全社適用に向けた「役員コミュニケーション計画」「ユーザとのコミュニケーション計画」「変更管理計画」を策定するオーソドックスな段階的展開が実行における課題や計画の実現性を高めるうえで望ましいと方法と考えています。この計画に基づいてユーザへの「適用推進キャンペーン」など通じた適用推奨、その適用進捗を確認するため履歴設定やレポートやビューなどの監視設定、設定した監視情報のダッシュボード等を通じた定期的な適用状況監視により計画の進捗確認と適用促進を繰り返す事も不可欠の要素と言えます。これらの適用準備や展開監視を支援するツールとして「セキュリティ管理の現状把握」にはセキュリティ状態チェック機能、「監視設定」や「適用状況監視」には2FAダッシュボードなどがSales Cloud、Service Cloud、Platformなどで利用可能ですので、これらツールを利用することも忘れずに覚えておきましょう。セキュリティ状態チェック(ヘルプ記事)2FAダッシュボード(AppExchange)5.SalesforceへのアクセスにおけるMFA要件 [*2]認証ユーザの認証情報取得への攻撃が昨今さらに強くなっている環境における、安全なアクセスを担保する手段として2022 年2 月より Salesforce へのアクセス時に MFA を要件とする旨のご案内を 2021 年 2 月に配信させていただきました。このアクセス要件は、認証ユーザにおけるセキュリティを複数の認証要素を用いることで担保するソリューションおよび情報を、前述のセキュリティパートナーシップにおけるSalesforceの責任においてお伝えするものです。この MFA 要件は「UI経由でログインする Salesforce の Internal User」を対象(*1)に、Salesforce へのアクセス時に知っている情報 (ユーザ ID とパスワード) 以外の要素での追加認証 (Authenticator や Hardware Key など各個人が持っている情報など) を必須とする内容となっています。この対象ユーザの UI 経由のログインは、単純に Salesforce のログイン画面 (UI) にユーザ名とパスワードを入力する最もシンプルな形態の場合には、その入力後に持っている情報 (Authenticator や Hardware Key など)を利用して本人を認証する事を意図していますが、複数システムを利用されているお客様においては別システムにおける ID とパスワード認証を経てその認証情報を Token などの形態で Salesforce に連携させることでログインを完結させる SSO(Single Sign-On *2) を利用されるお客様も少なからずいらっしゃいます。この外部での認証情報をもって Salesforce にアクセスされているお客様においても、その外部認証時における多要素認証を実施いただいた上で Salesforce にアクセスいただく (前述のセキュリティパートナーシップにおけるお客様の責任に該当する内容) 事がセキュリティ担保の上で不可欠となりますが、その適用状況(外部認証における多要素認証の適用)に関しては現時点で弊社で判断可能な内容ではございません(*3) ので、弊社にてその準拠状況を監視ならびに制御するもの、できるものではなく、お客様のビジネスにおける安全性確保の観点においてご対応いただきたい内容と考えています。(*1) 組織外の認証ユーザとなる Experience Cloud の外部ユーザ、Chatter Free や外部 Chatter ユーザ、E-Commerce のユーザ、および認証が発生しないゲストユーザ、システム間連携のために利用される都度 UI ログインが発生しない API やIntegration 用ユーザは必須要件の対象外(*2) Reverse Proxy など代理認証も広義での SSO と定義される場合もありますが、SAML や OpenID Connect などによる外部認証を SSO と定義しており、代理認証は Salesforce への通常の UI 経由のログインとして扱われるため Salesforce 側での MFA が必要(*3) SSO で利用される OpenID Connect は、amr 属性 (Authentication Method Reference) でMFAの利用可否をSpring’21から Salesforce で識別可能。SAML においても将来的に AuthContext 属性によって MFA 適用された SSO を識別可能にする予定考慮事項本ブログは定期的に更新されます。毎月一度は必ずご確認ください。最後にいかがでしたでしょうか。今回ご紹介した Salesforce への安全なアクセスの基本知識については、Trailhead で学習することも可能です。検討の基礎知識の再確認の意味でも、こちらのモジュールを完了させておきましょう。Trailheadで自己学習ユーザ認証 / Identityの基本 / セキュリティの基本参考リソース [*1]Salesforceのセキュリティの基本(ヘルプ記事)Spring’21 IDとアクセス管理(リリースノート :更新)Salesforce セキュリティガイド(開発者ガイド)Salesforce 多要素認証のFAQ(ヘルプ記事 : 更新[*1] )Marketing Cloud の多要素認証に関する FAQ (ヘルプ記事)* MFA - Getting Started *(Trailblazer Communityの多要素認証のグループ : 英語)管理者向けガイド多要素認証(MFA)設定マニュアル (日本語)多要素認証の管理者ガイド(日本語)管理者向けのシステム管理者ガイド (日本語)Admin Guide to Multi Factor Authentication(English)動画Webセミナーの資料と動画(Trailblazer Community へのログイン要)2020年8月28日 開催 より安全にSalesforceにアクセスするための「多要素認証」の設定2020年9月25日 開催 Marketing Cloud 多要素認証 (MFA) の導入と設定Marketing Cloudの多要素認証の設定 (動画解説)多要素認証がアカウントへのアクセスを保護する仕組み (CCで日本語字幕選択可能)Salesforce Authenticator の概要(CCで日本語字幕選択可能)アクセラレータウェブセミナー[オンデマンド・アクセラレータ] Platform: 多要素認証 (オンデマンド録画 : New)資料[JP]Social Studio 多要素認証機能のご紹介信頼性の高いCommerce Cloudの設計 多要素認証の導入 ステップガイド改定[*1] Spring’22 での対応状況を踏まえて更新[*2] 2021年2月にご案内の”【重要】多要素認証への対応のお願い”の送信に基づく追記[*3] 海外の事例を追加 [*4] 弊社公開ブログ記事を追加
-
👤この文章の対象者👤主に、Marketing Cloud Engagementを使って施策を企画、実行、運用、改善を行なわれる方向けの情報となります。ただし、データ連携に関連する部分はシステム部門の方と連携していただく必要がある場合があります。必要な設定が環境に適用されたら、データ連携を行いましょう。Marketing Cloud Engagementにデータを連携する上で最も重要なのが、「コンタクトキー(連絡先キーとも呼ばれます)」です。コンタクトキーを決めたら、連携するデータを整理し、全ての顧客データに対してそのコンタクトキーが関連づけられるようにします。コンタクトキー(連絡先キー)を決めるコンタクトキー(翻訳ブレで連絡先キーと記載されることもあります。)とは、Marketing Cloud Engagementの中で顧客を特定するもので、全ての顧客に対してユニークな値を設定する必要があります。同じ値を違う複数の人に振り分けることはできません。コンタクトキーとして貴社でどんな値を利用するか、選択することができます。例えば、基盤システムで使っている顧客識別番号であったり、マイページにログインするためのログインIDのような値であることが一般的です。以下の図は、メール、モバイルアプリプッシュ(MobilePush)、SMSメッセージ(MobileConnect)を送信するにあたり、それぞれのチャネルで固有のデータテーブルを持ち、顧客(レコード)を管理している例です。「ABC002」というコンタクトキーにより、「Yamada Taro」さんのメールアドレスは「taro@sample.net」であり、DeviceIDは「463ADD312CAE」であり、Mobile Phoneは「818012345678」であることが特定できます。つまり、チャネルを跨いで同一人物を特定することができています。このように、ABC00*のようなコンタクトキーの値を決めるには、今後のチャネルやデータの拡張性を考慮する必要があります。(Emailのテーブルである「All subscribers」では「Subscriber Key」と表記されています。厳密には違うものですが、ここでは簡易性を重視して同じものと捉えていただいて問題ありません)メールアドレスをコンタクトキーにした場合、メールアドレス情報がない顧客(例えばLINEキャンペーンで獲得した顧客など)を登録する際にイレギュラーなコンタクトキーを登録することとなり、データが必要以上に複雑になり、運用にも大きな負荷をかける可能性があります。また、メールアドレスは登録後に変わる可能性もあるため、できる限りメールアドレスではなく企業で管理している値をコンタクトキーに選択したほうが良いとされます。また、MC ConnectでSales CloudやService Cloudなどと接続をしている場合は、CRM側で採番するSalesforce IDがコンタクトキーとして適用されます。これにより、クラウドを跨いで同一人物を特定することができます。さらに詳しくコンタクトキーへの理解を深めたい方は以下のリソースをご確認ください。参考:Marketing Cloud Engagement ポケットガイド (1) - セットアップ編エキスパートコーチング:「データと連絡先の管理」Salesforce Help: 「Marketing Cloud の購読者キー」Salesforce Trailhead: 「Marketing Cloud Engagement 連絡先管理」Salesforce Trailhead: 「データモデルの設計」データ取り込みから、送信、結果分析までの流れを把握コンタクトキーが決まったら、データの中心核が決まったも同然です!ここから顧客に関係するデータ(例えば、名前、メールアドレス、住所、会員ランク、保持ポイント、購買情報など)や、製品やサービス(製品カタログ、画像URL、価格表など必ずしも顧客に紐づかないデータも)など、必要なデータをMarketing Cloud Engagementに連携する準備を始めましょう。以下の図は、大まかなMarketing Cloud Engagementの利用の流れです。取り込むデータを決める (Data-In)Marketing Cloud Engagementを使って、1:1コミュニケーションをしたい!という場合には、多くの場合、上図「リスト抽出」にあるように、条件に当てはまる顧客を取り出して、送信対象となる顧客を抽出する必要があります。このため、データを連携する際には、運用を意識してデータを連携する必要があります。例えば、顧客の過去の購買データを参照して、Aという製品を1000円以上、1年以内に購入した、関西地方の人で、明日が誕生日の人にだけ、特定のメールを送りたいとします。この時、購入製品、購入金額、最終購入日、居住エリア、誕生日がコンタクトキーに紐づいて特定できるようになっている必要がありますが、すべてがバラバラのデータエクステンションに入っていたら(実際にはそんなことはないと思いますが!)、SQLを書いてデータを繋ぎ合わせる必要があります。これを毎度行うには、担当者のスキルによっては運用に負荷がかかる可能性があります。これが、もし3つまでのテーブルであったら、SQLを書かなくてもデータフィルターを使ってデータを取得することができ、SQLを書くことのできない方が運用担当になっても、継続することができます。このように、セグメントなどに使う重要なデータは利用しやすい状態で連携をすることが非常に重要となります。また、最近ではSalesforce Data Cloudのように、Marketing Cloud Engagement外部で抽出をして、Marketing Cloud Engagementに連携するケースもあります。どこで抽出作業をするのが良いかは、データの持ち方や運用方法によって最適解が異なりますので、運用と将来の拡張性を考慮してご検討ください。データを取り込む方法として、主要なデータインポート方法 及び Salesforce製品連携の方法を以下にご紹介いたします。MC Connect Sales CloudやService CloudなどからCRMデータを連携します。参考本はじめてガイド:3-2 アカウントの設定Salesforce Help: 「同期データソースの実装のベストプラクティス」インポートウィザード (手動) データエクステンションに直接データを手動インポートします。参考Salesforce Trailhead: 「購読者データのインポート」Salesforce Help: 「Marketing Cloud データエクステンションへのデータインポート」インポートアクティビティ(Automation Studioを使った自動化)SFTPにあるファイルを特定の時刻、またはSFTP上の特定の場所にファイルが置かれたら、指定したデータエクステンションにインポートします。参考Salesforce Help: 「外部ファイルを使用したリストまたはデータエクステンションの更新」Data CloudData Cloudで作成したセグメントを有効化して、データエクステンションに取り込みます参考Salesforce Help: 「Marketing Cloud 有効化対象の作成」PersonalizationPersonalizationのデータをデータエクステンションに取り込みます参考Salesforce Help: 「Integrate Personalization with Automation Studio」(英語)APIデータ連携を行うために、RESTとSOAPの両方を用意しています。参考Salesforce Trailhead: 「Marketing Cloud Engagement API」Salesforce Developers: 「Marketing Cloud Engagement APIs and SDKs」本はじめてガイド:3-2 アカウントの設定リストの抽出について、さらに理解を深めたい方はこちらのリソースがおすすめです。エキスパートコーチング:「メールのセグメント化の設定と自動化」Salesforce Trailhead: 「セグメンテーションツールの概要」Salesforce Help: 「SQL クエリアクティビティを使用したデータの取得とセグメント化」Salesforce Trailhead: 「SQL を使用したデータのクエリ」Marketing Cloud Engagement上で生成されるデータを把握するMarketing Cloud Engagementで生成されるデータとは、なんでしょうか。それは、主にメールなどを送信した結果データです。例えば、送信したメールの開封数やクリック数、または特定の顧客が開封したメールやクリックしたリンクなどです。その他、様々なログも生成、格納されています。Marketing Cloud Engagementの画面上から確認できるものもあれば、SQLを使って呼び出す必要のあるデータもあります。以下に挙げたポイントは機能の一部であり、すべてを網羅しているわけではありませんが、それぞれの特色を簡単にご紹介します。まずは、配信結果の確認方法5つをご紹介します。レポート:施策の結果を日々確認し、報告や改善に使うことができます。複数の送信を1画面で確認可能です。Analytics Builder > Intelligence Report予め用意されたダッシュボードを使って、メール、MobilePushなど複数チャネルからの送信に関するデータを確認することができます。ジャーニーごとにバージョンと送信アクティビティの結果を一元管理することもできます。ピボットテーブルを使って、比較的柔軟にレポートを作成することもでき、カスタム指標などにも対応しています。レポートをスケジュール配信するなどしてエクスポートが可能です。Intelligent Report Advanceではクエリなどで、顧客個別のデータを確認することもできます。Analytics Builder > Reports (2024年4月現在Hyperforce版ではご利用いただけません)テンプレート化(「カタログ」と呼ばれています)されたフォーマットのレポートの抽出条件を選択し画面表示、またはファイルへの出力でデータを確認します。トラッキング:シンプルな画面でメール送信の結果を確認することができます。1画面で1送信の結果を確認します。Email Studio > Email > トラッキング送信ジョブごとに、送信数や各バウンス、到達数、開封数、クリック数、クリックされたリンク一覧などを確認することができます一部のデータにおいて、CSVなどで手動エクスポートすることができます標準トラッキングJourney Builder > Automation Studioクエリをかかずに、Automation Studioの機能を使ってトラッキングデータを抽出し、SFTPへのファイル出力を行います。ファイル形式や含む項目などは予め決まっており、その中で少しカスタマイズをすることができます。さらに自由度の高い形式で抽出を希望の場合は、下記の「データビュー」から抽出します。データビューJourney Builder > Automation StudioクエリアクティビティでデータテーブルからSQLでデータを取得し、データエクステンションに格納します。その後、データエクステンションをSFTPにエクスポートすることができます。複数のデータビューから組み合わせて自由にファイルの構成を行うことができます。API上記機能について、さらに理解を深めたい方は、以下のリソースがおすすめです。エキスパートコーチング:「レポートとトラッキング」Salesforce Help:「Marketing Cloud でのデータ収集のベストプラクティス」Salesforce Help: 「Automation Studio でのデータエクステンションの抽出」Salesforce Trailhead: 「レポートの実行と結果のトラッキング」Salesforce Trailhead: 「Intelligence Reports for Engagement」Salesforce Trailhead: 「SQL を使用したデータのクエリ」続いて、配信した結果からEinsteinが生成したデータや、ログのご紹介です。Einstein Engagement Scoringが生成するデータEinstein(機械学習)が顧客ごとにエンゲージ状況に基づいて各顧客のエンゲージメントスコアを計算し、該当のデータエクステンションに格納します。エクスポートも可能です。Einstein Engagement Scoringについて理解を深めたい方は以下のリソースがおすすめですエキスパートコーチング:「Einstein 機能概要」Salesforce Trailhead: 「Einstein Engagement Scoring in Marketing Cloud Engagement」送信ログメール送信時に生成される動的な情報をデータエクステンションに格納することができます。送信ログについて理解を深めたい方は以下のリソースがおすすめですSalesforce Trailhead: 「Marketing Cloud Engagement の送信ロギング」Salesforce Trailhead: 「送信ログを使用したデータの収集」● ● ●「活用7ステップ」全体に戻りたい場合はこちら
-
ウェブセミナーシリーズ「Salesforce まずはこれだけ」
「Salesforce のシステム管理者に任命されたが、機能がたくさんあってどこから使い始めたら良いかわからない」「前任者から引き継いだが、現在どういう設定になっているのか把握できていない」このように日々 Salesforce で業務をしていただく上でお悩みのシステム管理者の方は多いのではないでしょうか。このウェブセミナーシリーズでは、「まず、これだけは抑えて欲しいポイント」をSalesforce サポートエンジニアが解説しています。最新の動画レポート徹底活用術 -初級編-https://play.vidyard.com/giwLMvUTJS4BZh2KCVwZS2・レポート機能の概要・レポートタイプの選定・検索条件の設定・列/グルーピング項目の設定・デモンストレーション・よくあるお問い合わせ資料はこちら第1弾:システム運用編https://play.vidyard.com/7UPKKJwG5ZSpyeHFFA7Dfa・データマネジメントのススメ ・データバックアップのススメ資料はこちら第2弾:データ活用編https://play.vidyard.com/qSapdwftuiiut3oGfVACCN・レポート/ダッシュボードの活用 ・レコードアクセス権資料はこちら第3弾:使いやすさ向上につながる設定https://play.vidyard.com/Q94kaTfYyKoY78pq1mt1zR・レイアウトのカスタマイズ・Sandbox / 変更セット資料はこちら第4弾:自動化への第一歩https://play.vidyard.com/F6cfd6saDc5HjbvzVPwVC4・数式、積み上げ集計、フローの説明 ・デモを使った各機能のユースケースの紹介 ・各機能を使い分けるポイント資料はこちらこれであなたもフローマスター~フロー初心者編https://play.vidyard.com/YftXqUxninBKpEqKNPVFza・フロー概要・レコードトリガフローのデモ・画面フローのデモ資料はこちらフロー初心者 総まとめ編https://play.vidyard.com/cT1fW2xQBasQJqQCFrEuFC・フローの概要説明・デモ形式でのレコードトリガフローのご紹介・フローの学習についてロードマップをご紹介資料はこちら第5弾:メール到達率の向上/レポートについてhttps://play.vidyard.com/RXvkk1tjRvf5DSobCiML43・なぜ到達率の向上が必要か ・到達率を向上させる方法 ・到達率の確認方法資料はこちらレポート徹底活用術 -初級編-https://play.vidyard.com/giwLMvUTJS4BZh2KCVwZS2・レポート機能の概要・レポートタイプの選定・検索条件の設定・列/グルーピング項目の設定・デモンストレーション・よくあるお問い合わせ資料はこちら関連リソース次回以降の開催については日程が決まり次第、イベントカレンダーに掲載いたします。また、テクサポ日本のページでもご案内いたします。