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 では確認ができないため、利用有無および対応方法については、開発会社や開発担当者様へご確認をお願いします。

インスタンスリフレッシュの概要と準備

「インスタンスリフレッシュ」メンテナンスについて、以下動画で説明していますので、ぜひご視聴ください。（イネーブルメントサイトとイベントモニタリングの情報は動画および資料に含まれておりません）​[動画] インスタンスリフレッシュの概要と準備 (1.約17分＋ 2.約14分)https://play.vidyard.com/aJQhixFTpdgNBzaSCFvEtb投影資料のダウンロードはこちら画面右下の歯車マークより再生スピードが変更可能です上記2つの動画の構成は、以下のとおりです。必要な箇所の確認をお願いします。インスタンスリフレッシュの概要と事前準備の概要（約17分）※インスタンスリフレッシュの概要インスタンスリフレッシュメンテナンス（ナレッジ）の内容を、見やすくリスト化した資料の説明インスタンスリフレッシュの事前準備（詳細）（約14分）システムメンテナンスのベストプラクティスの解説 ※お客様の実装により、インスタンスリフレッシュの前後で必要な準備・ご対応の解説ハードコード化された参照（4:13~）Salesforce内の設定や、Salesforceと連携している外部システムの設定に、ハードコード化された参照（例：https://ap3.salesforce.com ）がある場合、ご視聴くださいSalesforce Mobile SDK（8:26~）独自開発したモバイルアプリケーションをご利用の場合、ご視聴くださいメールログ（8:54~）以前は、インスタンスリフレッシュ後に、インスタンスリフレッシュ前のメールログをダウンロードする必要がある場合、インスタンスリフレッシュ前にメールログをリクエストいただく必要がありましたが、現在はその必要性は無くなりました。（そのため、このパートは割愛いただいて構いません）Live Agent（チャット）または SOS（9:45~）Live Agent（チャット）または SOS をご利用中の場合、ご視聴くださいスケジュールされたアクティビティ（11:40~）インスタンスリフレッシュ中やその前後にスケジュールされたアクティビティ（Job）がある場合、ご視聴ください。※インスタンスリフレッシュメンテナンスが予定されている組織の、すべてのシステム管理者様にご確認いただきたい内容です。動画ではなく、「読んで理解したい！」という場合は、動画で解説している内容を以下に纏めていますので、ご確認ください。​インスタンスリフレッシュの概要と目的​関連リンクサクセスナビ：インスタンスリフレッシュ、組織移行、継続的サイト切り替えって？ナレッジ記事：インスタンスリフレッシュメンテナンス​Salesforce のシステムメンテナンスの概要​上記スライドでは、インスタンスリフレッシュを含めた Salesforce で定期的に実施している システムメンテナンス の種類と概要を纏めています。その中で、本記事では、インスタンスリフレッシュの内容を説明します。​インスタンスリフレッシュの目的は、インフラストラクチャーのアップグレードを実施し、お客様が期待するパフォーマンスレベルを維持することです。インスタンスリフレッシュメンテナンスが予定されているインスタンスにある、すべての組織が対象になり、強化された新しいインフラのデータセンターにインスタンスを移行します。現状の所要時間は約90分（※）で、本番環境が対象のインスタンスリフレッシュメンテナンス実施中は、対象組織は原則リードオンリーモードになります。※：2023年4月時点の実績情報であり今後変更される可能性があります​IPアドレスおよびインスタンス名はインスタンスリフレッシュ後に、変更になります。お客様への事前通知は、「製品およびサービスに関するお知らせ」と併せて、Trust 通知がございます。Trust通知の登録は、インスタンスリフレッシュ後も維持されます。また、実施日の変更はできません。​関連リンクインスタンスリフレッシュメンテナンス組織の移行への準備方法サイト切り替えの概要と FAQ最適化されたサイト切り替えの概要と FAQ​Salesforce のシステムメンテナンスの中で、インスタンスが変更になる場合のイメージです。インスタンスリフレッシュと組織移行は、組織が別のインスタンスに移行されます。​インスタンスリフレッシュインスタンスリフレッシュは、従来の基盤間での移行（apX → apXX）です。インスタンスリフレッシュは、元のインスタン上のすべての組織が新しいインスタンスに移行されますので、完了後に元のインスタンスは破棄されます。​組織移行インスタンスリフレッシュ以外にも、インスタンス名が変更になるシステムメンテナンスとして、組織移行があります。組織移行には従来の基盤間での移行（apX → apXX）と、次世代基盤であるHyperforceへの移行（apX → JPNx）の２つのパターンがあります。組織移行では一部の組織がまとめて別のインスタンスに移行されますが、元インスタンスはそのまま継続して稼働を続けます。インスタンスリフレッシュと組織移行では、My Domain名や各ドメインに変更はありませんが、サーバーのIPアドレスは変更されます。​関連リンクサクセスナビ：インスタンスリフレッシュ、組織移行、継続的サイト切り替えって？上記は、インスタンスリフレッシュの全体プロセスについて、タイムラインをまとめたものです。​対象組織に1回目の通知が約2ヶ月に送信され、2回目の通知が約15日前に送信されます。（事前通知の送信時期については、現時点の実績情報であり、将来変更される可能性があります）​移行当日にメンテナンス開始時間になったら、移行の準備が開始され、優先システムメンテナス枠（4時間）内で、インスタンスリフレッシュ作業が実施されます。インスタンスリフレッシュの所要時間は約90分です。Salesforce にて、移行が完了・成功したことを確認した後は、お客様の組織は、新しいインスタンス上で稼働します。つまり、Salesforceの新しいインフラストラクチャが利用できるようになります！素晴らしいですね！​関連リンク製品およびサービスに関するお知らせTrustサイト優先システムメンテナスのスケジュール​上記はインスタンスリフレッシュの当日のタイムラインです。​インスタンスリフレッシュ開始後、対象組織はリードオンリーモードになり、その後インスタンスリフレッシュが始まります。リードオンリーモードの時間帯は参照のみとなり、外部データをSalesforceに取り込むような更新作業は実施いただけないため、メンテナンス開始前の準備作業とメンテナンス終了後の事後作業について、確認していきます。※Sandboxが対象のインスタンスリフレッシュメンテナンス実施中は、利用不可です​[2024/3/19追記]イベントモニタリングは毎晩のバッチ・プロセスにて処理されるため、インスタンスリフレッシュ前に処理されなかったイベントログデータは存在せず、インスタンスリフレッシュ中に新しいインスタンスの組織に追加されません。​​[2023/10/16追記]イネーブルメントサイト (旧称 myTrailhead サブドメイン)をご利用のお客様は、インスタンスリフレッシュや組織移行の実施前と実施後に追加作業が必要です。詳細は、組織移行またはインスタンスリフレッシュ後のイネーブルメントサイト (myTrailhead) へのアクセスに関する問題と対処方法（ナレッジ）のご確認をお願いします。メンテナンス開始前の準備作業（左側のオレンジ）メールログのリクエストインテグレーションの再起動、およびDNSキャッシュ更新の準備ローカルキャッシュ用の最新証明書を入手長時間実行ジョブのスケジュールの変更を検討外部サービスへのApexコールアウトで、System.getApplicationReadWriteMode()を使用していない場合、コールアウト処理を止める​メンテナンス完了・終了後の確認作業（右側の緑）Salesforce for Outlook（SFO）の再ログインLiveAgent（チャット）エンドポイントの確認・更新長時間実行ジョブがエラーの場合、再起動Trust通知 の登録確認Einsteinボットの再有効化​なお、上記に記載の作業は代表的な確認事項です。対象の機能を利用していたり、その実装がある場合は確認をお願いします。​インスタンスリフレッシュ に備えた準備（概要）この章では、インスタンスリフレッシュに備えた事前準備の概要を説明します。​​インスタンスリフレッシュメンテナンス のナレッジに、インスタンスリフレッシュに関する各種情報や、その準備、そして影響を受ける機能について網羅されています。ご利用いただいている機能によっては、事前/事後の作業が必要なものがあったり、また移行中は制限のある機能があります。ここからは、このインスタンスリフレッシュメンテナンス のナレッジに記載されている内容に沿って、お客様で必要な準備や対処があるのか、またどのような作業が必要なのかについて説明します。上記リストには、[分類]、[No.]、[質問]、[回答]、[参考資料]があります。[分類]で、”情報”、”準備”、”機能への影響”のいずれかに分類しています。そして、[対象機能]でどの機能に関するものか明記されていますので、ご利用になっている機能の質問と回答内容がひと目で分かるようになっています！便利ですね！上記は、インスタンスリフレッシュに関連する一般情報（よくいただくご質問）です。ほとんどの内容は、本記事の上部で既に説明した内容ですが、復習も兼ねて、上記リストの内容を今一度ご確認いただくことをお勧めします。​関連リンク「インスタンスリフレッシュ」ページ（投影資料のP.4をご参照ください）ナレッジ記事：リードオンリーモードの概要ナレッジ記事：優先システムメンテナンスのスケジュールサクセスナビ：Salesforceのメンテナンスを知ろうナレッジ記事：FAQ - ハードコード化された参照の更新ナレッジ記事：Salesforce のメンテナンス中、組織にどのような影響がありますか？ナレッジ記事：SalesforceのIP範囲 / 許可すべき Salesforce の IP アドレスとドメイン​上記も、インスタンスリフレッシュに関連してよくいただくご質問です。内容の確認をお願いします。​​関連リンク：製品およびサービスに関するお知らせService Delivery (inc Hyperforce)「タイムライン」ページ（投影資料のP.8をご参照ください）ナレッジ記事：製品およびサービスに関するお知らせSalesforce アーキテクチャについてMultitenant Architecture (マルチテナントアーキテクチャ)Trust 通知​次に、インスタンスリフレッシュの準備についてです。具体的な情報は、「インスタンスリフレッシュに備えた準備（詳細）」の章で説明します。ここでは、どのような準備が必要かの概要と参考資料を纏めています。​関連リンク：Certificates Changes グループSalesforce のシステムメンテナンスのベストプラクティス」ページナレッジ記事：ハードコード化された参照の更新ナレッジ記事：許可すべき Salesforce の IP アドレスとドメインここからは、インスタンスリフレッシュによる個別の機能への影響についてです。スライドの内容を確認しましょう。​関連リンク：Outlook/Teams, Gmail, and Inboxグループナレッジ記事：Salesforce for Outlook OAuth 再認証「メールログ」ページ（投影資料のP.25をご参照ください）ナレッジ記事：メールログのリクエスト​こちらも、インスタンスリフレッシュによる個別の機能への影響についてです。スライドの内容を確認しましょう。​関連リンク：「LiveAgent (チャット) または SOS」ページ（投影資料のP.26をご参照ください）「スケジュールされたアクティビティ」ページ（投影資料のP.27をご参照ください）ヘルプ : What do I need to do about my upcoming Salesforce instance refresh?こちらも、インスタンスリフレッシュによる個別の機能への影響についてです。スライドの内容を確認しましょう。関連リンク：大量のプラットフォームイベント変更データのキャプチャ開発者ガイド：イベントバスReplayIDEinstein.AI(Salesforce AI)こちらは、インスタンスリフレッシュによる影響はございませんが、よくお問合せ頂く内容です。念のため、内容の確認をお願いします。​インスタンスリフレッシュ に備えた準備（詳細）これ以降は、インスタンスリフレッシュに備えた準備の詳細を説明します。まずは、Salesforce のシステムメンテナンスにおけるベストプラクティスのご紹介です。これらは、インスタンスリフレッシュだけでなく、組織移行やサイトスイッチのメンテナンスにも当てはまるものです。​ハードコード化された参照の更新ハードコード化とは、URLに固有のインスタンス名（例えばap3など）を含むURLをコード内に直書きしていることを指します。メンテナンスが完了すると、インスタンス名が変わりますので、そのコードを含む処理が正常に動かなくなる場合があります。こちらの確認方法などは後半で説明します。ここでは、ハードコード化された参照とはどういうものを意味するのかを理解しておいてください。​許可すべきSalesforce のIPアドレスとドメインインスタンスリフレッシュが完了すると、IPアドレスが変わります。SalesforceのIPアドレスが変わることによる一般的な影響は以下のとおりです。皆様のオフィスからのSalesforceへのアクセスを、以前のインスタンスのIPアドレスを使用してフィルタリングしている場合に、Salesforceにアクセスができなくなります。Salesforceと連携しているシステム側で以前のインスタンスのIPアドレスを使用したフィルタリングを行っている場合に、そのシステムからSalesforceへの連携が停止します。​最低限実施いただきたいこと：メンテナンス前に、Salesforceへアクセスする端末およびSalesforceと連携しているシステムで、最新のIPアドレス範囲を許可リストに追加してください。追加すべきIPアドレス情報については、許可すべき Salesforce の IP アドレスとドメインのナレッジをご確認ください。​推奨事項：Salesforce サーバへのアクセスには、 IP アドレス許可リストではなく必要なドメインを許可する事を推奨しています。これを機に、IPアドレスではなく、ドメインを使用したフィルタリングに変更ができないかをぜひご検討ください。​Salesforceアプリケーションからのメールを受信できるようにするWebアクセスだけでなく、Salesforceから、みなさまの会社の社員に届くメールに対しても、IPアドレスでフィルタリングをしている場合は、TLS、SPF、DKIM、DMARCと言った標準メールセキュリティプロトコルを使用することをご検討ください。どうしてもそれらで代用ができない場合は、Webアクセスと同様、メンテナンス前に、最新のIPアドレス範囲が追加されていることをご確認ください。​優先システムメンテナンスのスケジュールSalesforceのシステムメンテナンスは、あらかじめ決められた優先システムメンテナンスのスケジュール枠内で実施されます。そのため、（みなさまの会社における）Salesforceのメンテナンスを計画する際は、優先システムメンテナンスの枠外で計画するようにしてください。優先システムメンテナンス枠は、お客様の組織のインスタンスによって変わりますが、主に日本のお客様の場合、第一、第三日曜日の未明です。詳細は、優先システムメンテナンスのスケジュールのナレッジをご確認ください。​それでは、ハードコード化された参照について、詳しく説明します。​ハードコード化された参照があるとインテグレーションや数式項目等の設定が壊れたり、メールテンプレートやナレッジ記事の画像が表示されなくなることがあります。対応方法としては、注釈1のように相対URLに変更いただく、注釈2のように、インスタンス名を含まない、汎用エンドポイントのURLや私のドメインのURLに変更いただくことになります。じゃあ、一体どこにハードコード化された参照があるのか。「検討がつかない・・・」とお困りのお客様はどうしたらいいでしょうか。​​関連リンク：ヘルプ：私のドメイン​​Salesforce内のハードコード化された参照の確認には、Lightning Experience 準備状況チェックをご利用いただけます。すべてのハードコード化された参照を検出できるわけではありませんが、設定画面から起動できるので、とても簡単です！ハードコード化された参照の箇所を確認したら、開発者の方へ共有し、更新を依頼します。また、ご自身が開発者である場合には、VSC（Visual Studio Code）を利用して、ハードコード化された参照を見つけて、更新することができます。​関連リンク：Lightning Experience 準備状況チェックで評価する項目Lightning Experience 準備状況チェックの開始Salesforce Extensions for Visual Studio CodeVisual Studio Code で Salesforce プロジェクトを作成して、ハードコード化された参照を検索​ここまでは、メンテナンス後に意図しないサービス中断等が発生しないために、事前に確認・対応をいただきたい内容でしたが、対応できなかった場合の動作について、説明します。​ハードコード化されている参照の中には、Salesforceサーバにより、メンテナンス後の新しいインスタンスにリダイレクトされるものがあります。例えば、ブラウザリンクやブックマーク、カスタムボタンやChatter投稿などが該当します。​ただし、リダイレクトによりパフォーマンスが低下する可能性があったり、永遠にリダイレクトされるわけではないこと、必ずしもすべての参照がリダイレクトされることを保証していないため、リダイレクトに依存するのは非推奨です。ハードコード化された参照は、可能な限り、メンテナンス開始前に、すべて削除・更新しておくことを強く推奨します。​先程、Lightning Experience 準備状況チェックで、Salesforce内でハードコード化された参照をある程度確認ができることをお伝えしました。こちらは、Salesforceと外部システムのインテグレーションをしている場合についてです。結論から申し上げると、必要な対応は、Salesforce内にハードコード化された参照がある場合と一緒です。​外部システムの設定において、ハードコード化された参照の有無を確認し、ある場合は、私のドメインのURLもしくは汎用エンドポイントのURLに変更をお願いします。​なお、上記では、現時点でApex WSDLを作成した画面を載せていますが、昔のApex WSDLでは、インスタンスが含まれたURLが記載されていました。そのため、その当時のWSDLを今も使用し続けている古いインテグレーションがある場合には、必ず確認するようにお願いします。​​こちらは、Salesforce Mobile SDKを使って、会社独自のモバイルアプリケーションを使用中のお客様に必要な対応について説明します。（Salesforce モバイルアプリケーションのことではありません）​最新バージョンのSalesforce Mobile SDKは、メンテナンスの影響を受けません。旧バージョンをご利用の場合は、メンテナンス前にアプリケーションを更新し、ユーザへ転送することを推奨します。​インスタンスリフレッシュ後にメールログを表示する必要がある場合、以前は、メンテナンス開始前にメールログをリクエストする必要がありましたが、現在はその必要性はなくなりましたのでご安心ください。​関連リンク：メールログをリクエスト​こちらはLive Agent（チャット）やSOSをご利用中のお客様が必要な対応についてです。​チャットを埋め込んでいるWebページやクライアントに、Salesforceが標準で提供しているリリースコートが使われているかを確認してください。​リリースコードの場合リリースコードをご利用の場合、メンテナンス後に以前のチャットサーバーに届いたチャット要求は、自動的に正しいチャットサーバに転送されます。そのため、すぐにチャットをご利用いただけなくなるわけではございません。しかし、インスタンスリフレッシュが完了した後に、古いデータセンターでインスタンスをホストしていたハードウェアは廃止されます。その後は、転送はされなくなりますので、メンテナンス完了後のできるだけ早いタイミングで、Webページのコードを、メンテナンス完了後の新しいリリースコードに更新するようにしてください。​チャットAPIエンドポイントの場合リリースコードを使わずに、カスタムRESTクライアント等で直接チャットAPIエンドポイントに要求を投げている場合には、メンテナンス後にはチャットAPIエンドポイントが変更となるため、メンテナンス直後に新しいチャットAPIエンドポイントを参照するようにクライアントに変更を加える必要があります。​最後に、SOSについてですが、SOS 製品群は廃止され、注文終了日以降、引き続きSOSをご利用いただくことはできません。そのため、現在もご利用中のお客様は少ないと思いますが、もし、「使っている！」という場合には、チャットと同様の対応が必要です。​​関連リンク：サーバエンドポイント URL が更新された後にチャットが動作しないスケジュールされたJob等のアクティビティやサーバープロセスに対するインスタンスリフレッシュの影響についてご説明致します。​インスタンスリフレッシュ実施前から継続していたアクティビティにつきましては、一旦停止されますが、インスタンスリフレッシュ後に再開されます。インスタンスリフレッシュの実施中にスケジュールされていたアクティビティにつきましましては、メンテナンス終了後にただちに開始されます。注意点になりますが、インスタンスリフレッシュ前に開始された一部の、Apex処理やBatch Apexジョブ、そしてREST APIやSOAP API、Bulk APIといったAPI処理は、メンテナンス期間後にエラーになる可能性があります。エラー発生時の対処方法としまして、インスタンスリフレッシュ実施後に再起動をして頂く事が可能ですが、長時間実行するような大きなジョブのスケジュールはインスタンスリフレッシュ実施後に（スケジュールを）変更して頂く事をお勧めします。​​関連リンク：Apex Callouts in Read-Only Mode (リードオンリーモードでの Apex コールアウト)​参考リソースサクセスナビ：インスタンスリフレッシュ、組織移行、継続的サイト切り替えって？ナレッジ：インスタンスリフレッシュメンテナンスナレッジ：リードオンリーモードの概要ナレッジ：Salesforce のメンテナンス中、組織にどのような影響がありますか？ナレッジ：ハードコード化された参照の更新ナレッジ：許可すべき Salesforce の IP アドレスとドメインナレッジ：優先システムメンテナンスのスケジュールナレッジ：製品およびサービスに関するお知らせナレッジ：組織移行またはインスタンスリフレッシュ後のイネーブルメントサイト (myTrailhead) へのアクセスに関する問題と対処方法​​

