バックアップとリストア

この記事で学べることバックアップの重要性とバックアップすべきデータの種類を知ることができます主なバックアップ方法を知ることができます定期的にバックアップをしてますか？システム管理者の皆様は、データローダを使用する前など作業がうまくいかなかった場合に備えて、事前にバックアップを取っていると思います。ですが、定期的にバックアップを取得していますか？上記は、2018年のDreamforceで実施したデータ保護に関するアンケートの結果です。回答者のうち、なんと28％の方がデータ損失や破損を経験しており、その原因の内訳で最も多かったのが、人的ミスでした。システム管理者の皆様が気を付けていても、ユーザが誤ってデータを更新してしまったり、削除してしまう可能性は十分にあります。​また、以下は実際に起きたデータ損失の事例です。​データ損失や破損の原因は人的ミスだけでなくシステム的な要因や天災などがありますが、有事に備えて業務で使用する大切なデータについては、定期的にバックアップをして、復旧計画を立てておくことが重要です。​バックアップの重要性お客様組織の総合的なデータ管理およびセキュリティモデルの一環としてデータのバックアップおよびリカバリ計画を立てておくことは、システム管理者である皆様の役割です。手元にバックアップがあることで、有事の際にもタイムリーに復元ができるため、安心してSalesforceをご利用いただけます。​では、具体的にどのようなデータのバックアップが必要なのでしょうか。​実は、一般的に想像するデータ（取引先や商談、ケースなど）だけでは十分ではありません。詳しく見ていきましょう！​データの種類（データとメタデータ）Salesforceはマルチテナントアーキテクチャを採用しており、メタデータ駆動型アーキテクチャを搭載したサービスです。システム管理者の皆様は、データとメタデータの違いを理解しておくことは重要です。​データデータとは、取引先、取引先責任者、リード、商談、ケース、契約書、他のレコードなど、ユーザのすべてのレコードを意味します。データには、カスタムオブジェクトレコード、ファイル、コンテンツ、Chatter も含まれます。メタデータメタデータとは、カスタム項目、ページレイアウト、カスタムレポート、ダッシュボード、Apex や Visualforce のようなカスタムコードなど、設定情報を示します。​さぁ、どちらのデータのバックアップが必要でしょうか？答えは・・・両方です！データのバックアップが必要な理由は?システム管理者がデータの削除や更新をした後に、その操作が間違いであったことに気付くことがあります。データローダのようなツールを使用すれば、レコードの削除や更新を一括で行うことができるのは、皆様よくご存知だと思います。また、ユーザがインポートウィザードを使用する際、ソースファイルや項目の対応付けをちょっと間違えたことによってデータが意図しない結果になってしまうことがあります。​そのような事態に備えるため、データを定期的にバックアップすること、また、データ移行作業前には必ず手動のバックアップを行うことをお勧めします。メタデータのバックアップが必要な理由は?システム管理者や開発者、および高度な権限を有するユーザも人間です。誤ってカスタム項目の追加や削除、ページレイアウトの変更、レポートやダッシュボードの削除や変更、カスタムコードの変更をしてしまうこともあるでしょう。​こうした変更の多くは元に戻すことができないため、以前の設定を復元する必要が生じた場合に元に戻せるよう、メタデータのバックアップを取得しておくことが重要です。​それでは、Salesforceが提供している主なバックアップ機能をご紹介します。Salesforceが提供しているバックアップ機能​​機能概要制限リソース​Salesforce バックアップ（拡張機能）・管理パッケージをインストールし、バックアップポリシーを設定します・設定したバップアップポリシーに基づきバックアップを自動生成します・数回のクリック操作でバックアップからデータの復元ができます・バックアップと復元の状況をログでリアルタイムに確認できます・一部サポートされていないオブジェクトがあります（例：Bulk APIがサポートされていないオブジェクト、Big Object）・データを一括で復元することはできません（2023年11月時点）※リリース毎に機能が追加されています。最新情報は弊社テクニカルサポートもしくは営業担当者へお問い合わせくださいSalesforce バックアップを使用したデータの保護（ヘルプ）​データエクスポートサービス　　　　　　・設定画面から毎週もしくは毎月のエクスポートをスケジュールできます・エクスポートデータはCSV形式で出力されます・ファイルもエクスポートできます・データ量が多い場合はエクスポートに時間がかかります・エクスポート完了後24時間以内にダウンロードする必要がありますSalesforce からバックアップデータをエクスポートする（ヘルプ）​データローダ・PCにインストールしてエクスポートします・Soap APIやBulk APIの使用制限があります・定期実行するには開発が必要です・オブジェクト毎にエクスポートが必要です初めてのデータローダ Export編（サクセスナビ）​レポートのエクスポート・レポートを作成し結果をエクスポートします・定期実行はできません・項目数などレポートの制限が適用されますレポートのエクスポート​フルSandbox・本番環境の（データを含む）コピーを作成します・Unlimited Editionの契約、もしくはフルSandboxを購入する必要があります・更新ができるのは29日毎ですSandboxを作成（ヘルプ）この機会に、データエクスポートサービスをスケジュールしておきましょう！​[設定][データ][データのエクスポート][エクスポートをスケジュール]の各オプションについては、Salesforce からバックアップデータをエクスポートする（ヘルプ）をご確認くださいウィークリーエクスポートサービスの実行が完了すると、システム管理者宛にメールが送信されます。48時間以内にデータをダウンロードして安全な場所に保管してください。メタデータのバックアップ方法​​機能概要制限リソース​変更セット設定画面から、バックアップ対象のコンポーネントを変更セットに追加・送信することで、本番組織のメタデータを Sandbox に送信します。コンポーネントによっては変更セットに追加できないものがあります。・変更セットの概要（ヘルプ）​Sandboxの作成・更新設定画面から、Sandboxを作成または既存の Sandbox を更新すると、本番組織のメタデータがコピーされます。作成・更新するSandboxの種類によって、更新間隔が異なります。・Sandbox の作成（ヘルプ）・種類別 Sandbox ライセンスおよびディスク使用制限（ヘルプ）​Visual Studio CodeVSC（統合開発環境）を使用してメタデータをXML形式でローカルディレクトリに保存します。メタデータの制限があります。・クイックスタート: Salesforce 開発のための Visual Studio Code（Trailhead）・メタデータの制限データを復元する方法は？Salesforce では、お客様が各自のバックアップデータを復元する手段として、いくつかの機能をご用意しています。メタデータの復元Sandboxの作成や更新でバックアップしたメタデータを復元する場合は、変更セットを使用します。または、Visual Studio Codeを使用して一旦ローカルディレクトリにダウンロード（Retrieve）した後、そのメタデータを本番環境へアップロード（Deploy）します。データの復元データローダ、データインポートウィザード等を利用することができます。詳細は、データをインポートする方法の選択（ヘルプ）をご確認ください。​また、復元時には以下のような考意事項があります。レコードの復元（再作成）時に、元のSalesforce IDを指定することはできません。他レコードとのリレーションがあるデータを復元する場合、親→子の順番で復元します。例えば、取引先と取引先責任者を復元する時は、まず、取引先を復元した後に取引先責任者を復元しますレコードの復元（再作成）時に監査項目（作成日、作成者、最終更新日、最終更新者）を指定したい場合は、「監査項目の作成」を有効化することで実施できる場合があります。詳細は、監査項目を有効化する前の考慮事項（ナレッジ）をご確認ください履歴情報など、復元できないデータもあります。APIを使用して復元する場合、24時間あたりのAPI コール数の上限があります。レコード作成時に設定された自動処理（プロセスビルダー、トリガー、入力規則など）がある場合は無効にします。復元時に、他システムとのインテグレーションに影響はないか事前に確認しましょう。学習ツールSalesforce データのバックアップと復元のベストプラクティス（ナレッジ）Salesforce のレコードとデータを回復する（ナレッジ）まとめデータを定期的にバックアップしましょうデータ移行作業前には、必ず手動でバックアップを行いましょうメタデータのバックアップも行いましょう

