トランザクションセキュリティポリシーの活用例

この記事で学べることイベントモニタリングに含まれるトランザクションセキュリティ機能により、お客様はご自身で定義されたルールに沿って、組織内の特定のアクセスを検知・遮断することができるようになります。本記事では、このトランザクションセキュリティ機能を使い始めるにあたってどのような用途で活用できるのか、実際の条件例を交えながら具体的なポリシー例をご紹介します。(おさらい) イベントモニタリングに含まれる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コードによるコーディングを用いたポリシーの作成にも対応しており、用途やシステム管理者の習熟度に応じて使い分けることが出来るようになっています。

3−2 Account EngagementとSalesforceのキャンペーン接続を行う

当記事に掲載されている画面イメージには一部旧名称（Pardot）の表記があり、実際の画面と異なる場合があります。設定方法は作成時点のものです。最新の情報はヘルプ/ナレッジ記事をご参照ください。ヘルプ/ナレッジ記事ヘルプ記事｜Account Engagement キャンペーンと Salesforce キャンペーンの接続設定概要SalesforceとAccount Engagementは単一の組織ではなく、それぞれ固有の組織のため、それぞれにキャンペーン(Salesforceキャンペーン, Account Engagementキャンペーン)が存在します。Salesforceキャンペーンの接続を行うことで、SalesforceキャンペーンとAccount Engagementキャンペーンを別々に管理することなく、一元的に管理することができます。設定手順設定の有効化状況を確認キャンペーン接続の設定が有効化されていることを確認します​1.［Account Engagement設定] > [コネクター] > [設定を編集]をクリック​2. [キャンペーン]タブを開き、「接続済みキャンペーンおよびEngagemen Historyを有効化」にチェックが入っていることを確認。マスタレコードタイプにチェックを入れ、 [保存] をクリック。Salesforce側でキャンペーンのレコードタイプを複数利用している場合、そのレコードタイプ名が表示されます。チェックを入れることで、Account Engagementと接続させるキャンペーンのレコードタイプを指定することが可能です。​接続されていないAccount Engagementキャンペーンを接続する接続されていないAccount Engagementキャンペーンを、Salesforceキャンペーンに接続します一括または個別で接続できます。ここでは「個別に接続」する方法についてご紹介します​一括で接続を行う場合は、下記のヘルプ記事をご参照ください。ヘルプ記事｜複数のキャンペーンの一括接続ヘルプ記事｜Salesforceデータローダーを使用した既存のキャンペーンの接続​個別に接続する場合ここでは、Account Engagementに標準で搭載されているWebsite Trackingに対応するSalesforceキャンペーンを新たに作成し、Account EngagementのWebsite Trackingキャンペーンと接続する手順を説明します。ヘルプ記事｜個々のキャンペーンの接続3. [キャンペーン]タブを開き、[新規]をクリック​4. 「キャンペーン名」に「Website Tracking」と入力し、有効にチェックを入れ、[保存]をクリック​5. キャンペーン「Website Tracking」が作成されたことを確認​6. アプリケーションランチャーから「キャンペーン」を検索 > [Account Engagementキャンペーン]をクリック​7. ビューのプルダウンから[接続されていないキャンペーン]を選択​8. 「Website Tracking」の右側のギアアイコン > [CRMキャンペーンに接続]をクリック​9. 「名前」に「Website Tracking」と入力し、「CRMキャンペーン」から「Website Tracking」を選択 > [キャンペーンを保存]をクリックCRMキャンペーンに「Website Tracking」が表示されない場合は、旋回(画像青枠)をクリックし、最新情報を読み込みます​Salesforceでキャンペーンを管理するための設定を行う個別または一括で、未接続のAccount EngagementキャンペーンとSalesforceキャンペーンの接続が完了したら、最後にSalesforceでキャンペーン管理を行うための設定を有効化します​10. [Account Engagement設定]タブから[コネクター] > ギアアイコン > [設定を編集]をクリック​11. 「キャンペーン」タブを開き、「Salesforceを使用してすべてのキャンペーンを管理」「キャンペーンタブに未接続キャンペーンを表示」にチェックを入れ、[保存]をクリック​ご不明点やエラーの解消が必要な場合は、弊社テクニカルサポートにお問合せください。弊社サポートエンジニアが貴社のSalesforce/Account Engagement環境を確認の上、具体的な手順をご案内いたします。ナレッジ記事：Salesforce カスタマーサポートへの問い合わせ前のステップ：3−1 Account EngagementとSalesforceのユーザーの接続を行う次のステップ：3−3 カスタム項目を作成して対応付ける「サクセスナビ｜初期設定を完了しましょう｜③Account Engagement設定」の記事に戻る

Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止