YouTubeチャンネル Salesforce Support のご紹介

Salesforce Supportではテクニカルサポートにお客様から寄せられたお問い合わせや、今後の新機能のリリース情報をもとにYouTubeコンテンツを作成し公開しています。現在、約746本の動画を公開中。総再生数は900万以上と世界中のSalesforceユーザーにご活用いただいております。​​おすすめ動画をPick Up!動的フォームを使うことで、柔軟にレイアウトをカスタマイズすることができます。動画では、有効化の方法や制限事項について紹介しておりますので、ぜひご活用ください！​動的フォームを使ったLightning レコードページの活用方法​​​日本語のプレイリスト英語コンテンツに加え日本語の動画も順次追加されており、現在25本の動画を公開中です。一般的なハウツーからトラブルシューティングまで、さまざまなコンテンツを1本約5分でご用意しています。その中からまずご覧いただきたい2本をピックアップしてご紹介します。MFA (多要素認証) | SalesforceのMFAについて（5:59）​Data Cloud はじめてのデータストリーム設定手順（5:36）​その他の動画につきましては、こちらの日本語プレイリストからご覧ください。​まとめテキストだけでは分かりづらい内容も、実際の画面を表示して分かりやすく情報をお届けしてまいります。ぜひチャンネルをご登録いただきご活用いただけますと幸いです。​YouTubeチャンネル Salesforce Support日本語プレイリスト日本語ウェブセミナープレイリスト（一部過去のウェブセミナーの動画も公開しております）​​