サンプルデータを削除しましょう

この記事で学べることサンプル（トライアル）のデータを一括削除する方法を知ることができます“(Sample)“データを効率よく削除する方法Salesforceのトライアル組織には、以下のように“(Sample)”と記載された初期データ（サンプルデータ）が入っています。ご契約前であれば、サンプルデータを削除する機能をご利用いただけます。注意事項：[すべてのデータの一括削除]は、初期データだけでなく、お客様自身が作成したサンプルデータを含めて、組織のすべてのデータを削除します。[すべてのデータの一括削除]を使用して削除されたデータを復元することはできません。お客様自身が作成したサンプルデータは残しつつ、初期データのみ一括削除をしたい場合、もしくは既にご契約をされている場合は、[一括削除]機能を使用することができます。具体的な操作方法は、「新しい Salesforce 組織で事前にロードされたサンプルデータを削除する」（ナレッジ）の「オプション2」をご確認ください。​[一括削除]画面に表示されていないオブジェクトのデータを削除する場合は、データローダを利用します。データローダの操作方法は、「初めてのデータローダ 〜Delete編〜」（サクセスナビ）をご覧ください学習ツールトライアルデータの削除（ヘルプ）組織データのデフォルトへのリセット（ナレッジ）新しい Salesforce 組織で事前にロードされたサンプルデータを削除する（ナレッジ）まとめご契約前のお客様は、サンプルデータを一括削除することができます。ご契約後であったり、自動作成されたサンプルデータのみを削除する場合は、[一括削除]や[データローダ]を使用します。

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バージョン更新作業を推奨します

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

この記事で学べること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月度分の更新情報は以上となります。最後までご覧いただき、ありがとうございました。