Summer '25 で廃止される Salesforce Platform API バージョン 21.0 ～ 30.0 の概要と影響有無の確認方法についての解説動画です。お客様での調査にお役立てください。https://play.vidyard.com/iE8EjS3tstXxdJS4jBUM3W投影資料のダウンロードはこちらからこの記事で学べることSummer '25に廃止される API バージョンと種類を知ることができますAPI バージョンの廃止スケジュールを知ることができますお客様にて必要な対応を知ることができますご存知ですか？ Summer ’25 で古い API バージョンが廃止されます​Salesforce では、API の品質およびパフォーマンスを充実させ、改善するために、最初のリリース日から最低 3 年間サポートしますが、それを超えるバージョンのサポートは停止されたり、廃止される場合があります。そのため、定期的に API バージョンを更新いただくことを推奨しています。※API バージョンを定期的に更新しましょう（サクセスナビ）も是非ご覧ください​今回廃止対象の API の種類とバージョンは以下のとおりです。SOAP：21.0、22.0、23.0、24.0、25.0、26.0、27.0、28.0、29.0、30.0REST：v21.0、v22.0、v23.0、v24.0、v25.0、v26.0、v27.0、v28.0、v29.0、v30.0Bulk：21.0、22.0、23.0、24.0、25.0、26.0、27.0、28.0、29.0、30.0注意事項この廃止には、以下は含まれませんApex クラス、Apex トリガ、Visualforce ページ、フロー、プロセスビルダーただし、AJAX Toolkit を介して行われるバージョン指定された API コールを埋め込んだ Visualforce ページやカスタムボタン、S コントロールはこの廃止による影響を受けます標準の Salesforce B2B Commerce for Visualforce 製品バージョン 30.0 以前のメタデータコンテンツを参照している管理パッケージカスタム Apex REST & SOAP Web Services​この廃止は以下のものに影響します。データローダー　Web Services ConnectorAJAX Toolkit を介して行われる廃止対象のバージョンが指定された API コールを埋め込んだ Visualforce ページやカスタムボタン、S コントロール SForceOfficeToolkit COM インターフェースを介して行われる従来の API コールForce.com Toolkit for PHPアウトバウンドメッセージによって生成されたペイロードから呼び出された SOAP API最新ではない API バージョンを使用している接続アプリケーション廃止スケジュールSummer ‘25以降、廃止された API バージョンを使用した場合場合、以下のようなエラーが発生します。REST API : 「410:GONE」SOAP API :「500:UNSUPPORTED_API_VERSION」Bulk API :「400:InvalidVersion」お客様にて必要な対応「そんな急に廃止と言われても・・・」と戸惑っているシステム管理者の方もいらっしゃるかもしれません。Salesforce では、システム管理者様宛に、月次で、以下のような 機能廃止ダイジェストメール等でお知らせしています。※ 終了日は 2025 年 6 月 1 日となっていますが、こちらのナレッジに記載の通り、実際の終了日は Summer ’25 リリース日となります。（リリース日は Trust サイトにてご確認いただけます）​推奨する対応順序設計書や仕様書などのシステム導入時のドキュメントや、実際のデータ連携実装箇所を調査する外部システムやツール（データローダー等）を使って Salesforce へ接続するアプリケーションの有無とバージョンを確認組織内の開発で AJAX Toolkit 等を使用した実装有無とバージョンを確認こちらの資料を参考に、見落としがちな設定を確認追加でご確認いただく手段として、ログイン履歴の確認や API でのアクセス状況をイベントモニタリングログから確認いただくことが可能です。（こちらの P.10 参照）　手順１、２で確認した箇所の API バージョンを更新[リリース更新] の [テスト実行] を有効化後に、APIバージョンを更新した外部システムやツールを実行 *手順１、２で確認した方法（ログイン履歴等）で、手順４の接続結果を確認* Winter’25 より、[リリース更新]の[テスト実行]をご利用いただけます。[テスト実行] 有効化後は、廃止対象の Platform API バージョンの利用は不可となります。具体的には、廃止対象バージョンの API バージョンに対して外部システムからアクセスすると その API  コールは失敗、エラーが発生するようになります。[テスト実行を有効化]をするには、[使用開始] をクリック後の画面で [テスト実行を有効化] をクリックします。この機能を利用し、外部システムからの API コールをテストをすることができます。※適用スケジュールまでの間は、いつでも [テスト実行] の有効 / 無効を切り替えることができます。​学習ツールSalesforce Platform API バージョン 21.0 ～ 30.0 の廃止（ナレッジ）API バージョンを定期的に更新しましょう（サクセスナビ）イベントモニタリング（Trailhead）API 合計使用量（開発者ガイド）​まとめSalesforce の API は、最初のリリース日から 3 年経過すると廃止になる場合があるので、定期的にバージョンを更新する必要があります機能廃止に関するダイジェストメールが月次で配信されていますので、システム管理者様は必ず確認して下さい廃止対象の API バージョンを使用しているかどうか、使用箇所や実装された詳細については、Salesforce では確認ができないため、利用有無および対応方法については、開発会社や開発担当者様へご確認をお願いします。

Salesforceにデータを取り込む

この記事で学べること別システムのデータをSalesforce に取り込む場合の考慮事項について知ることができますSalesforce へデータを取り込む理由皆様の会社では、業務でどんなシステムを使っていますか？きっとSalesforce 以外にもたくさんのアプリケーションを使っていると思います。​そして、日々の運用という観点では、それら別々のシステムに保存されているデータを取り出して、集計や報告をしなければならないということもあると思います。が、それって結構面倒ですよね？「もう少し楽にできないか？」と感じることもあるでしょう。そんな時に、「Salesforce にデータを（自動で）取り込めないか？」と考えるかもしれません！​そうです。Salesforce にデータを取り込めば、レポートやダッシュボード使って、手軽に集計や報告ができそうですね。​この記事では、「Salesforce にデータを取り込む場合の考慮事項」について、（自動化以外の）手動の方法も含めて概要をご紹介します。（データ量によっては、Salesforce ではなく、CRM Analytics などにデータを取り込むほうが良い場合もあります）​まずは、Salesforceにデータを取り込むために用意されている方法を見てみましょう。データインポートウィザードデータインポートウィザードを使用すると、あらかじめ用意したCSVファイルをアップロードし、取引先、取引先責任者、リード、キャンペーンメンバー、カスタムオブジェクトなどへ容易にデータをインポートできます。（Database.com Edition以外の）すべてのエディションでご利用可能で、一度にインポートできるレコードの最大数は 5 万件です。​Salesforceの画面上から実行できるので最も簡単な方法となりますが、自動化はできません。​特徴は、取引先と取引先責任者を同時に（互いを関連付けた状態で）インポート出来る点です。そのため、これからSalesforceにデータを投入して使い始めるお客様には、最適な機能です。※データインポートウィザードで商談をインポートすることはできません。商談をインポートする場合はデータローダーを使用します​データインポートウィザードについては、Excelの顧客データを取り込む（サクセスナビ）をご確認ください。データローダーデータローダーを使用すると、あらかじめ用意したCSVファイルを使用して（レコードのインポートのみでなく）更新や削除、エクスポートができます。Enterprise Edition以上、もしくはDeveloper Edition、Database.com Editionでご利用可能で、一度に操作できるレコードの最大数は、55百万件です。​データローダーは（英語の）クライアントアプリケーションなので、PCにインストールが必要ですが、Windows端末をご利用の場合は自動化（バッチモード）もできます。​データローダーは、データインポートウィザードでは対応していない（商談等の）オブジェクトにも使用できますが、複数のオブジェクトに対して一度に作業を行うことはできません。互いに関連しているデータをインポートする場合は、親 → 子の順番でインポートをしていきます。​また、データローダーはAPIを消費しますので、上限を超過しないように注意が必要です。詳細は、API 要求の制限と割り当てをご確認ください。​データローダーの画面操作については、以下をご確認ください。初めてのデータローダー 〜Insert編〜初めてのデータローダー 〜Update編〜初めてのデータローダー 〜Upsert編〜初めてのデータローダー 〜Delete編〜初めてのデータローダー 〜Export編初めてのデータローダー 〜Export All編データローダーのバッチモードについては、バッチモードでの実行 (Windows のみ)をご確認ください。​さて、ここまでは、Salesforceが標準で提供している機能（方法）についてご紹介しました。​データローダーのバッチモードは、設定ファイルの編集やバッチファイルの起動など、Salesforceの設定だけでは完結しません。設定をする場合にはシステム管理者と協力して進めましょう。（もし、ご自身がSalesforceのシステム管理者の場合は、データローダーを使用して連携したいシステムの管理者の方と協力しましょう）​これ以降は、外部システムから直接API（アプリケーション・プログラミング・インタフェース）を呼び出す方法をご紹介します。​「自分にはAPIを呼び出すなどのスキルが無い・・・」というシステム管理者の方も、ご安心ください。AppExchangeでパートナー企業を探すこともできます！Salesforce APIAPIを使用して開発をすれば、ほぼ何でもできます！（しかし、これは、言いすぎかもしれません・・・）​この記事では、外部システムのデータをSalesforceに定期的に取り込むことで、手動での外部システムからのデータのダウンロード、（場合によってはデータの加工）、Salesforceへのデータインポートにかかる工数を無くす方法について考えてみましょう。​※お客様のユースケースによっては、外部システムのデータをリアルタイムにSalesforceの画面に表示したいこともあるでしょう。その場合、定期的にデータをロードしても間に合いません！以下は、日次や週次等といった定期的にデータを取り込むのに適した方法です。どのようなツールを利用すべきですか？サードパーティ製の ETL ツールを利用することもできますし、独自のクライアントアプリケーションを開発することもできます。いずれにせよ必要な処理は、一定期間内に発生した外部システムのデータ変更を取得し、そのデータを（必要であればSalesforce用に加工して）Bulk APIもしくはSOAP APIを使用してSalesforceに取り込みます。どのAPIを使用すべきかですか？使用するAPIは、取り扱うデータ量を元に選択します。​Bulk APIは、大量データ（数千から数百万単位のレコード）を扱うために最適化されています。複数のバッチを並列して送信するので、多数のレコードをで挿入、更新、更新/挿入または削除できます。​一方、SOAP API は、一度に少数のレコードを更新するリアルタイムのクライアントアプリケーション用に最適化されています。SOAP API を使用しても多数のレコードを処理することはできますが、数十万のレコードを扱う場合にはBulk APIの方が実用的です。​また、Bulk APIとSOAP APIの違いは以下の通りです。APIの種類プロトコルデータの形式同期/非同期1APIの種類プロトコルデータの形式同期/非同期2Bulk APIRESTCSV、JSON、XML非同期3SOAP APISOAP (WSDL)XML同期Bulk API には 2 つのバージョン (1.0と 2.0) があります。2.0の方がデータの取り扱いが容易ですが、データローダーは2.0に対応していません。他の種類のAPIを含めた説明は、Salesforce Lightning プラットフォーム API の概要（Trailhead）をご確認ください。データを取り込むタイミング営業時間内にデータを取り込むと、画面上でユーザがデータを更新などしていた場合に（バッチ処理と）競合して、ロックやエラーが発生することがあります。バッチ処理は、事前にフルSandbox等で実際にかかる所要時間を確認し、夜間などユーザが操作をしていない時間帯にスケジュールしましょう。Bulk APIのフルSandbox等での評価時にロックエラーが発生する場合には、データの投入順序を調整するといった対処が必要になる事があります。（ロックエラーが出て対処法を模索中の場合は、この資料や英語のブログが参考になります）学習ツールインテグレーションのパターンと実践データの Salesforce へのインポート（ヘルプ）データ管理（Trailhead）まとめ外部システムからデータを取り込む処理は、大量データになることがあるのでBulk APIに対応したツールがおすすめですデータの取り込みを本番に実装する前に、所要時間の確認を含めSandboxで事前検証しましょう