Salesforce導入支援パートナーの選び方

この記事で学べることSalesforce公式のパートナー専門性評価の仕組みSalesforce導入プロジェクトを成功に導く認定パートナーの選び方Salesforce導入領域へのパートナーの専門性を確認する方法Salesforce導入プロジェクトの成功には「最適な導入支援パートナー」の選定が重要です。しかし、Salesforce関連製品の高度化・パートナー社数の増加に伴い、自社にあった専門性を有するパートナーの選定は難しくなっています。そこでSalesforceでは、お客様の導入支援パートナー選定をご支援するべく、パートナーの専門性を製品・業界別に認定する「Navigatorプログラム」を運用しています。​Navigatorプログラムでは認定資格・プロジェクト件数・顧客満足度に基づき、定量的にパートナーの専門性を認定・開示しています。Navigator認定を活用することで、自社のSalesforce導入に対して、専門性が認められたパートナーを探し出すことができます。Salesforceパートナー専門性マップ製品・業界別のパートナー専門性（Navigator認定）を一枚絵に纏めたパートナーマップを公開しています。導入時のパートナー選定にお役立てください。製品・業界別パートナー専門性マップ (Navigator Map)学習ツールhttps://www.youtube.com/embed/beM0lYwZui4?si=SCHURgkwxl3UHSEPまとめSalesforce導入支援パートナー選定には「専門性の確認」が重要です。専門性の確認には製品・業界別パートナー専門性マップ (Navigator Map)がご活用いただけます。

