“������������������”の検索結果
-
この記事で学べること 商談スコアの更新履歴を保存する設定方法概要商談スコアの更新履歴の取得は以下に役立ちます。商談開始から完了までどういうスコア遍歴をしているか、幅が広すぎる更新が多すぎないかなどが確認でき、スコアの特徴や信用度を決める時に役立ちます。スコアの活用時、スコアが良くなったのか、悪くなったのかなど、変化量を取得する時に役立ちます。商談スコアは、項目更新履歴では更新履歴を取得できません。商談スコアの履歴をカスタムオブジェクトに保持して評価する方法をご紹介します。なお、本設定を一定期間だけではなく、常時有効化する場合は、商談数によってはストレージを圧迫する可能性があるためデータの削除方針もご検討ください。設定手順商談オブジェクトに以下項目を作成します。(商談完了時のスコアを保存しようにて作成済みの場合不要です)「商談スコア(コピー)」項目 :商談スコアを数式参照する数式項目商談スコア履歴を保存するカスタムオブジェクト「商談スコア履歴」を作成します。自動化機能のフローを活用し、毎日自動的にスコア変化を取得します。商談のレポートを作成し、スコアの変化量を一覧で表示します。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時間のフォローアップセッションをリクエストいただくことが可能です。(動画は誰でも閲覧可能です)エキスパートコーチング ▶レポート&ダッシュボード クイックスタートエキスパートコーチング ▶ レポート&ダッシュボード レベルアップ活用ステップ全体に戻る場合は、こちら
-
この記事で学べること スコア精度を良くするために実施できること自社独自の予測モデル作成の検討商談スコアの値を精度の良いものにするには商談スコアの値を確認し、まだ活用できるようなレベルでスコアが出ていないと感じた場合、何を行うべきでしょうか。Einstein 商談スコアリングは月に一度自動でAIモデルを再学習してくれます。そのため、基本的には複雑な設定はせずにそのまま使い続けていくだけで、徐々に精度が良くなります。一方で、過去の商談関連データをもとにスコアを出力しているため、データの質が低かったり量が少ないと良い精度は得られません。そのためスコア値をよくするためには、商談の項目整備・運用の整備・入力定着が必要不可欠になります。では、具体的な2つの改善アプローチをご紹介します。1.Einstein商談スコアリングが考慮するデータを限定するEinstein(AI)が考慮する商談のレコードや項目を絞り込むことで、商談スコアを改善するアプローチです。Einstein(AI)が考慮するデータからイレギュラーな商談レコードや、考慮する必要のない商談カスタム項目を除外します。この除外の設定は「設定>Einstein商談スコアリング」から商談スコアを再設定することで指定ができます。レコード除外設定画面:項目の除外設定画面(カスタム項目のみ):除外する対象の具体例・通常の営業サイクルと違う商談レコードを除外する・商談完了後に入力するデータ項目を除外する2.商談の入力項目や運用ルールを見直す日々の入力内容や運用を見直すことで、今後蓄積するデータを整え、商談スコアを改善していくアプローチです。なお、このアプローチは商談スコアを活用中にも必要なアプローチです。入力や運用のルールが徹底されていないと、今後スコアの精度が悪くなる可能性もあります。以下を是非ご確認ください。まず、以下の項目設定の確認を行い、Salesforceに蓄積されるデータをより良いものにしていきましょう。項目整備は以下リソースも参考としてください。【サクセスナビ】商談を入力、更新する【サクセスナビ】入力ミスをなくし、データの精度を高めよう【サクセスナビ】入力を簡略化する機能を活用して、手入力の時間を減らそう次に、各ユーザの方にしっかりと情報を入力いただけるよう、以下の点を確認し、入力サイクルを作っていきましょう。商談情報の入力・更新ルールを設定・見直す1週間の運用ルールを設定・見直す入力したデータを可視化し会議などで活用することで、更なる入力を促す運用ルールの整備や定着化について、以下情報も参考としてください。【サクセスナビ】Salesforceを組織で定着させるために【サクセスナビ】定着化を早期に実現するためのポイントを知る【サクセスナビ】定着化のための指標を可視化するいかがでしょうか?商談スコアをより良いものにしていくアプローチをご紹介しました。ここまでの内容を踏まえ、ビジネス上の特性や業態によっては、商談スコアでは精度の良いスコアにはならないのではと感じる方もいるかと思います。その場合は以下のトピックを参照ください。自社独自の予測モデル(受注確度予測)を作る商談スコアは参照するオブジェクトが決まっています。重要な情報が別のオブジェクトにまたがっている場合は、商談スコアがうまく商談確度を表現できない場合もあります。このような場合は、「Einstein 予測ビルダー」※や「Einstein Discovery」※を活用し、自社独自の予測モデルを作ることをご検討ください。※Einstein 予測ビルダー: Enterprise Edition 以上のお客様は1個のモデル有効化が可能です。※Einstein Discovery:ご利用にはライセンスが必要です。自社で利用できるかご確認の上ご検討ください。Einstein 予測ビルダーの設定は以下リソースをご活用ください。Einstein 予測ビルダー(ヘルプドキュメント)エキスパートコーチング▶︎Einstein 予測ビルダークイックスタート:Einstein 予測ビルダーの設定方法を動画にて解説しております。動画は誰でも視聴可能です。また、PremierまたはSignature Success Planをご契約のお客様は動画の内容でご質問がある場合は、Salesforceエキスパートとの1時間のフォローアップセッションをリクエストいただくことが可能です。活用ステップ全体に戻る場合は、こちら参考情報Einstein 商談スコアリングの設定に関する考慮事項(ヘルプドキュメント)Einstein によって商談にスコアが付けられる方法(ヘルプドキュメント)
-
この記事で学べること商談を完了フェーズに更新時、スコア値を保存する設定方法概要商談スコアが実態を反映しているか評価するシンプルな方法が、商談結果と商談スコア値を比較する方法です。商談成立時にスコアが高く、失注時にスコアが低いとこが確認できればスコアの信頼度が上がり、活用方法のアイディアも多く出てくるかと思います。ただ、商談スコアは、商談が完了ステータスになると、スコア値がクリアされるため、デフォルトでは上記の比較はできません。そのため、商談完了時のスコアをカスタム項目に保持して評価する方法をご紹介します。設定手順商談オブジェクトに2つの項目を作成します。「商談スコア(コピー)」項目 :商談スコアを数式参照する数式項目「最終スコア」項目 :商談が完了時スコアを保存する数値項目自動化機能のフローを活用し、「最終スコア」項目に商談完了時の商談スコアを保存します。商談のレポートを作成し、「最終スコア」の完了フェーズ毎の中央値や平均値を集計します。1.項目の作成設定>オブジェクトマネージャ>商談>項目とリレーション>新規のボタンから以下2項目を作成します。なお、作成する2項目は、Einstein 商談スコアリングの設定で、分析対象項目から外すことをお勧めします。「商談スコア(コピー)」項目作成「数式」項目とし、商談スコアを参照させます。(数式:OpportunityScore.Score)※フローで商談スコアを直接参照できないため、数式項目を作成します。「最終スコア」項目作成:商談完了時にスコアを保存するための項目です。「数値」項目で作成します。2.フローの作成商談完了時に、「商談スコア」を「最終スコア」項目にコピーします。設定>フロー>新規作成 から新規フローの画面を立ち上げます。「レコードトリガフロー」を選択します。「開始を設定」の画面の設定を行います。オブジェクト:「商談」を選択します。トリガを設定:「レコードが更新された」を選択します。エントリ条件:条件の要件:いずれかの条件に一致(OR)を選択し、皆様の環境の商談が完了ステータスのフェーズ条件を指定します。(※完了フラグでの設定ではなく、フェーズで設定ください)例:項目:フェーズ(StageName),演算子:次の文字列と一致する,成立(ClosedWon)例:項目:フェーズ(StageName),演算子:次の文字列と一致する,失注(ClosedLost)更新されたレコードでフローを実行するタイミング:「条件の要件に一致するようにレコードを更新したときのみ」を選択します。フローを最適化:「高速項目更新」を選択します。「完了」をクリックします。「+」から「レコードを更新」を選択します。レコードを更新画面が開くため以下の設定をします。表示ラベルとAPI参照名:任意の文字列を入力します。更新するレコードを検索してその値を設定する方法:「フローをトリガした商談レコードを使用」が選択されていることを確認します。(変更なし)検索条件を設定:なしであることを確認します。(変更なし)商談 の項目値を レコード に設定:項目:項目作成で作成した「最終スコア」の項目を選択します。値:「$Record__Prior」を選択し、項目作成で作成した数式項目「商談スコア(コピー)」を選択します。「完了」をクリックします。補足:$Record__Priorはフローをトリガしたレコード(今回は完了フェーズに更新された商談レコード)の更新前の値をとることができます。ここでは完了時にクリアされる前の商談スコアの値を、商談スコア(コピー)項目を利用して取得しています。これで設定は完了です。全体像は以下のようになります。画面上部の「デバック」ボタンを押してテストをして見ましょう。デバック画面で、「商談」項目でテストする商談を選びます。すると、下に項目が出力されるためフェーズを「成立」に更新して実行します。「最終スコア」に値がスコア値に更新されているかデバック上で確認します。(下記例では58が格納されました)十分テストし、フローを「有効化」したら設定は完了です。3.レポートの作成商談完了時のスコアを保持する設定の後は、商談のレポートを作成し、成立時と失注時の商談スコアを集計します。以下の流れでレポートを作成します。レポート>新規レポート>商談のレポートを選択します。検索条件を設定します。商談状況:完了最終スコア(上記で作成した項目)が空白と一致しない対象適宜、完了予定日などで期間を絞るアウトラインを指定します。グループ:フェーズ項目列:最終スコア(上記で作成した項目)最終スコア列の▼から、「集計」を選択し、平均または中央値を表示させます。おつかれさまでした。この内容から以下などで活用してみてください。スコアの値の確認(実際の受注/失注時にどのようなスコアになっているか)に活用商談スコア運用開始後のスコア状態の把握(定点観測)に活用参考:フローやレポート・ダッシュボードの学習リソース今回設定に利用したフローやレポートダッシュボードの機能をもっと知りたい方は、以下のリソースをご活用ください。フローをいちから学びたいフロー初心者向け学習リソースまとめ:フローの機能を学ぶことができるコンテンツのまとめ記事になります。エキスパートコーチング ▶フローによる プロセスの自動化:エキスパートがフローの使い方をご案内いたします。PremierまたはSignature Success Planをご契約のお客様はSalesforceエキスパートとの1 対 1 のセッションにお申し込みいただくことが可能です。レポートダッシュボードをもっと学びたい以下2種類の動画にて活用方法を解説しております。また、PremierまたはSignature Success Planをご契約のお客様は動画の内容でご質問がある場合は、Salesforceエキスパートとの1時間のフォローアップセッションをリクエストいただくことが可能です。(動画は誰でも閲覧可能です)エキスパートコーチング ▶レポート&ダッシュボード クイックスタートエキスパートコーチング ▶ レポート&ダッシュボード レベルアップ活用ステップ全体に戻る場合は、こちら
-
この記事で学べること スコア値を確認するレポート設定方法概要スコア値は過去データの質や量によって精度が変わってきます。各フェーズでスコアを集計し、どのようなスコア値が出力されているか、スコアがおおよそ実態を反映しているかを確認しましょう。たとえば、商談の終盤フェーズのスコア中央値が他のフェーズよりも高くなっていることが確認できれば、信用度や活用方法を考えるヒントとなります。なお、商談の進行が早い業界など、フェーズと対応させてもスコアが評価できない場合もありますので、その場合は他の確認方法も参考としてください。確認手順商談のレポートを新規作成します。・商談スコア項目の集計(平均、中央値、最大、最小)を表示します。・商談スコアのバケット項目を作成し、スコアがないもの、スコアのレンジごとのレコード件数を見れるようにします。(任意)必要に応じてダッシュボードに配置します。1.商談レポートの作成商談のレポートを作成し、フェーズ毎の商談スコアを集計します。以下の流れでレポートを作成します。レポート>新規レポート>商談のレポートを選択します。検索条件を設定します。・全ての商談・完了予定日:常時・商談状況:進行中アウトライン・グループ:フェーズ・項目列:商談スコア と最低限の項目商談スコア列の▼から、「集計」を選択し、平均または中央値を表示させます。列の▼から「バケット列を追加」を選択し、スコアをバケット分けします。「レポートのからの商談スコア値は0として処理します」にチェックし、0.1より小さいNullのバケットを作成し、25レンジでバケット分を行います。(さらに細かく分けても問題ございません。)作ったバケット項目をグループに追加します。2.必要に応じてダッシュボードに配置おつかれさまでした。この内容から以下などで活用してみてください。スコアがついていないレコード数の割合から商談スコアを活用できるかの判断フェーズ別のスコアの値の平均値/中央値を確認し、スコア値が実態を反映できているかの判断フェーズ別のスコアレンジの割合を確認し、スコア値の信用度を評価グループに別の項目を指定し、他の切り口でもスコアを評価参考:レポート・ダッシュボード機能の学習リソース今回設定に利用したレポート・ダッシュボードの機能をもっと知りたい方は、以下のリソースをご活用ください。レポートダッシュボードをもっと学びたい以下2種類の動画にて活用方法を解説しております。また、PremierまたはSignature Success Planをご契約のお客様は動画の内容でご質問がある場合は、Salesforceエキスパートとの1時間のフォローアップセッションをリクエストいただくことが可能です。(動画は誰でも閲覧可能です)エキスパートコーチング ▶レポート&ダッシュボード クイックスタートエキスパートコーチング ▶ レポート&ダッシュボード レベルアップ活用ステップ全体に戻る場合は、こちら
-
この記事で学べること 具体的なスコア確認の流れスコアを確認するための設定例スコア値が表示されたら、どのようなスコアがついているか確認しましょう。商談スコアは皆様の環境のデータによって精度が変わります。活用検討に向けて、自社の商談スコアの状態を確認・評価します。なぜスコア値を確認するのか皆様、新しい道具を使う時、まずなにを行いますでしょうか。これに使える/使えない、使いやすい/使いづらい...等、まずは道具がどう使えそうか確認するかと思います。商談スコアも同じです。スコア値がどうついているかが明確でないと活用方法(どう使うか)はなかなか決まりません。そのため、活用方法を決める前に、「どのようなスコアがついているか/ついてないか」「どう使えそうか」を明確にします。スコアを確認する流れスコアは以下の流れで確認していきます。1:確認準備をしてスコアを確認する2:確認した結果を書き出してスコアを評価するでは、流れに従ってスコアを確認していきましょう。1:確認準備をして、スコアを確認するまず、スコア確認のため、集計レポートやダッシュボードを作成して、スコアを確認していきましょう。スコアを色々な角度で確認し、どのような値を取っているか確認します。具体的な確認方法の例として、Level.1〜3に分けて確認例をご紹介します。活用時にも便利に使える設定を含みますので、ぜひご確認ください。【Level.1 各フェーズのスコア分布を確認する】フェーズは多くのお客様で、商談の確度・進行を表す指標としてお使いいただいているかと思います。そのため、進行の目安である各フェーズごとに、スコアがどうついているか、中央値がどうなっているかを確認します。確認観点特定のフェーズでスコア値に偏りや異常があるか終盤のフェーズではスコアの中央値が高くなっているか(フェーズ進行と受注確度が紐付いているフェーズ管理の場合)詳しい設定と確認方法を商談フェーズ毎のスコアを集計しようからご確認ください。【Level.2 商談完了時のスコア値を確認する】実際の商談完了時(受注/失注時)に商談スコアがどのような値を取っているかを確認します。自動化機能のフローを使って商談完了直前のスコアを保存し、一定期間、確認期間を設けて期間中に完了した商談を対象にスコアを確認します。確認観点受注時のスコア平均/中央値が高く出ているか失注時のスコア平均/中央値が低く出ているか失注時と受注時のスコアの差分はどのくらいか、十分な差異があるか詳しい設定と確認方法を商談完了時の商談スコアを保存しようからご確認ください。【Level.3 スコアの更新履歴を確認する】商談スコアの変化の履歴を残し、値の更新頻度や更新幅を確認します。自動化機能のフローを使ってスコア履歴の保存設定を行い、一定期間、確認期間を設けて期間中の更新履歴を確認します。確認観点スコアが商談完了までにどの程度更新されているかスコア値の更新幅が大きすぎるなど問題がある更新に偏っていないか詳しい確認準備設定と確認方法を商談スコアの変更履歴を保存しようからご確認ください。2:確認した結果を書き出し、スコアがどう使えるか評価する続いて、確認した結果を書き出し、スコア値の評価を行います。自社の商談運用特性を加味し、評価しましょう。また、評価結果が次のステップでの活用方法の検討に役立ちますので、しっかり評価結果を書き出しておきましょう。具体的なサンプルとして、上記Level1〜3の設定で確認した結果例と評価例をご紹介します。サンプルスコア値の確認とその評価ができたら、次のステップに進みましょう。補足:スコア値がいまいちの場合スコアの確認・評価した結果、スコアが期待ほどうまく出ていない場合、スコアの精度をより良くする必要があります。商談スコアの元になるのは、過去の商談関連データです。スコアをよくるすために重要となる、項目整備・入力促進・定着化については以下を参照ください。スコアの値を精度の良いものにするには活用ステップ全体に戻る場合は、こちら参考情報Einstein 商談スコアリングの設定に関する考慮事項(ヘルプドキュメント)Einstein によって商談にスコアが付けられる方法(ヘルプドキュメント)
-
この記事で学べること 商談スコア有効化の具体的な設定手順商談スコアの有効化まずは商談スコアの有効化の設定手順をご説明いたいます。Salesforceの設定>「支援付き設定」を選択し、商談スコアの「設定」部分をクリックします。※「支援付き設定」が見つからない場合は、サポートにお問い合わせください。画面に従って設定を進めます。スコア算出に考慮したくないレコードがある場合「Einsteinで考慮する商談は?」で除外します。スコア算出時に考慮したくない項目は「Einsteinですべての商談項目を考慮しますか?」で除外します。Einstein活動キャプチャの活動データを含めるかを選択し、設定を完了します。設定後、スコアがつくまでに最大48時間かかります。時間をあけて、商談に商談スコアに項目が表示されているか、スコア値が出ているか確認します。つづけて、商談スコアの項目が商談に出てこない場合は、商談画面や商談のリストビューに商談スコアを表示させます。商談スコアを表示商談スコア有効化後、画面などに商談スコアを表示させましょう。商談画面に商談スコアを表示設定>オブジェクトマネージャ を開き、「商談」オブジェクトを選択します。左のバーから「ページレイアウト」を選択し、商談に適用しているページレイアウトを選択します。「商談スコア」項目を任意のエリアに配置して「保存」を選択します。商談レコードを開き、再読み込みを行い、レイアウトに「商談スコア」が追加されていることを確認します。リストビューに商談スコアを表示商談スコアを表示したいリストの歯車マークから「表示する項目を選択」を選択し「商談スコア」を追加します。48時間以上たっても商談スコアがつかない場合は以下のリソースを参考としてください。データが少ない場合は、データが溜まるまで期間をおいて利用を開始しましょう。Einstein 商談スコアリングの設定に関する考慮事項Einstein によって商談にスコアが付けられる方法スコア値が確認できたら、次のステップに進みましょう。活用ステップ全体に戻る場合は、こちら
-
まずは商談スコアの機能についてご紹介します。この記事で学べること Einstein 商談スコアリングの概要Einstein 商談スコアリング活用ステップの全体像Einstein 商談スコアリングの活用シーン商談のAI機能を知っていますか?デジタル化が進んだ現代社会で、私たちは膨大なデジタル情報を取り扱っています。大量のデータを扱う上で情報を分析し活用できる形に落とし込む様々なAIは、私たちに欠かすことのできないツールとなってきています。Salesforceにも多くのAI機能があり、その中の一つとしてSales Cloudをご利用の多くの皆様※に使っていただける Einstein 商談スコアリング という機能をご紹介します。(以降、商談スコアと記載する場合があります)※2023/1時点:SalesCloud Enterprise Edition以上の環境でお使いになることができます。Einstein 商談スコアリングは、過去の完了商談を分析し、進行中商談の確度を1~99の指標でスコアリングします。加えて、スコアに最も寄与した要因 (プラスとマイナスの両方) を表示します。いわば分析アシスタントのように、皆様に変わって過去の商談データを分析し、進行中の商談を評価します。商談スコアの利用を検討するにあたって商談スコアは過去の商談データを分析してスコアを出します。そのため、精度の良い商談スコアにするには多くの過去データ(成立および不成立商談データ)が必要です。また、業界特性や商談特性により、商談の成立・不成立の要因が外部要因(Salesforceの中にない情報や商談関連データとは別の情報の要因)が多い場合、データが多くあったとしてもスコアの精度が高まらない可能性もあります。そのため、自社のSalesforce環境のデータ量や商談特性などに応じて商談スコアの活用検討を始めることをおすすめします。自社の環境で十分なデータがあるかを確かめるためには、こちらのEinstein準備状況評価ツールにアクセスし、Sales Cloud Einsteinから “I have an active Salesforce account” を選択し、評価を行いたいSalesforce組織でログイン認証をしてただくと、Einsteinの利用における組織のデータ準備状況と期待できるROIレポートを取得できます。また、データ要件も参考としてください。Einstein 商談スコアリングの設定に関する考慮事項(ヘルプドキュメント)もちろん、上記は一例です。商談スコアを設定して実際に自社で活用できるかは、後述の商談スコアの詳細や活用ステップを参考に検討を行っていきましょう。商談スコアはどう判断されているのか商談スコアは過去の完了商談の情報をもとに、現在の商談についてスコアをつけます。大まかに以下の流れで商談スコアは判断されています。SalesforceのAI機能(Einstein)が皆様の環境の「完了(成立/不成立)商談」および関連データを定期的に分析し、成立に重要な情報や法則性を方程式として保存します。進行中の商談のデータを方程式に当てはめ、どの程度成立に近いかをスコアで算出します。商談スコアを算出する上で、基準になっているのは過去の商談データとなり、過去データがしっかりとある方が現実を反映した”精度の良いスコア”となりやすく、データが少ない場合はその逆となります。そのほか、モデルの更新頻度等は以下の表を参照ください。(2023/1月時点)トピック内容データ要件過去 24 か月間に、それぞれの存続期間が 2 日以上の 200 件以上の成立商談が必要です過去 24 か月間に、それぞれの存続期間が 2 日以上の 200 件以上の不成立商談が必要ですモデルのタイプ二値分類 (受注 または 失注 の予測モデル)モデルの採用十分なデータがない場合グローバルモデルが採用されるモデルの更新タイミング毎月 1 回、またはシステム管理者が設定を更新するたびに Einstein によって商談データが再分析され、モデルが更新されますモデルの参照データ各商談のレコード詳細 (標準項目とカスタム項目の両方)、履歴、および関連活動、関連取引先のレコード詳細と一部のレコード履歴、関連商品、見積、および価格表に関する詳細情報スコアの更新タイミング商談スコアは数時間ごとに更新されます商談スコアをどう活用するのか商談スコアは受注率の向上や業務効率化を目的とした、営業活動の優先順位付けや商談状態の判断指標に利用します。商談スコアは指標を表すツールとして営業活動や戦略的な施策にスコアを組み込み、活用することで初めて効果を発揮します。活用シーン例として、以下のものが挙げられます。活用の4ステップ商談スコアの概要は理解できましたでしょうか。それでは、実際どのように使っていくのかを、活用ステップを追って確認していきましょう。ステップ1:有効化する商談スコアの有効化設定完了しますステップ2:スコアを確認するスコア値を確認し、どのような値をとっているか確認しますスコア値の状態を加味し、どのように活用できるか評価しますステップ3:具体的な活用方法を決めるねらう効果と活用方法を明確にしますステップ4:スコアを活用する商談スコアを活用し効果を測定します課題や結果から活用方法をブラッシュアップしますでは、各ステップの詳細を確認していきましょう。活用ステップ全体に戻る場合は、こちら参考情報Einstein 商談スコアリングの設定に関する考慮事項(ヘルプドキュメント)Einstein によって商談にスコアが付けられる方法(ヘルプドキュメント)Salesforce Einstein Model CardsEinstein Opportunity Scoring for Everyone
-
この記事で学べることイベントモニタリングに含まれるトランザクションセキュリティ機能により、お客様はご自身で定義されたルールに沿って、組織内の特定のアクセスを検知・遮断することができるようになります。本記事では、このトランザクションセキュリティ機能を使い始めるにあたってどのような用途で活用できるのか、実際の条件例を交えながら具体的なポリシー例をご紹介します。(おさらい) イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング:セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング:イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとはこのうち、今回ご説明するトランザクションセキュリティポリシーはリアルタイムイベントモニタリングログを利用します。トランザクションセキュリティ機能の概要については、以下の記事をご参照ください。トランザクションセキュリティとは条件ビルダーによるポリシー作成例ApiEvent ポリシー例[特定のオブジェクトにて照会に○○ミリ秒以上かかったAPIクエリを検出]ポリシー設定 (“リード”オブジェクトの例)イベント: ApiEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)Elapsed Time / [>=] / “1,000” (任意の経過ミリ秒)[2つ以上の特定のオブジェクトのデータローダによるエクスポートの検出]ポリシー設定 (“取引先責任者”もしくは“リード”オブジェクトの例)イベント: ApiEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3 AND 4条件: 条件 / 演算子 / 値1. 照会されるエンティティ / [次の文字列と一致する] / “Contact” (任意のオブジェクト名)2. 照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)3. クエリ / [次の文字列と一致する] / “Select”4. Client / [次の文字列で始まる] / “DataLoader”ListViewEvent ポリシー例[APIを使用して照会されたリストビューの検出]ポリシー設定イベント: ListViewEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値イベントソース / [次の文字列と一致する] / “API”メモ: API の代わりに Classic または Lightning を指定することで、UIを利用したリストビューの照会についても追跡することができます。[2つ以上の特定のオブジェクトのリストビュー実行の検出]ポリシー設定 (“取引先責任者”もしくは“リード”オブジェクトの例)イベント: ListViewEvent条件ロジック: いずれかの条件に一致 (OR)条件: 条件 / 演算子 / 値照会されるエンティティ / [次の文字列と一致する] / “Contact” (任意のオブジェクト名)照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)[特定ドメインのユーザによるすべてのレコードもしくは特定のリストビュー実行の検出]ポリシー設定イベント: ListViewEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3条件: 条件 / 演算子 / 値1. 範囲 / [次の文字列と一致する] / “Everything”2. 名前 / [次の文字列と一致する] / “SuperSecureListView” (任意のリストビュー名)3. ユーザ名 / [次の文字列で終わる] / “@spy.mycompany.com” (任意のドメイン名)LoginEvent ポリシー例[特定のIPアドレスからのログインを検出]ポリシー設定イベント: LoginEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値アクセス元 IP / [次の文字列と一致する] / “12.34.56.78” (任意のIPアドレス)メモ: [次の文字列で始まる] や [次の文字列を含む] 演算子を使用することで、特定のIPアドレス以外にも、社内ネットワークなど特定のサブネットに所属するIPアドレスからのログインを追跡することができます。[特定のブラウザからのログインを検出]ポリシー設定イベント: LoginEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値ブラウザ / [次の文字列を含む] / “Chrome” (任意のブラウザ名)メモ: 文字列を変えることで、Safari や Firefox ブラウザからのログインについても追跡することもできます。ReportEvent ポリシー例[特定のオブジェクトで○○件以上のレコードを表示したレポート実行の検出]ポリシー設定 (“リード”オブジェクトの例)イベント: ReportEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値処理行 / [>=] / “2,000”照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)[出力にメールアドレスが含まれる列を持つレポート実行の検出]ポリシー設定イベント: ReportEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値列名 / [次の文字列を含む] / “Email” (任意の列名)メモ: [次の文字列を含む] 演算子を使用することで、Email、Customer Email、 Email of Customer など、列名に“Email”を含む項目を全て当てはめることができます。[2つ以上の特定のオブジェクトを元にしたレポートのエクスポートの検出]ポリシー設定 (“取引先責任者”もしくは“リード”オブジェクトの例)イベント: ReportEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3条件: 条件 / 演算子 / 値1. 照会されるエンティティ / [次の文字列と一致する] / “Contact” (任意のオブジェクト名)2. 照会されるエンティティ / [次の文字列と一致する] / “Lead” (任意のオブジェクト名)3. 演算子 / [次の文字列と一致する] / “ReportExported”[高保証セッションレベルセキュリティがないセッションからの機密レポート参照を検出]ポリシー設定イベント: ReportEvent条件ロジック: カスタム条件ロジックに一致 → (1 OR 2) AND 3条件: 条件 / 演算子 / 値セッションレベル / [次の文字列と一致する] / “LOW”セッションレベル / [次の文字列と一致する] / “STANDARD”名前 / [次の文字列を含む] / “AccountList” (任意のレポート名)PermissionSetEvent ポリシー例[“パスワード無期限”権限のユーザへの割り当てを検出]ポリシー設定イベント: PermissionSetEvent条件ロジック: すべての条件に一致 (AND)条件: 条件 / 演算子 / 値権限リスト / [次の文字列を含む] / “PasswordNeverExpires”演算子 / [次の文字列と一致する] / “AssignedToUsers”Apexによるポリシー作成例ReportEvent ポリシー例[特定のプロファイルに属するユーザによるレポートのエクスポートを検出]ポリシー設定イベント: ReportExportApexコード例global class BlockSpecificProfileReportExport implements TxnSecurity.EventCondition { public boolean evaluate(SObject event) { switch on event{ when ReportEvent reportEvent { return evaluate(reportEvent); } when null { return false; } when else{ return false; } } } private boolean evaluate(ReportEvent reportEvent) { // Retrieve User's profile id. User results = [SELECT Id, ProfileId FROM User WHERE Id = :reportEvent.UserId]; // Check ProfileId and report export operation. if (results.ProfileId.equals('00eXXXXXXXXXXXXXX') && reportEvent.Operation.contains('ReportExport')) { return true; } return false; }}学習ツール拡張トランザクションセキュリティポリシーの種別条件ビルダーの例Apex トランザクションセキュリティの高度な実装例まとめトランザクションセキュリティを活用することにより、プロファイルや権限セットでは表現できないような細かなユーザアクセスの検出や制御を実現し、リアルタイムで検知・遮断することが可能となります。条件ビルダーでは画面操作により誰でも簡単にポリシーを作成することができる一方で、より複雑な要件に対してはApexコードによるコーディングを用いたポリシーの作成にも対応しており、用途やシステム管理者の習熟度に応じて使い分けることが出来るようになっています。
-
ウェブセミナーシリーズ「Salesforce まずはこれだけ」
さいご「Salesforce のシステム管理者に任命されたが、機能がたくさんあってどこから使い始めたら良いかわからない」「前任者から引き継いだが、現在どういう設定になっているのか把握できていない」このように日々 Salesforce で業務をしていただく上でお悩みのシステム管理者の方は多いのではないでしょうか。このウェブセミナーシリーズでは、「まず、これだけは抑えて欲しいポイント」をSalesforce サポートエンジニアが解説しています。最新の動画メール到達率の向上/レポートについてhttps://play.vidyard.com/RXvkk1tjRvf5DSobCiML43・なぜ到達率の向上が必要か ・到達率を向上させる方法 ・到達率の確認方法資料はこちら第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・なぜ到達率の向上が必要か ・到達率を向上させる方法 ・到達率の確認方法資料はこちら関連リソース次回以降の開催については日程が決まり次第、イベントカレンダーに掲載いたします。また、テクサポ日本のページでもご案内いたします。
-
Youtubeチャンネル Salesforce Support のご紹介
Salesforce Supportではテクニカルサポートにお客様から寄せられたお問い合わせや、今後の新機能のリリース情報をもとにYoutubeコンテンツを作成し公開しています。現在、約785本の動画を公開中。総再生数は900万以上と世界中のSalesforceユーザーにご活用いただいております。おすすめ動画をPick Up!自動化処理はSalesforceの大きな魅力の1つです。人の手を介さずに処理することで入力ミスを防止し、正確かつ迅速なデータを反映することで組織の情報価値を高めます。動画を参考に、項目の入力をトリガーにした関連するレコード入力の自動化をお試しください。自動化処理で快適に!~レコードトリガフロー編~(5:31)日本語のプレイリスト英語コンテンツに加え日本語の動画も順次追加されており、現在21本の動画を公開中です。一般的なハウツーからトラブルシューティングまで、さまざまなコンテンツを1本約5分でご用意しています。その中からまずご覧いただきたい2本をピックアップしてご紹介します。MFA (多要素認証) | SalesforceのMFAについて(5:59)Data Cloud はじめてのデータストリーム設定手順(5:36)その他の動画につきましては、こちらの日本語プレイリストからご覧ください。まとめテキストだけでは分かりづらい内容も、実際の画面を表示して分かりやすく情報をお届けしてまいります。ぜひチャンネルをご登録いただきご活用いただけますと幸いです。Youtubeチャンネル Salesforce Support日本語プレイリスト日本語ウェブセミナープレイリスト(一部過去のウェブセミナーの動画も公開しております)
-
この記事で学べることICUロケール形式の有効化の背景と適用時期ICUロケール形式の有効化における変更点ICUロケール形式の有効化までの推奨アクションICUロケール形式の有効化の方法ICUロケール形式に関するFAQICUロケール形式の採用の背景Salesforce システム管理者は組織のデフォルトのロケールを設定できます。またユーザは個人設定ページで各自が使用するロケールを設定できます。このロケールにより、日付、時刻、通貨、住所、名前、数値などの表示形式(フォーマット)が制御されますこの表示形式について、現在の Salesforce Platform では Java Development Kit (JDK) ロケール形式を使用していますが、JDKロケール形式は定期的な更新がなく、国際標準との差異が発生しています。Salesforceでは、Salesforce Platform を常に最新の国際標準に準拠させる取り組みの一環として、Winter '20 で新しいロケール形式(ICUロケール形式)を採用しました。ICUロケール形式の採用により、世界中の ICU 準拠のアプリケーションとのインテグレーションが向上します。参考情報 : 新しい国際ロケール形式によるグローバル対応ICUロケール形式が有効化される時期Winter'20 のリリース以降に作成された組織では、ICU ロケール形式が既定で有効になっています。Winter'20 のリリース(2019年10月)以前に作成された組織については、JDKロケール形式が使用されています。JDKロケール形式が使用されている組織が ICU ロケール形式を適用できるように、Salesforceでは リリース更新を提供しています。*上記は設定画面のメニューより「リリース更新」を選択したときの画面です。[ICUロケール形式を有効化]の自動適用について、当初はSpring’24を予定しておりましたが、自動適用時期が以下の通り変更となりました。Spring'24のリリースですべての組織で[ICUロケール形式を有効化]を適用をするのではなく、Spring'24以降で段階的に自動適用を進めます。[ICUロケール形式を有効化]が適用される30 ~ 60 日前にSalesforceは管理者様にメールで通知します。[ICUロケール形式を有効化]の段階的な適用はSpring'25のリリースまで継続されます。参考情報 : WInter’24 リリースノート Enable ICU Locale Formats (Release Update)なお、システム管理者様は設定メニューを使用して、[ICUロケール形式を有効化]の自動適用をSpring'25のリリースまで延期させることができます。[ICUロケール形式を有効化]の適用をSpring'25のリリースまで延期する場合は、以下の手順を実施します。設定メニューのクイック検索ボックスに「ユーザーインターフェース」と入力します。「ユーザーインターフェース」をクリックし、設定画面を表示させます。「ユーザーインターフェース」セクションにある「Enable ICU locale formats as part of the scheduled rollout」という設定項目があるので、OFFにします。*この設定はJDKロケール形式が使用されている組織でのみ表示されます。*設定項目の名称は、今後日本語に翻訳される場合があります。参考情報 : JDK ロケール形式の廃止現在JDKロケール形式をご利用中の組織の管理者様は、SalesforceによるICUロケール形式有効化の自動適用を待つのではなく、影響範囲をご確認のうえで、計画的に適用できるようにご準備を進めていただくことを推奨します。組織で使用しているロケール形式の確認方法現在のSalesforce Platformでは、JDKロケール形式とICUロケール形式の両方がサポートされています。Salesforce 組織でどちらのロケール形式が採用されているかを確認するためには「リリース更新」を確認します。▼ICUロケール形式のリリース更新でテスト実行が有効化されている[設定]→[リリース更新]→[要対応]タブを押下。[ICUロケール形式の有効化]の[使用開始]をクリック[この更新は、テストできる状態になりました。]と表示されていたら、テスト実行によりICUロケール形式を利用中。それ以外の場合、組織は JDK ロケール形式を使用しています。▼ICUロケール形式のリリース更新が適用されている[設定]→[リリース更新]→[アーカイブ済み]タブを押下[ICUロケール形式の有効化]の有無を確認。[アーカイブ済み]タブにある[ICUロケール形式の有効化]を確認して、ステップバイステップガイドに従ってテスト実行を完了している場合には、[完了]とマークされており、リリース更新の適用によりICUロケール形式を利用中。参考情報 : 組織が ICU と JDK のどちらのロケール形式を使用しているかの判断ICUロケール形式を有効化したときの変更点ICUロケール形式がSalesforce 組織に適用されることで変更が発生する項目は以下のものがあります。日付(Date)日付時間(Datetime)時刻(Time)通貨(Currency)数字(Number、Integer)すべてのロケールにおいて上記項目で変更が発生するのではなく、ユーザが使用しているロケールによって変更点は異なります。例として、日本語、日本語(日本)、英語(アメリカ)の3つのロケールにおける変更点をご紹介します。ロケール毎の各データタイプ(形式種別)への影響は JDK と ICU ロケール形式の相違点 に掲載されていますが、影響のあるデータタイプは標準画面やカスタム画面では使用されない場合もあります。ICUロケール形式が有効化されたときの動作イメージは次のセクションでご紹介します。参考情報 : JDK と ICU ロケール形式の相違点ICUロケール形式有効化時の動作イメージ「日本語(日本)」のロケールを選択している場合におけるICUロケール形式が適用された際の標準画面のイメージは以下のとおりです。Lightning Experienceの標準画面ではChatterの日付に「Date:Long」のデータタイプが使用されています。そして「日本語(日本)」ロケールの場合、「Date:Long」のデータタイプはICUロケール形式が有効化されたときの形式変更対象なので、表示形式が「2022/03/15」から「2022年3月15日」に変更されていることがわかります。しかし標準画面の他の項目では通常 Short のデータタイプが使用されており、「日本語(日本)」ロケールでは Short のデータタイプは形式の変更がないため、ICUロケール形式が適用されていても表示形式に変更はありません。それでは次に、「日本語(日本)」のロケールを選択している場合におけるICUロケール形式が適用された際のVisualforceページのイメージを見てみます。Visualforceページを使用していたとしても通常は Short のデータタイプが使用されているため、[日本語(日本)]のロケールではICUロケール形式が適用されても表示形式は変わりません。「日本語(日本)」のロケールを使用していた場合の標準画面とVisualforceページを例にして動作イメージをご紹介しましたが、異なるロケールを使用していた場合の例として、「英語(アメリカ)」のロケールを使用していた場合の標準画面の動作イメージをご紹介します。「英語(アメリカ)」のロケールではICUロケール形式の有効化において「Date:Long」は形式変更対象ではなく、「Date Time:Short」が形式変更対象に含まれています。そして日付時間型項目では「Date Time:Short」のデータタイプが使用されているため、該当の項目において、「8/1/2022 12:00PM」から「8/1/2022, 12:00PM」に表示形式が変わっている(カンマが追加されている)ことが確認できます。このように、使用しているロケールによって表示形式が変更される項目が変わっていることが確認できます。Apex クラス/トリガ、および Visualforce ページを使用している場合の留意点ICUロケール形式はAPI バージョン 45.0 以降で使用できます。ApexやVisualforceページなどのカスタマイズで ICU ロケール形式を使用するには、Apex クラス、Apex トリガ、および Visualforce ページを最新の API バージョンに更新します。ApexやVisualforceページなどのカスタマイズが API バージョン 44.0 以前を使用している場合、JDKロケール形式が返されるため、データの整合性の問題やエンドユーザの困惑が発生するなどの影響が発生する可能性があります。 以下に影響例の1つとして、API バージョン 44以前のVisualforceページを使用した場合の例をご紹介します。*この例は[英語 (アメリカ)]ロケールを使用している場合の例です。[英語 (アメリカ)]ロケールでは日付時間項目[Date Time:Short]について影響がありますが、[日本語 (日本)]ロケールでは[Date Time: Short]や[Date:Short]は形式変更対象ではないため、この例に示すパターンのエラーは発生しません)[英語 (アメリカ)]ロケールを使用している場合、[Date Time:Short]は形式変更対象であり、[Date Time:Short]は日付時間型項目で使用されているので、APIバージョン45以降のVisualforceページでは表示形式が変わります。しかし、VisualforceページのAPIバージョンが44以前の場合は、ICUロケール形式が使用できずJDKロケール形式が使用されるため、表示形式が変わりません。APIバージョン44以前のVisualforceページは表示形式が変わらないのですが、Visualforce ページのインライン編集の処理では最新のAPIバージョンが使用されます。つまり、Visualforce ページで apex:detail を使用している場合、インライン編集時にはAPIバージョン44以前でもICUロケール形式を使用します。しかし、APIバージョン44以前のVisualforceページでは、ICUロケール形式が使用できないためエラーが発生します。以上がAPIバージョン44以前のVisualforceページを使用していた場合の影響例です。もう1つ影響例をご紹介します。Apexクラスで以下のメソッドのようにロケール形式に依存するメソッドを使用している場合やLightningコンポーネントで$Localeを使用している場合には、ロケール形式の変更によって影響が出る可能性があります。ロケール形式に依存するApexメソッド例Date.format()Date.parse()DateTime.format()DataTime.parse()DateTime.formatLong() などロケール形式を意識したカスタマイズを実装されている場合、形式の変更により現在のカスタムロジック(文字列の判定など)が正しく動作しなくなる可能性があります。参考情報 : Apex クラス、Apex トリガ、および Visualforce ページの API バージョンICUロケール形式の有効化までの推奨アクションICUロケール形式が適用されると、使用しているロケールによって日付・時刻・通貨等の表示形式が一部変更されます。該当項目を使用した検索条件が利用されている場合(レポート、入力規則など)、なんらかの影響が発生する可能性があります。また、Apex クラス、Apex トリガ、Visualforceページにて、API バージョン44.0以前をご利用の場合はJDKロケール形式が返されるため、エラー等の問題が発生する可能性があります。そのため、事前にSandbox等でICUロケール形式を有効化して動作テストを実施し、Salesforce組織での影響有無を確認の上で、本番環境で有効化することを推奨します。(Salesforceによる自動適用を待つのではなく、管理者様にて事前にテスト/評価、有効化していただくことを推奨します。)動作テストでは、表示上の確認だけではなくVisualforce ページのインライン編集やカスタムコードの挙動、インストール済みパッケージの動作等についても御確認ください。参考情報 : ICU ロケール形式の採用に関する考慮事項ICUロケール形式の有効化の方法ICUロケール形式の有効化は「リリース更新」から実施します。最初にSandboxでICUロケール形式を有効化し、動作テストを実施します。影響がないことが確認されたら、本番環境でICUロケール形式を有効化してください。「リリース更新」を使用してICUロケール形式を有効化する方法は以下のとおりです。1.[設定]→[リリース更新]→[要対応]タブを押下して、[ICUロケール形式の有効化]の[使用開始]をクリック2.[テスト実行を有効化]をクリック。3.[このリリース更新の影響を評価]の「完了」ボタンをクリックし、有効化動作テストにあたっての事前確認事項Salesforce組織で現在使用されているロケールとユーザの確認SOQL クエリを使用して、組織で使用されているロケールと各ロケールのユーザ数を確認し、影響調査や動作テストが必要なロケールの種類を調べます。<SOQLクエリ>SELECT toLabel(LocaleSidKey) LocaleName, LocaleSidKey, Count(id) UserCount FROM User where IsActive=true GROUP BY LocaleSidKey<クエリ実行結果のイメージ>*上記は開発者コンソールを使用してSOQLクエリを実行した結果のイメージです。この結果の例では、日本語/日本語(日本)/英語(アメリカ)が使用されていることが確認できます。参考情報 : 使用中のロケールの判断Apexクラス、Apexトリガ、Visualforceページ のAPIバージョンの確認ICUロケールを適用するには APIバージョンが 45.0以上の必要があります。APIバージョンが45.0未満の場合は、45.0以上に更新します。API バージョン 45.0 以上にアップグレードしない場合、ユーザに「無効な日付と時間です」といったParseException エラーが表示される可能性があります。参考情報 : Apex クラス、Apex トリガ、および Visualforce ページの API バージョンApexクラスで使用しているメソッドの確認Apexクラスで以下のメソッドのように、ロケール形式に依存するメソッドで影響が無いか確認します。Date.format(),Date.parse(),Date.toStartOfWeek(),DateTime.format(),DataTime.parse(),DateTime.formatLong()等影響がある場合は、ロケール形式に依存しないコードとするためのガイドラインを適用します。・標準メソッドを利用 - 日付形式のデータから”月”を抽出する場合は、Dateクラスの month()を利用する。 - 整数値と通貨値は、書式設定する必要が生じるまで書式設定のない整数として処理。 など・値に追加の処理を行う場合、ロケールに依存しない形式を使用・ユーザが選択しているロケール形式へのデータの変換は、そのデータ処理の最後のステップとする。参考情報 : コードでのロケールに依存しないメソッドの使用Lightningコンポーネントの確認$Localeを使用していると、ユーザが選択しているロケール形式が使用されるので、ICUロケール形式の適用によって影響を受ける可能性があります。そのため使用箇所がないか確認します。参考情報 : Lightning コンポーネント開発者ガイドICUロケール形式の有効化に関するFAQQ:ICUロケール形式の有効化後、[日本語(日本)]や[日本語]のロケールを使用した場合、Classicの標準画面では影響がありますか。A:Lightning Experience と Classicで差異はありません。Chatterの投稿時間等では表示形式に変更があります。Q:ICUロケール形式の対象範囲は、REST APIや、SOAP API、Bulk APIも含みますか。A:SOAP/REST/Bulk APIではロケールに依存しないデータ型が使用されます。ただし、Apex クラスを公開するApex SOAP/REST web servicesではロケールに依存するデータ型が使用可能な為、影響がでる可能性があります。Q:ApexやVisualforceを多用しているのですが、全てについてバージョンを上げる対応が必要でしょうか。A:例えばVisualforceページについては、44以下のAPIバージョンのままICUロケールを有効化すると、インライン編集での保存時にエラーが発生する可能性があります。予期せぬ問題が発生しないようにする為に、Sandbox上でAPIバージョンは45以上の新しいバージョンに上げて頂いた上で、動作確認テストを実施して頂く事を推奨しています。APIバージョン44以下のものが残る場合でも、Sandbox上でICUロケール形式を適用しての動作確認テストは十分に実施するようにしてください。Q:ICUロケール形式が強制適用される時期は延長可能ですか。A:Spring'25までであれば、管理者様にて設定画面から延期することが可能です。Q:ICUロケール形式が自動適用されたら、表示内容が変わったり、エラーが表示されるようになるのでしょうか。A:使用するロケールや、カスタマイズ内容によって影響が異なります。ICUロケールが適用された際に本番環境で影響が出ないように、事前にSandboxでの動作確認テストの実施をお願いいたします。
-
この記事で学べること項目監査履歴は、データの正確性を維持し、第三者に改ざん等がされていないことを証明するための更新ログの記録という本来の目的とは別に万一のデータ漏えい事故において、漏えい時期の絞り込みに寄与し、インシデントレスポンスにおける効率的なログ調査を実現できることが新たに注目されています。本記事ではとあるオフィスにおける架空の情報漏えい事故の対応を見て行くことで、効率的な対応が可能である理由を学べます。とあるオフィスでの一幕とある架空企業A社はDXに関する提案・開発支援・運用支援のサービスを手掛ける企業で、多くの見込み客、顧客、商談、プロジェクト情報、サポート状況など、様々な情報をSalesforceで管理している。A社はとある官庁との取引があり、当該官庁向けのプロジェクト情報もステークホルダー管理(個人情報)をした上でSalesforceに保管していた。ある日、A社の営業が顧客でとある官庁から一通のメールを受信した。メールには、当該官庁のセキュリティ運用を担っているベンダーの調査で、ダークWebで取引される情報のサンプルデータ(犯罪者が取引する情報の信ぴょう性を喧伝するために窃取したデータの一部を公開したもの)に当該官庁向けプロジェクトの情報が確認されたこと、プロジェクト情報には個人情報であるステークホルダー情報を含んでいたこと、データの内容からA社より情報が漏えいしたと思われること、また緊急で調査をしてほしい旨が書かれていた。サンプルデータを確認するとA社とお客様でしか知り得ないプロジェクト情報がA社のSalesforce環境のデータと一言一句違わずに書かれており、また個人情報もA社が管理している内容とほぼ同等な内容であることが確認された。A社はCSIRTを中心としたインシデントレスポンスを即時開始。CSIRTは過去に遡ってSalesforce環境におけるアクセスログの調査を開始した。アクセスログの記録についてアクセスログはイベントモニタリングで提供される機能の一つであるリアルタイムイベントモニタリングで確認することができます。詳細はアクセスログの参照ガイドをご参照ください。再びオフィス(本記事のメイントピック)A社はイベントモニタリングを契約の上、リアルタイムイベントモニタリングを有効化し、また定期的にアクセスログの保管をしていたことから、アクセスログを調査できる目途は立った。しかしアクセスログの量は膨大で、またサンプルデータからは漏えい時期を隠匿するためか、レコードの作成日や更新日等の監査項目は記載されていなかった。そのためデータの漏えいした時期や漏えいに関与したユーザアカウントの絞りこみといった調査には相当な時間を要すると思われた。CSIRTに招集された官庁向けプロジェクトのプロジェクトマネージャが漏えいしたサンプルデータを見ると、いくつか古い状態のデータがあるのに気付いた。このデータが古い状態であった期間が特定できればログの絞り込みは容易になるのではないかと考え履歴の調査を開始した。項目監査履歴の特徴項目監査履歴は項目履歴管理の機能を拡張する製品となります。詳細は項目監査履歴とはをご参照ください。ここでは漏えいが発覚しCSIRTによる調査を開始した日を2020/12/31 として、サンプルデータや本番環境のデータの状態例を見ながら項目履歴管理を設定していない場合、項目監査履歴が無い場合、項目監査履歴がある場合の調査対象ログの絞り込み方を確認していきます。【漏えいしたサンプルデータから確認できた古い情報】【本番環境にある情報】※黄色はサンプルデータからの変更点、また日時データは簡略化のため年月以外は1日午前0時に統一、またデータの変更は、値から変更前後がわかりやすいように常に1が加算されるものとしています。例:99(変更前)→100(漏えい値)→101(変更後)項目履歴管理の設定をしていない場合それぞれのレコードでは作成日、最終更新日の監査情報しかありませんので、ログの調査対象期間は、漏えいしていた4つのレコードの中で一番最近に登録されたレコードの作成日(レコード4の2018/04/01)から、漏えい値から変更のあったレコード(レコード1,2,3)のうち、最も古い最終更新日(レコード2の2019/10/01)までの18ヶ月に絞り込まれます。この期間より古いと、レコード4が存在していませんし、また新しいとレコード2の項目Aの値が漏えいした値と異なることになるため調査対象期間から除外されるからです。青:レコードの値が確定できない時期 薄い緑:レコードの値が確定できる時期項目履歴管理の設定を実施していた場合項目履歴管理の設定をしている場合、項目レベルで変更履歴を確認することができます。A社の場合、項目Aに項目履歴管理の設定をしていた為、以下の履歴を確認することができました。【本番環境から確認できるレコード1の履歴】【本番環境から確認できるレコード2の履歴】このログによるとレコード1及びレコード2の項目Aの値が漏えい値から現在の値に変更された日時の特定ができましたが、24カ月より前の変更履歴が既に確認できないため、前の値から漏えい値に変更された日時の特定はできませんでした。また、A社においては履歴を管理できる項目の数が1オブジェクトあたり20項目という上限に抵触したために優先度の低い項目Bには履歴管理の設定ができていませんでした。青:レコードの値が確定できない時期 薄い緑:レコードの値が確定できる時期 濃い緑:漏えい値であったと確定した期間このログにより、レコード1とレコード2の項目Aが同時に漏えい値であった時期は2019年2月1日より前であることになり、調査期間も10ヶ月分に絞り込むことができました。2019年2月1日以降は、レコード1の項目Aが漏えい値と異なるため除外されるからです。項目監査履歴がある場合項目監査履歴があれば、1オブジェクトあたり項目履歴管理の3倍の60項目まで履歴管理を設定できるため、優先度の低かった項目Bの履歴管理も設定でき、またログの保存期間も無期限であるため、以下の情報が追加で確認することができます。【本番環境から確認できるレコード1の履歴】【本番環境から確認できるレコード2の履歴】【本番環境から確認できるレコード3の履歴】薄い緑:レコードの値が確定できる時期 濃い緑:漏えい値であったと確定した期間このログにより、すべてのレコードが存在し、各レコードの項目の値が漏えい当時の値であったのがいつであったのか、すなわちその期間にデータが抜き出されたことを特定できます。今回のお話では、各レコードの漏えい値がSalesforce内に存在していた期間は、2018年1月の僅か1ヶ月間であったことが判明、その調査対象期間のイベントモニタリングのログを解析することにより、漏えいに関与したユーザアカウントの特定と同時に漏えいしたデータの全貌が短期間で特定することが可能となりました。今回のお話では、外部から入手できたレコードが4件と項目も2つのみというシンプルなストーリーでしたが、実際には、外部から入手されたデータが多いほど、漏えい値の存在期間の被っている時期、つまり漏えいした時期がピンポイントで絞り込み可能となりますので、イベントモニタリングの導入には、ぜひセットで項目監査履歴の導入を検討いただければと思います。学習ツールヘルプ:項目履歴管理ヘルプ:項目監査履歴まとめ項目監査履歴は、更新頻度の多い項目に数多く設定しておくことにより、万一の情報漏えいに対してイベントモニタリングと合わせて効率的にインシデントレスポンスを行うことができます。