APIバージョンを定期的に更新しましょう

この記事で学べることAPIバージョンを定期的に更新することの重要性APIバージョンのサポート対象期間APIとはAPI（Application Programing Interfaceの略）は、外部システムから自システムに対するリクエストを受け取るために用意された窓口（インターフェース）です。外部システムからSalesforceの情報にアクセスする必要がある時にはSalesforceのAPIを使用します。例えば、基幹システムの売上データをSalesforceに取り込む処理（夜間バッチなど）であったり、社内システムからのリクエストでSalesforceのデータを参照する時に使用します。APIのバージョンAPIにはバージョンという概念があります。APIを使用するときは、以下のように宛先とバージョンを指定してアクセスをします。以下の例では、外部システムから、Salesforceに対してSOAP APIの54.0のバージョンでアクセスをしています。上記例はSOAP APIですが、他にもいくつか種類があり、いずれも、バージョンを指定する必要があります。※APIの種類については、Salesforce プラットフォーム API について知る（Trailhead）をご確認ください。​APIの最新バージョンは、Salesforce の年3回のバージョンアップのタイミングで更新されます。​例Summer ’22： APIバージョン55.0 Winter ’23：APIバージョン56.0・・・​しかし、APIバージョンは外部システムによって明示的に指定されるため、お客様（外部システム）にて定期的に新しいバージョンに更新していただく必要があります。そして、Salesforceではあらかじめ最低限のサポート対象期間が決まっています。​APIのサポート対象期間Salesforce は、API バージョンを最初のリリース日から最低 3 年間サポートします。API の品質およびパフォーマンスを充実させ、改善するために、3 年を超えるバージョンのサポートは停止される場合があります。API バージョン廃止の予定がある場合、サポートが終了する最低 1 年前までに事前通知されます。​※実際に廃止になった例は、Salesforce Platform API バージョン 7.0 ～ 20.0 の廃止（ナレッジ）をご覧ください​APIをご利用の場合は、上記サポート期間を目安に定期的にAPIバージョンを更新いただくことを推奨します。​APIバージョンの更新更新箇所の確認：APIバージョンを更新する際は、まずはどこでAPIを使用しているかを把握している必要があります。開発を外部発注した場合は、ベンダーから受け取った仕様書に、使用しているAPIバージョンの記載があることを確認し、大切に保管します。社内で開発をする場合も、APIバージョンを含めた仕様を後で確認ができるように管理方法を決めて、社内で共有しておきましょう。​更新作業：実際のAPIバージョン更新作業は、Salesforce以外のシステムの設定変更であったり、AJAX Toolkitを使用した開発をしている場合はデプロイが必要になります。そのため、通常はベンダーや開発者様にて実施いただく作業になります。外部ベンダーへ依頼する場合には、社内プロセス（予算取りや承認申請など）に時間がかかることもあるかもしれませんので、早めに準備をしておきましょう。​その他：データローダもAPIを使用します。PCの画面上でデータローダを起動しご利用いただいている場合は、Salesforceの[設定]画面からデータローダのダウンロードをする事で、新しいAPIバージョンを使用する最新のデータローダを再インストールすることができます。データローダのツール自体のサポートは最新バージョンのみとなりますが、少なくとも3年に1度はデータローダを再インストールすることをお勧めします。学習ツールSalesforce プラットフォーム API について知る（Trailhead）Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止（サクセスナビ）Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止（ナレッジ）SOAP API 開発者ガイドREST API 開発者ガイドBulk API 開発者ガイドデータローダのインストール手順（ナレッジ）まとめSalesforceのAPIバージョンは、年3回のバージョンアップで更新されるリリース日から3 年を超えるAPIバージョンのサポートは停止される場合がありますAPIバージョン廃止の影響を防ぐため、定期的にお客様でのAPIバージョン更新作業を推奨します

項目監査履歴とは