バージョンアップに備えましょう

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 モバイルアプリケーションのバージョン 228 の廃止

この記事で学べることSalesforce モバイルアプリケーション バージョン228 の廃止の概要を知ることができますSalesforce モバイルアプリケーションを最新バージョンに更新する方法を知ることができます概要Summer '23（2023年6月）で、Salesforceモバイルアプリケーション バージョン228以下は廃止されます。Summer '23以降は、Salesforceモバイルアプリケーション バージョン228以下でログインすることはできません（エラーになります）既にSalesforce モバイルアプリケーション バージョン228 にログインをしている状態で、Summer '23リリースを迎えると、それ以降バージョン228のままで再ログインはできませんエラー発生による業務影響を回避するため、早めにSalesforce モバイルアプリケーションのバージョンを更新することを推奨します。iOS および Android両方に影響があります注意事項Salesforce モバイルアプリケーション バージョン230以上に更新するためには、最低でも Android 7.0 または iOS 13.4 の OS バージョンが必要です必要な対応Salesforce モバイルアプリケーションを バージョン230 以上に更新します。​※App Store または Google Play から自動更新を有効にしている場合、ほとんどのユーザはすでにアプリケーションの最新バージョンを使用しているはずなので、この変更による影響は受けません。​自動更新を無効にしている場合や自動更新を有効にしているか不明な場合は、以下の手順でSalesforce モバイルアプリケーションを最新版に更新することができます。​手順Apple Store もしくは Google Play で「Salesforce」で検索し、「Salesforce」アプリケーションを表示します。​※こちらはApple Storeの画面ショットです​​2.[アップデート]が表示されていたら、タップして最新バージョンに更新します（[開く]が表示されていたら、既に最新バージョンなので対応不要です）​注意事項Apple StoreやGoogle Playへのアクセスが制限されていたり、任意のアプリケーションの更新ができないように制御されている場合は、貴社内システム管理者様へご相談お願いします。​学習ツールSalesforce モバイルアプリケーションのバージョン 228 の廃止（ナレッジ）Salesforceの機能廃止（EOS/EOL）について（サクセスナビ）Salesforce 機能の廃止（ナレッジ）チェックリストSummer '23（2023年6月）までに、Salesforce モバイルアプリケーション バージョン228以下利用している場合、更新が必要であることを理解しましたSalesforce モバイルアプリケーションが最新版であるか（Google PlayやApp Store上で[アップデート]ではなく[表示]）であることを確認しました

[日本語(カタカナ)の表示ラベル変更]の準備について

この記事で学べることWinter '24で実施予定の[日本語(カタカナ)の表示ラベル変更]の準備について知ることができます。日本語(カタカナ)の表示ラベル変更とは？（どこが変わりますか？）Sales Cloud、Service Cloud、Platform等のSalesforce Platformを利用する製品において、ユーザーインターフェースの日本語表示ラベルに使用されているカタカナ表記の一部が、従来のJIS規格に準じた表記からより発音に近い表記に変更されます。（全126語）​*変更対象の完全なリストは、Winter '24 日本語(カタカナ)の表示ラベル変更（ナレッジ）からダウンロードできます。​これらのラベルが使用されている場所は以下の通りです。​これらのラベルの使用箇所の例例1) ユーザーが業務で使用する画面（変更前）フォルダ　→ （変更後）フォルダー​例2) システム管理者が利用する設定画面（変更前）ユーザ　→ （変更後）ユーザー​（変更前）マネージャ　→（変更後）マネージャー​例3) Salesforceのログイン画面​​​背景（この変更を行う理由）は？外来語の表記に関する内閣告示に従い、Salesforceの全ての製品やドキュメントでスタイルの一貫性を保つことが目的です。ソフトウェアの画面と技術製品のカタカナ語（外来語）については、Salesforceが日本語の画面を提供し始めた当初は、JIS規格に準拠した表記を使用するのが一般的でしたが、現在はより発音に近い表記が一般的となっています。*TableauやSlackといった買収製品では既に新しい表記が用いられています。​影響範囲と対応について教えてください影響範囲は、画面上の表示ラベルの変更のみのため、お客様のデータ自体への影響はありません。ただし、例として以下のような点については、運用によっては手順書等の修正対応が必要になる場合があります。事前に、お客様組織においての影響有無をご確認いただくことを推奨します。お客様が自組織のエンドユーザー用に準備した手順書内表記と実際の画面表記との差異（スクリーンショット、動画含む）が生じる可能性があります。お客様のRPA等で、表示ラベル名を元にした判定処理を実装している場合、正常に動作しない可能性があります注）表示ラベル名をもとにした判定は一般的に推奨されません。Salesforceのドキュメント（ヘルプ、Trailhead、開発者ガイド等）内の表記の更新は、Winter '24以降に段階的に実施します。変更が完了するまでは、画面表記とドキュメントとの差異が生じます。表示ラベルの文字数が増えることで、画面によっては表示ラベルの折り返し表示、あるいは表示しきれない文字の省略（切り落とし）が発生する可能性があります。​実施スケジュール*Sandboxプレビュー環境でのリリースタイミングは異なります（リリースの正式なスケジュールについては、Trustサイトをご確認ください）​学習ツールWinter '24 日本語(カタカナ)の表示ラベル変更（ナレッジ）Prepare for the Japanese Katakana Style Change （Spring '23 リリースノート）　まとめWinter '24で、日本語(カタカナ)の表示ラベルの変更が行われますWinter '24 日本語(カタカナ)の表示ラベル変更（ナレッジ）で変更対象を確認することができます自社に影響があるか早めに判断しましょう