この記事で学べることデータの変更履歴の長期保存がどうして必要なのかを理解し、標準機能で提供される項目履歴管理との違いを理解します。項目単位に変更履歴を設定する方法を学びます。項目履歴管理（標準機能）との違い項目監査履歴（オプション）は、項目履歴管理（標準機能）の制限を拡張させたものですが、利用できるエディション、オブジェクトあたりの追跡できる項目数、保存期間、および保存場所に以下のような違いがあります。​​項目履歴管理項目監査履歴​利用可能なエディション全てEnterprise、Performance、Unlimited​項目数/オブジェクト最大20項目最大60項目​保管期間本番組織に18 か月API 経由で最大 24 か月アクセス可本番組織に18ヶ月アーカイブ後は無期限​保管場所StandardObjectNameHistory または CustomObjectName__Historyアーカイブ前は項目履歴管理と同じアーカイブ後はFieldHistoryArchive Big Object項目監査履歴を利用するメリットイベントモニタリングは、ページまたはレコードレベルでユーザのアクセス履歴を追跡するためのログを提供しますが、更に項目監査履歴を利用することで、レコード内の項目値がどのように変更されたかという履歴を追跡することができるようになります。以下のような要件を満たす必要があるお客様にメリットをもたらします。データの変更履歴を監査証跡として提示し、更新処理が正確で改ざんなどの不正がないことを証明することが求められるが、以下の点で標準機能ではお客様の要求を満たすことができない場合追跡したい項目がオブジェクトあたり20項目を超えるデータを21ヶ月以上の長期間保管したい個人情報保護法や GDPR に求められる個人情報の正確性に対して厳密に準拠したい場合企業の会計情報に影響を与える情報を Salesforce 内で保存管理をしている場合規制業種のお客様（金融サービス、ヘルスケア、ライフサイエンス、医療機器、研究機関など）が、法令やガイドラインで求められる履歴データの保持要件に適合する場合顧客のレコードの項目値がどのように変更されたかの履歴を、過去に遡って調べる必要がある場合変更履歴を保管する仕組みを予めユーザに周知することで期待される、不正行為（コミッションに関係する金額の改ざんなど）の抑止効果コーポレイトガバナンスを強化したい場合項目監査履歴の特徴項目監査履歴データは、Salesforce 組織のデータストレージ制限には含まれませんので、ログを蓄積することでお客様組織のストレージが消費されてしまう心配はありません（項目履歴管理も同様の仕様です）データの変更履歴は、オプションの契約手続きが完了すると、本番組織に18ヶ月保管した後 Big Object にアーカイブされるよう自動的に仕様が拡張されますので、お客様側での特別な設定作業は不要です一部のオブジェクトに対しては、オブジェクトごとに保持ポリシーを定義できます。本番組織の保存期間は 0 〜 18 ヶ月、アーカイブの保存期間は  0 〜 無期限、の範囲で設定可能ですアーカイブデータには 、データローダーやSOQL または Bulk API によるクエリを実行することでアクセスできます 変更履歴を追跡するために必要な設定・操作項目の変更履歴を追跡するための基本的な設定手順は、項目履歴管理（標準機能）と同じです。レコードの変更履歴を管理する を参照ください。項目監査履歴（オプション）で必要となる設定や操作はに以下のものがあります。Salesforce メタデータ API を使用して、オブジェクト単位で変更履歴の保持ポリシーを更新できます。この設定を行うのは、アーカイブデータの保持ポリシーに設定されているデフォルト値（本番組織に18ヶ月、アーカイブは無期限）を変更する場合のみです。例えば、取引先オブジェクトの変更履歴は、本番組織には6か月間、アーカイブには5年間保持する、といった内容でポリシーを変更することができます。メタデータの具体的な編集例はヘルプ記事を参照くださいアーカイブデータを照会するには、FieldHistoryArchive オブジェクトに対して SOQL クエリを実行します。実行する SOQL 文の例は、SOQL with FieldHistoryArchive（英語）を参照ください データローダーで、FieldHistoryArchive オブジェクトのデータをエクスポートすることもできます一般的な考慮事項本番データのレコードを削除すると、関連する履歴レコードもカスケード削除される仕様は項目履歴管理と同じですが、Big Object にアーカイブされたデータは削除されません。このデータを削除するための手順は、「項目履歴および項目監査履歴データの削除」を参照してください項目監査履歴を有効にしている組織で、後からプラットフォーム暗号化を有効にした場合、アーカイブされたデータは自動的に暗号化されません。ヘルプ記事をご確認いただき、アーカイブされたデータを暗号化するためには弊社サポートにお問い合わせください学習ツールサクセスナビ：レコードの変更履歴を管理するヘルプ ：項目監査履歴実装ガイド：Field Audit Trail Implementation Guide(英語)トレイルヘッド：アプリケーションへのセキュリティレイヤの追加まとめ項目監査履歴により、長年にわたり、内部統制が適切に行われていることを確認し、第三者に証明できることによりコーポレートガバナンスの強化が実現できます。項目履歴管理（標準機能）の制限拡張オプションですので、ライセンス購入後に特別セットアップは必要にありませんが、保存期間を調整する場合には設定が必要です。

ログの取得方法