Salesforceの機能廃止（EOS/EOL）について

この記事で学べることSalesforceのサポート終了/機能廃止に関する情報の確認方法Salesforce にもEOS、EOLがありますシステム管理者の皆様は、EOSやEOLという言葉を聞いたことがあると思います。Salesforceでも同じ概念があり、古くなった製品のサポートを終了（End of Support）したり、機能が廃止（End of Life）されることがあります。​※初耳というお客様は、機能廃止の方針（ナレッジ）に、Salesforceの機能廃止についての考え方が纏められておりますので、ぜひご確認ください。サポート終了/機能廃止の時期のお知らせSalesforceでは、原則として、機能を廃止する少なくとも12ヶ月前に、製品及びサービスに関するお知らせで通知をしています。また、月次で、以下のような機能廃止ダイジェストメールも送信しています。​​ダイジェストには、お客様のご利用中の機能に関する廃止について記載されています。毎月必ずご確認ください。廃止される機能をご利用の場合製品およびサービスに関するお知らせに、代替機能や対応方法が記載されておりますので、その情報を元にお客様にてご検討をお願いします。直近で廃止予定の機能Salesforce 機能の廃止（ナレッジ）に、今後廃止予定の機能・製品が纏められておりますので、ブックマークしていつでも参照できるようにしておくことをお勧めします。​学習ツール機能廃止の方針（ナレッジ）製品及びサービスに関するお知らせ（ナレッジ）まとめSalesforceの機能や製品は、廃止されることがあります原則、機能や製品を廃止する少なくとも12ヶ月前に、システム管理者様宛に通知をしています機能廃止ダイジェストメールは、毎月必ず確認しましょう

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編〜」（サクセスナビ）をご覧ください）​注意点：承認プロセスにマネージャー項目を使用している場合は、マネージャー項目も忘れずに変更しましょう。​ユーザ情報の変更が完了したら、取引先や商談などのデータを変更します。３．各データの所有者変更事前に定義した移行ルールに従い、データの所有者（や任命先）を変更します。​所有者の変更は、画面上から行える「所有権の一括変更」もしくはデータローダをご利用いただけます。どちらのツールが適しているかは、以下をご確認ください。​注意点：「所有者の一括変更」機能を利用できるのは、リード、取引先、カスタムオブジェクトのみです上記フロー以外のデータ（例：現在の所有者が所有している完了している商談など）の扱いについては、オプションで選択をすることができます。​以上で、組織の体制変更があった場合に、システム管理者様にて対応が必要な作業は完了です。学習ツールロールの項目（ヘルプ）ユーザの項目（ヘルプ）データの所有権の移行（ヘルプ）取引先の一括変更で、同時に移行されるデータについて（ナレッジ）まとめ変更作業を始める前に、移行ルールを決めておくことが重要ですデータ変更に使用できるツールは「所有権の一括変更」とデータローダがありますので、要件にあう方を選択しましょう