この記事で学べることイベントモニタリングに含まれる2種類のログの違いリアルタイムイベントモニタリングのログの取得方法イベントログファイル(EventLogFile)のログの取得方法イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントログファイル(EventLogFile)：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとは2種類のログは、取得方法が異なりますので、それぞれのログの取得方法について説明します。リアルタイムイベントモニタリングのログ取得リアルタイムイベントモニタリングでは、イベントデータをストリーミング視聴したり、Salesforceオブジェクトに保存してクエリしたりすることができます。保存イベントの多くは、大量データの最大6か月間(認証系ログは10年間)の保存に適したSalesforce Big Objectが対応します。Big Objectではデータが Salesforce ネイティブとして保存されるため、アクセスしてレポートやその他の用途に使用できます。一部の保存イベント（脅威検知イベントなど）は、標準 Salesforce オブジェクトが対応します。​リアルタイムログの記録開始については以下の記事を参照してください。ログの記録開始リアルタイムログの取得に必要な権限の設定[設定] から、次のいずれかの操作を実行します。[クイック検索] ボックスに「権限セット」と入力し、[権限セット] を選択します。[クイック検索] ボックスに「プロファイル」と入力し、[プロファイル] を選択します。権限セットまたはプロファイルを選択します。権限セットとプロファイルのどちらを使用するかに応じて、次のいずれかの操作を実行します。権限セットまたは拡張プロファイルユーザインターフェースで、権限を選択します。[設定の検索] ダイアログボックスに、「リアルタイムイベントモニタリングデータの表示」と入力します。[編集] をクリックし、オプションを選択して、[保存] をクリックします。「アプリケーションのカスタマイズ」権限についても上記の手順を繰り返します。元のプロファイルユーザインターフェースで、プロファイル名を選択し、[編集] をクリックします。トランザクションセキュリティポリシーを作成する予定の場合は、[リアルタイムイベントモニタリングデータを表示] と [アプリケーションのカスタマイズ] を選択します。[保存] をクリックします。リアルタイムイベントモニタリングを有効にするのに加えて、リアルタイムイベントオブジェクトに対するユーザ権限を設定します。リアルタイムイベントモニタリングオブジェクトには機密データが含まれる場合があります。リアルタイムログのストリーミングログの取得ここでは“Streaming Monitor”を利用してストリーミングイベントを確認する方法を紹介します。Streaming MonitorはSalesforceから提供している管理パッケージとなり、誰でも無償でご利用いただけますがサポートの対象外です。AppExchangeの“Streaming Monitor”ページより、パッケージをインストールしてください。https://appexchange.salesforce.com/listingDetail?listingId=a0N3A00000FYEEWUA5&tab=eパッケージが正常にインストールされると、アプリケーションランチャーにて“Streaming Monitor”が表示されます。​Streaming Monitorページにアクセスし、[Subscribe to a channel] → [Monitoring events] → [確認したいイベント]を順に選択し、[Subscribe]ボタンを押します。（Relay optionはデフォルトのままでOK）​確認したいイベント分だけ、No.3の手順を繰り返します。[Subscriptions]カラムに、指定したイベントログが表示されていることを確認します。（ここでは、一例として“LightningUriEvent”と“ReportEvent”をSubscribeしています）​この状態で実際のイベントが発生すると、画面上にキャプチャされたイベントログがグラフに表示されます。グラフ上の該当ログをクリックすることで、実際のログの内容を確認することができます。​​リアルタイムログのストレージログの取得リアルタイムイベントモニタリングの保存イベントの多くは、大量データの最大6か月間の保存に適したSalesforce Big Objectに保存されます。保存されたログデータはデータローダを用いてダウンロードすることが可能です。​データローダは、データを一括でインポートまたはエクスポートするためのクライアントアプリケーションです。データローダのインストールや利用方法の詳細は『データローダガイド』をご参照ください。データローダを開きます。[Export (エクスポート)] をクリックします。アーカイブされた活動レコードと論理削除されたレコードもエクスポートする場合は、代わりに [Export All (すべてをエクスポート)] をクリックします。Salesforceユーザ名とパスワードを入力し、[ログイン] をクリックします。ログインしたら、[次へ] をクリックします。オブジェクトを選択します。オブジェクト名がリストに表示されない場合は、[すべてのオブジェクトを表示] を選択して、アクセス可能なオブジェクトをすべて表示します。データのエクスポート先とするCSVファイルを選択または新規作成します。[次へ] をクリックします。データエクスポート用のSOQLクエリを作成します。[完了] をクリックし、[はい] をクリックして確認します。[View Extraction (抽出を表示)] をクリックして CSV ファイルを表示するか、[OK] をクリックして閉じます。イベントログファイル(EventLogFile)のログについてイベントログファイルのログは、“EventLogFile”という名前の専用オブジェクトに格納されます。EventLogFileオブジェクトではイベント種別、対象日（または対象時間）ごとに1件のレコードが作成され、ログデータがBase64に符号化されてLogFile列に格納されています。EventLogFile でサポートされているイベント種別イベントログファイルの保存期間はSpring’24のアップデートにより30日間から1年間に拡張されました。この保管期間の拡張を有効にするには、[イベントモニタリング設定] より、[イベントログファイルを保持]にチェックを入れてください。イベントログファイルの取得に必要な権限の設定[設定] から、次のいずれかの操作を実行します。[クイック検索] ボックスに「権限セット」と入力し、[権限セット] を選択します。[クイック検索] ボックスに「プロファイル」と入力し、[プロファイル] を選択します。権限セットまたはプロファイルを選択します。権限セットとプロファイルのどちらを使用するかに応じて、次のいずれかの操作を実行します。権限セットまたは拡張プロファイルユーザインターフェースで、権限を選択（または新規作成）します。[設定の検索] ダイアログボックスに、「イベントログファイルを参照」と入力します。[編集] をクリックし、オプションを選択して、[保存] をクリックします。「API の有効化」権限についても上記の手順を繰り返します。元のプロファイルユーザインターフェースで、プロファイル名を選択し、[編集] をクリックし、[イベントログファイルを参照] と [API の有効化] を選択します。[保存] をクリックします。イベントログファイルのダウンロードイベントログファイルはSalesforceオブジェクトのレコードであるため、さまざまな方法でダウンロードできます。イベントログファイルブラウザーデータローダーcURLスクリプトPythonスクリプトetcここではイベントログファイルブラウザーを使用し、base64デコード済みのcsvファイルを直接ダウンロードする方法を紹介します。組織にログインします。[設定] から、クイック検索で“イベントモニタリング”と入力し、[イベントログファイルブラウザー] を選択します。検索する日付範囲を入力します検索するイベント種別を入力します間隔（すべて / 毎日 / 1時間ごと）を入力します[適用] をクリックしますこのリストには、指定した日付や時間、イベント種別に該当するイベントログファイルが表示されます。これらのログをブラウザアプリケーションで直接開くことはできませんが、csvファイルとして手元にダウンロードすることができます。右端の▼マークのアイコンをクリックして、[csvファイルとしてダウンロード] を選択します。今回は一例としてLightningページビューイベントのログファイルをダウンロードします。このファイルをスプレッドシートで開いて内容を確認します。PAGE_URL項目でアクセスしたページやレコードを示すURLを、USER_ID項目でユーザのIDを確認することが可能です。学習ツールTrailhead - リアルタイムイベントモニタリングTrailhead - イベントモニタリング動画 - イベントモニタリング設定動画_基礎編（ログの有効化と取得）まとめイベントモニタリングで取得できる二種類のログ（リアルタイムログおよびイベントログファイル）の取得方法はそれぞれ異なります。今回はストリーミングや取得方法の一例をご紹介しました。ご利用開始後、適切な方法でログを取得しイベントモニタリングを最大限にご活用ください。

Account Engagement マーケティングデータ共有機能について