ユーザ管理の便利機能

この記事で学べることユーザ管理に必要な基礎知識を学ぶことができますユーザの管理に使用できる便利な機能を知ることができます知っていますか？Salesforceのユーザを削除することはできませんSalesforceのシステム管理者様の業務で欠かすことができないのものの1つはユーザ管理だと思います。新入社員が入る、長期休暇を取得するユーザがいる、異動するユーザがいる等の様々なイベントに対して、システム管理者様はユーザを作成したり編集したりされていると思います。​さて、ここで質問です。「ユーザが退職するとき」どのように対応しますか？​答えは、「ユーザを無効化する」です。Salesforceのユーザは一旦登録をすると削除をすることはできません。ユーザには様々なデータが紐付いています。例えば、そのユーザが担当（所有していた）取引先や商談、活動、カスタムオブジェクト等があります。そのユーザが退職した後も、そのユーザが勤務していた時の状態でデータを残しておけるように、削除ではなく「無効化」ができるようになっています。そして、無効化をすることで、そのユーザが使用していたライセンスが開放され、他のユーザがライセンスを使用することができるようになります。​ですが、何らかのエラーが発生し、すぐにユーザを無効化できない場合があります。（もちろんあなたは、退職後のユーザにはSalesforceにログインしてほしくありません！）​こんな時に使えるのが「凍結」です。凍結をしておけば、あなたがエラーの原因を確認（必要に応じてサポートへ問い合わせを）している間、そのユーザがSalesforceにログインできないようにすることができます。​注意点：「無効化」と異なり、「凍結」をしてもユーザライセンスは開放されませんので、他のユーザにライセンスを使用することはできませんので、ご注意ください。知っていますか？ユーザにもリストビューを作ることができますSalesforceには、オブジェクト（取引先や商談）毎にデータの一覧を簡単に表示できるように「リストビュー」という機能があります。システム管理者のみなさまは、現場のユーザが業務で使用するリストビューを作成しているかと思いますが、そのリストビューを[ユーザ]オブジェクトに対しても作成することができます。​特にユーザ数が多い組織の場合、全ユーザの一覧画面をスクロールして対象ユーザを探すのは大変だと思います。あらかじめ部署毎、ロール毎、プロファイル毎などの条件でリストビューを作成しておくと管理しやすくなります。（リストビューの作成方法は、「Salesforce Classic でのカスタムリストビューの作成」(ヘルプ)をご覧ください）​知っていますか？プロファイルにもリストビューを作成することができますリストビューつながりで、もう一つ、ユーザのアクセス権管理の便利機能をご紹介します。​※「プロファイルって何だろう？ユーザとどういう関係が？」という方は、「ユーザを登録する」(サクセスナビ)「プロファイルと権限セットを使って、アクセス方法や権限を設定する」(サクセスナビ)をご覧ください​規模の大きな組織では、ユーザに割り当てるプロファイルの数も多くなります。「プロファイル毎にどういう権限が付いているのか見比べたい」「複数のプロファイルの権限を一括で変更したい」という場面もあるかと思います。そんな時におすすめなのが、「プロファイルのリストビュー」です。​※ もし、[編集 | 削除 | 新規ビューの作成]リンクが表示されていない場合は、[拡張プロファイルリストビュー]を有効にします。具体的な手順は、「拡張プロファイルリストビューを有効化」(ヘルプ) をご覧ください。​以下は、プロファイル毎に、取引先のオブジェクト権限の設定を表示するリストビューのサンプルです。（リストビューの作成手順は「プロファイルリストビューの作成と編集」(ヘルプ) をご覧ください）​他のオブジェクト（取引先や商談など）のリストビューと同様に、必要な項目（オブジェクト権限やユーザ権限）を追加して、リスト上でインライン編集したり、複数プロファイルの権限を一度に編集することができます。​また、「特定の権限が付与されているユーザは誰か？」というように権限を条件にユーザやプロファイル、権限セットを検索したい場面もあるかと思います。そんな時には、AppExchangeサイトで公開されている「Permission Helper」アプリケーションをぜひご活用ください。​以下は、[すべてのデータの編集]権限を持つユーザの一覧を表示していますが、特定のオブジェクト権限を持つユーザの一覧を表示することもできます。知っていますか？設定画面で、ユーザを直接検索できますここまで、リストビューを活用したユーザ管理についてご紹介してきましたが、設定画面でも、グローバル検索と同じようにユーザを検索することができます。一人のユーザのパスワードリセットを行う場合などは、リストビューを表示して特定ユーザを探すよりも検索をしたほうがスムーズです。​以下は「標準」の文字列で検索をしていますが、[ユーザ]だけでなく[項目名]なども検索することができます。（あいにく、[プロファイル名]を検索することはできません）注意点：画面左上の[クイック検索]はメニューを検索するものです。ユーザや項目を検索するときは、画面上部の虫眼鏡から検索してください。​学習ツールSalesforce Classic でのカスタムリストビューの作成（ヘルプ）プロファイルリストビューの作成と編集（ヘルプ）Permission Helper（AppExchange）ユーザ管理（Trailhead）まとめ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でご利用可能で、一度に操作できるレコードの最大数は、5 百万件です。​データローダは（英語の）クライアントアプリケーションなので、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で事前検証しましょう