この記事で学べることAccount Engagement Advanced エディション以上で利用可能な「マーケティングデータ共有」機能について理解する「マーケティングデータ共有」機能を利用して、Account Engagement アカウントに同期する Salesforce レコードの選択・制御方法を理解するはじめにAccount Engagement を利用するにあたり、CRM としての Salesforce にあるリードまたは取引先責任者レコードを、プロスペクトレコードとして MA ツールである Account Engagemen へ同期させることで、マーケティング活動から営業活動まで一気通貫で業務を遂行したり、リード獲得から商談成立までのマーケティング ROI 分析が可能となります。​Salesforce で作成されたリードまたは取引先責任者レコードを Account Engagement へプロスペクトとして同期させるには、以下の条件を満たす必要があります。​Account Engagement 側のコネクターが接続済みであることAccount Engagement 側のコネクター設定にて「Salesforce でプロスペクトがリードまたは取引先責任者として作成されている場合は、Account Engagement にプロスペクトを自動的に作成する」オプションが有効化であることSalesforce リードや取引先責任者レコードにメールアドレスが入力されていること​デフォルトでは、上記条件を満たす全てのリードや取引先責任者レコードが、コネクター接続中の Account Engagement ビジネスユニット（複数の場合はいずれか）へ同期されますが、B2B/B2C ビジネスモデル別、商品・サービスのブランド別などの理由から、マーケティング活動を行う対象のレコードのみを適切なビジネスユニットへ同期させたい場合もあります。​そこで活用できるのが、Advanced エディション以上で利用可能な マーケティングデータ共有 機能です。マーケティングデータ共有の仕組みマーケティングデータ共有機能は、Salesforceに作成したリードと取引先責任者レコードを、Account Engagement へ同期させるか否か、また、複数のビジネスユニット を利用する環境においてはどのビジネスユニットに同期させるかを制御する機能です。​具体的には、各ビジネスユニットのコネクター設定における定義と、作成する Salesforce レコード側のマーケティングデータ共有制御用の項目の値によって、同期の有無や同期先ビジネスユニットを制御します。​イメージ図：​また当機能は、Account Engagement の Advanced エディション以上で利用可能です。設定の流れは以下の通りです。＊注意設定後、ルール定義や制御用のレコードの項目値に応じて、各ビジネスユニットの既存プロスペクトがごみ箱にアーカイブされたり、別ビジネスユニットに新規作成されるなど広く同期処理が実行されますため、作業は業務影響の少ないタイミング（休日夜間など）での実施をお勧めします。Salesforce の リード と 取引先責任者、商談オブジェクトおよび任意でカスタムオブジェクトそれぞれに対して、マーケティングデータ共有の条件指定用項目を作成する（ヘルプ）（既に同期先ビジネスユニットや非同期を指定可能な値を持つ項目（例：レコードタイプや担当部署など）がある場合はその利用も可能）リードと取引先責任者オブジェクトの両方に同じ名前（ラベル名およびAPI参照名）で作成する意図しない値の入力を防ぐため [値セットで定義された値に選択リストを制限します] オプションを有効にした選択リスト型の利用を検討する（例：値1=BU1、値2=BU2、値3=DoNotSync）必要に応じて、デフォルト値の定義 (レコード作成後に同期先を選択する運用の場合は、デフォルト値を未同期用の値（例：DoNotSync）にする、など）を検討する（ヘルプ）インテグレーション（コネクター）ユーザーに対し、当該項目への編集権限を付与する（ヘルプ）AccountEngagementと同期設定されている項目はMDS条件に利用できないため、Account Engagement 側には項目は作成しないSalesforce 各レコードのマーケティングデータ共有用の項目に、希望する同期先ビジネスユニットや未同期を指定する値を正確に入力する一括更新を行う場合は インポートウィザード または データローダ などの一括更新機能を利用する値は、同期させたい対象ビジネスユニットを示すもの（非同期を指定するための値がある場合はその値）で、正確に入力するビジネスユニット（複数ある場合は全て）でコネクターを一時停止するヘルプを参考に、各ビジネスユニットの Salesforce コネクター設定にて、マーケティングデータ共有を設定する定義できるルール形式は、カスタム項目｜一致する｜<値> のみ定義できるルールは、オブジェクトごとに 1 ルールのみ1-e に記載の通り、マッピング済みの項目は選択不可ビジネスユニット（複数ある場合は全て）でコネクターを再開する設定例：考慮事項（詳細はこちら）＊画像クリックで拡大可能学習ツールTrailhead：Pardot ビジネスユニットを設定するヘルプ：マーケティングデータ共有---抜粋---使用可能なエディション: 2019 年 2 月 12 日より後に購入またはアップグレードされた Account Engagement Premium Edition および Account Engagement Advanced Edition の Account Engagement Lightning アプリケーション-------------サクセスナビ：初期設定を完了しましょうまとめ本記事では、どの Account Engagement ビジネスユニットにどの Salesforce レコードを同期させる、あるいはさせない制御を可能とするマーケティングデータ共有機能について解説しました。​運用方法や他社事例などについてご質問がございましたら、 Account Engagement(旧Pardot) 日本 グループまたは質問広場～初心者から上級者まで～ 日本 グループにてご質問ください。​なお、当機能は Advanced エディション以上向けとなりますため、ライセンスのアップグレードなどご検討の際は弊社担当営業までお問い合わせください。​個別の技術的なご質問がございましたら、ヘルプ & トレーニングより弊社サポートへお問合せください。

組織の体制変更がある場合の対応のポイント

この記事で学べることSalesforce稼働後の（自社の）組織体制変更時の対応の流れを知ることができます組織体制変更時に使用するツールについて知ることができます組織体制変更時の対応の流れSalesforceのシステム管理者のみなさまは、普段新入社員のユーザを作成したり、退職するユーザを無効化したり、ユーザ情報の更新（部署やロール、プロファイルの変更）等のユーザ管理業務を行なわれていると思います。※ ユーザの管理については「ユーザ管理の便利機能」も参考にしてください。​今回は、期初や期末にみなさまの会社で行われる事があるであろう、組織の体制変更に伴い、Salesforceにどのような変更を行う必要があるかを考慮点含めて説明します。※人事異動の場合はユーザ情報の更新（ロール項目の変更）になりますが、今回はロール自体を変更する場合の作業の流れになります​一般的に、組織の体制変更がある場合、以下のような変更が行われると思います。それをSalesforceに反映させるための変更箇所は以下のとおりです。組織の変更に伴う変更点Salesforceの設定変更箇所組織の体制変更（新たな部署が設置される/既存の部署が統合されるなど）・ロール（自体）の変更・階層構造の変更既存の部門/部署名の変更・ロール（の名称）変更・ユーザの[部署名]の変更部署のメンバーの変更・ユーザの[ロール]の変更役職名の変更・ユーザの[役職]の変更お客様の担当替え・取引先や商談の[所有者]変更・活動の[任命先]変更注意事項：上記以外にも、例えば[ロール名]を条件にしたレポート、ダッシュボード、数式項目、フロー等の自動化設定がある場合は、それらの変更も忘れずに実施しましょうユーザの[ロール]や[役職]項目以外にも、プロファイル、マネージャーや権限セットの変更が必要な場合は一緒に変更しますSalesforceの設定変更箇所を把握したので、「早めに変更作業をしたい」と思うかもしれませんが、その前に！決めておくべきことがあります。移行ルール変更作業に着手する前に、関連部署のメンバーとあらかじめ以下を決めておくことで、変更作業をスムーズに進めることができます。組織の体制変更後に、Salesforceのデータをどのようなルールで共有するか（データへのアクセス権をどうするか）最終的に、どのようなロール階層にするか共有ルールを使用するか、使用する場合にはどのようなルールにするか誰がどの取引先を担当するか取引先の新旧担当者一覧の作成商談の担当はどうするか例：現在進行中の商談の担当者は変更しない、完了している商談の担当は変更しない（過去の実績を組織の体制変更前の担当で把握する必要がある場合は、担当者を変更しないでください）活動の担当はどうするか例：まだ完了していない活動の任命先を変更するか/しないか注意事項：上記以外のオブジェクトを使用している場合は、オブジェクト毎に担当をどのようにするかを決めておきましょう。​移行ルールが決まったら、次の流れで変更作業を行いますロール・共有ルールの変更ユーザ情報の変更各データの所有者変更１．ロール・共有ルールの変更まずは組織の土台となるロール、およびロールを使用した共有ルール（アクセス権）の設定を行います。ロールや共有ルールは、2.ユーザ情報の変更作業が完了するまでは反映されません。そのため、ユーザ情報変更作業前に、あらかじめ準備をしておきます。​組織の体制変更後の状態に合わせて、ロールを変更します。新たな部署が追加される場合は、[ロールの追加]からロールを作成します部署が統合される場合も、新たな部署を作成します。統合前の部署を残しておくと、退職したユーザのロールを変更する必要がありません​階層構造の変更はなく単なる名称変更の場合は、[表示ラベル]と[レポートに表示するロール名]を変更します階層構造が変わる場合は、[このロールの上位ロール]項目を変更します会社の合併など、大幅な組織体制変更の場合は、新しいロール階層を定義することをお勧めします。​組織の体制変更の前日までは、旧体制のまま業務を行う必要があると思いますので、あらかじめ新組織体制の準備でロールを作成しておき、新組織体制に変わるタイミングでユーザ情報を更新して新しいロール設定を反映させます。​次に、ユーザ情報を変更して、新しい組織体制を反映させましょう。２．ユーザ情報の変更組織の土台となるロールおよび共有ルールの設定が終わったら、ユーザ情報の変更を行います。​ユーザ情報は、以下3種類の方法で変更することができます。ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面から複数ユーザを一括で変更するデータローダを使用する​ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面の[ユーザをロールに割り当て]で、複数ユーザを一括で変更する（具体的な操作手順は、「ユーザへのロールの割り当て」（ヘルプ）をご覧ください）​データローダを使用する​組織の体制変更がある場合、一般的には、ロールを変更するタイミングでプロファイルや部署名、役職名等も変更になることがあると思いますので、それらを一度に変更ができるデータローダを使用することをお勧めします。（データローダの使い方ついては「初めてのデータローダ 〜Update編〜」（サクセスナビ）をご覧ください）​注意点：承認プロセスにマネージャー項目を使用している場合は、マネージャー項目も忘れずに変更しましょう。​ユーザ情報の変更が完了したら、取引先や商談などのデータを変更します。３．各データの所有者変更事前に定義した移行ルールに従い、データの所有者（や任命先）を変更します。​所有者の変更は、画面上から行える「所有権の一括変更」もしくはデータローダをご利用いただけます。どちらのツールが適しているかは、以下をご確認ください。​注意点：「所有者の一括変更」機能を利用できるのは、リード、取引先、カスタムオブジェクトのみです上記フロー以外のデータ（例：現在の所有者が所有している完了している商談など）の扱いについては、オプションで選択をすることができます。​以上で、組織の体制変更があった場合に、システム管理者様にて対応が必要な作業は完了です。学習ツールロールの項目（ヘルプ）ユーザの項目（ヘルプ）データの所有権の移行（ヘルプ）取引先の一括変更で、同時に移行されるデータについて（ナレッジ）まとめ変更作業を始める前に、移行ルールを決めておくことが重要ですデータ変更に使用できるツールは「所有権の一括変更」とデータローダがありますので、要件にあう方を選択しましょう

(2023年6月) Salesforceの運用に関する重要なお知らせ

この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート​動画で更新内容を学ぶhttps://play.vidyard.com/gmr5nhcSYK3igoV4Txtqxt​全ての資料をダウンロードして学ぶダウンロードはこちら​記事で更新内容を学ぶ本記事は「Salesforceの運用に関するお知らせ」の6月号となります。こちらの記事では、メンテナンス情報や技術情報、セキュリティ関連情報の構成で、特に重要な更新情報をピックアップしてご紹介いたします。必要なアクションをお客様にいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。​2023年6月のトピックはこちらになります。本記事では、前月との差分である赤字の部分についてと、特に重要な情報をピックアップしてご紹介します。​まずは製品イノベーションです。​6月11日に、日本のお客様が利用しているインスタンスがバージョンアップして、Summer '23になりました！サクセスナビに、Summer '23リリース 注目の新機能 ページを公開中です。来月には、今までの新機能ウェブセミナーに代わる、新機能の動画を公開予定です。ぜひ、今のうちに新機能ページをブックマークしておいてください。​関連リンクThe 360 Blogサクセスナビ : バージョンアップに備えましょうSummer '23新機能 特設ページオンラインコミュニティ：Admin Trailblazers、Release Readiness TrailblazersプレリリースサイトリリースノートRelease Overview Deck、Release in a BOXSummer '23 Release Highlights​続いて、Summer ’23 のリリースノートの更新情報をご紹介します。​ここでは、5月22日以降のリリースノートの更新情報の中から、現行動作に影響を与える可能性があるものをピックアップしてご紹介していきます。​全ての更新情報をご覧頂く場合は、スライド左下の「Summer '23更新情報一覧」の英語版をご確認お願いします。​No. 10 REST API で呼び出し可能なカスタムアクションの例外が発生した場合のロールバックの適用 (リリース更新)2回更新が入っています。5/22強制適用のスケジュールが変わりました。元は Winter ’24 の予定でしたが、Spring ’24 に変更されました。6/12より更新内容がわかりやすいように、英語のリリース更新名が変わりました。スライドに新旧両方の名前を記載しています。「似たような名称だけど、同じリリース更新ですか？」というご質問をいただくことがあるので、こちらで共有となります。​No. 11　サイトでのゲストユーザのオブジェクト、レコード、項目へのアクセスの確認[設定]画面に、「ゲストユーザー共有ルールアクセスレポート」というメニューが新しく追加されました。このレポートで、管理者様はゲストユーザーが共有ルールからどのレコードにアクセスできるかを確認できます。サイトを外部公開する時や、外部公開している既存サイトの設定変更をする時など、本レポートを参照して、意図しないレコードへのアクセス権が付与されていないかを簡単に確認することができますので、ぜひご利用ください。​No. 12　Lightning アプリケーションの CSRF トークンのセキュリティの機能強化 (リリース更新)2回更新が入っています。5/29Sandboxは変わっていませんが、本番環境のみ、強制適用のスケジュールがWinter '24に延期になりました。6/12このリリース更新はLightning Outには適用されない旨が追記されました。​No. 13　関連リストでの一括クイックアクションを使用した生産性の向上 (ベータ)現行動作に影響を与える類の情報ではありませんが、とても便利なベータ版機能です。注目度が高いと思いますので、共有します。​関連リストにクイックアクションを追加する方法の記載が、より明確になりました。もし、Sandboxで設定を試してみたものの、関連リストに追加したアクションがうまく表示できなかったという場合には、関連リストの種別を[拡張リスト]に変更して表示の確認をお願いします。​No. 14　The Ref ID Format for Email-to-Case Changed現在メール to ケースをご利用のお客様にとって重要な情報です。2回更新が入っています。6/5メール to ケースで使用されているRef IDの新しい形式の説明が追加されました。6/12この変更はWinter ‘24にリリースされる予定である旨が追記されましたメール to ケースのRef IDについては、新しいLgithningメールスレッドへの移行が推奨されています。Lgithningメールスレッドは、Salesforceのセキュリティ標準に適合する方法で作成されるトークンベースのスレッドのことです。設定画面の[リリース更新]から有効化できますので、まだ古いRed IDをご利用のお客様は、まずはSandboxで有効化して動作をご確認いただき、本番環境へ適用の準備を進めてください。​No. 15　Lightning Knowledge 移行ツールの実行Classic Knowledgeの実装におけるカスタムソリューションがある場合には、リファクタリングする必要性があることが追記されました。ClassicナレッジのデータモデルはSummer '25（2025年6月）で廃止される予定のため、それまでに、移行ツールを実行いただく必要がございます。その移行ツールを実行する前に、記事タイプを参照するVisualforce ページや Apexクラスなどのカスタムソリューションがあれば、それらを変更いただく必要があるという内容になります。​No.16　Hyperforce アシスタントを使用した Hyperforce への移行Hyperforce Assistantの使用方法が更新されました。お客様組織のHyperforceのアップグレードの日程が確定しなくても、Hyperforce Assistantを利用可能であることが記載されました。​続いて、多要素認証（MFA）に関する更新情報です。​「Salesforce 多要素認証に関するFAQ」ナレッジに、英語版のみですが、6月1日に更新が入っています。更新内容は、以下の通りです。​更新箇所は3つあります。いずれも、データローダのOAuthログインに関する内容です。​データローダにログインする際、ユーザ名とパスワードを入力する方法は、以下2種類あります。OAuthPassword Authenticatonデフォルトでは、OAuthが選択されており、ブラウザのログイン画面が表示されて、ユーザ名とパスワードを入力し、MFAが有効な場合は検証要素が求められます。その検証要素として、セキュリティキー、組み込み認証（Windows Hello、Touch ID、Face ID等）はサポートされていない旨が明記されました。​次は、インフラ強化に関する情報です。​​まずは、インスタンスリフレッシュです。多くの日本のお客様の組織が稼働する下記のインスタンスでインスタンスリフレッシュが予定されていましたが、一旦キャンセルになり、今年中に再度スケジュールされる予定です。2023/8/20(JST) : AP0, AP3, AP4, AP5, AP6, AP7, AP8, AP152023/8/6(JST) : CS5, CS6, CS31, CS57, CS58, CS72, CS73, CS74, CS75, CS76​新しい日程はTrustサイト、および、Salesforceからお客様へメールで通知をさせていただきます。また、インスタンスリフレッシュに必要な準備についてまとめた動画をサクセスナビよりご視聴いただけます。念の為、ご確認いただけますようお願いします。​関連リンクインスタンスリフレッシュメンテナンスインスタンスリフレッシュ、組織移行、継続的サイト切り替えって？インスタンスリフレッシュの概要と準備（動画付きの解説あり）​続いて、許可すべきIPアドレスとドメインに関する情報です。​「Hyperforce 上の Salesforce サービスへの中断しないアクセスを維持する」のナレッジに更新があります。HyperforceへのアクセスにおいてIPアドレスによる許可リストを構成しなければならない場合、それらのIPアドレスは弊社 Complianceサイト から確認できる旨が追記されました。 Complianceサイト のIPアドレスは、メールリレー用のIPアドレスではないこと、そして Marketing Cloud、Commerce Cloud のような Salesforce Platform 以外の製品のIPアドレスではないことが明記されました。High Scale Orders、Service Cloud Voice、Event Relayにおける既知の問題の対応時期についても更新があり、2023年度中にHyperforce上で利用可能になる予定であることが記載されました。​​関連リンク許可すべき Salesforce の IP アドレスとドメインHyperforce 上の Salesforce サービスへの中断しないアクセスを維持するSalesforce アプリケーションからのメールを受信できるようにする​続いて、リリース更新に関する情報です。​以下リリース更新は、Summer '23 で適用される予定でしたが、延期されました。​ゲストユーザによる承認申請の編集または削除の防止Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止​強制適用日は延期となりましたが、今後のリリースでは適用されますので、内容のご確認をお願いします。​上記は、次期バージョンである Winter ’24 で適用予定のリリース更新のご紹介です。ここでは、特に重要な更新を４つピックアップしてご説明します。MFA の自動有効化: お客様の組織に適用されるタイミングと方法の確認 (リリース更新)Spring '23 とSummer '23 のリリースに引き続き、Winter '24 のリリースでもMFAが自動有効化される組織がございます。自動有効化対象のお客様には事前にSalesforceからお知らせのメールが送信されますので、管理者様は弊社から送信されるメールのご確認をお願い致します。拡張ドメインの有効化Spring '23 と Summer ’23 のリリースで拡張ドメインの自動有効化が行われましたが、Winter ’24 でも拡張ドメインの有効化が行われます。またWinter'24での拡張ドメイン有効化が行われると、管理者様は拡張ドメインを無効化することができません。ケースおよび取引先責任者の暗黙的な子共有を保存しないことによる取引先共有の再適用の迅速化の実現 (リリース更新)このリリース更新の適用により、取引先オブジェクトの子レコードになるケースレコードおよび取引先責任者レコードに関する共有レコードが保存されなくなります。子レコードに関する共有レコードが作成されないため、共有ルール適用に関するパフォーマンスが向上します。一方で、共有レコードを参照するような個別開発を行っていた場合、そのカスタマイズの動作に影響を与える可能性がございますため、リリース更新の内容をご確認いただければと思います。​Chatter メール通知を送信するときの送信者名とメールアドレスの必須化 (リリース更新)このリリース更新が適用されると、Chatter メール通知の設定における「差出人名」と「メールアドレス」が設定されていない場合は、Chatterメール通知が送信されなくなります。リリース更新の情報をご確認いただき、それぞれの設定が行われているどうかご確認をお願いします。​続いて、その他の更新です。​前述しました通り、Winter '24 で拡張ドメインが強制適用されると、その後、管理者様は拡張ドメインを無効化することができません。拡張ドメインは影響度の大きい更新であるため、Winter '24 のリリースまでに適用できるようにお客様側でのご準備をお願い致します。​関連リンク拡張ドメインのスケジュールチェックリストSalesforce の拡張ドメインに関するよくある質問​続いて、フローに関するロードマップです。これまでのアナウンスの通り、Summer '23 のリリースでプロセスビルダーは新規作成できなくなりました。今後の自動化プロセスの作成はフローをご利用ください。また既存のワークフロールールやプロセスは移行ツールをご利用いただき、フローへの移行をご検討ください。関連リンクフローへの移行​最後に今後予定されている機能の廃止に関する情報です。​ここでは「Workforce Engagement」の廃止についてご紹介します。Workforce Engagementはコンタクトセンター等における作業量や人員配置の計画等をサポートする製品でしたが、現在のご契約が終了した時点で、ご契約の更新ができなくなります。​6月度分の更新情報は以上となります。最後までご覧いただき、ありがとうございました。