Salesforce Winter’25 リリースに関する情報をお届けします。
 

対象エディション

 
この変更は、Group、Essentials、Professional、Enterprise、Performance、Unlimited、および Developer エディションに適用されます。
 

影響範囲

メタデータ API を使用してコンシューマーログイン情報にアクセスしている、既存の外部クライアントアプリケーションのユーザーに適用されます。

概要

推奨されるセキュリティ標準に準拠するため、メタデータ API ではなく新しい credentials Connect REST API リソースを使用して、外部クライアントアプリケーション OAuth コンシューマーログイン情報にアクセスします。

影響

ログイン情報 Connect REST API リソースが Summer ’24 で導入されました。このリソースは、外部クライアントアプリケーションのOAuth コンシューマーの秘密への推奨アクセス方法です。

Connect REST API のログイン情報エンドポイントを介してコンシューマーの秘密にアクセスすると、コンシューマーの秘密をソース制御に誤ってコミットする可能性がなくなります。Winter ’25 以降、外部クライアントアプリケーションは、メタデータ APIを介してコンシューマーの秘密にアクセスできなくなります。

但し、Salesforce カスタマーサポートに事前に連絡して、メタデータ API を引き続き使用するように依頼することが可能です。

調査方法

１．外部クライアントアプリケーション OAuth 利用状況を確認します。

 
①：図_調査方法A-1：[設定] の [クイック検索] ボックスに「外部クライアントアプリケーション」 と入力します。
②：図_調査方法A-1：「外部クライアントアプリケーションマネージャー」をクリックします。
　→外部クライアントアプリケーションが使用されていない場合は、[ 図_調査方法A-１ ] のように表示されるます。この場合、対応不要です。
 

２．外部クライアントアプリケーション OAuth　利用状況を確認します。

 
③：図_調査方法A-2：[設定] の [クイック検索] ボックスに「外部クライアントアプリケーション」 と入力し、「外部クライアントアプリケーションマネージャー」をクリックします。
④：図_調査方法A-2：「外部クライアントアプリケーションマネージャー」をクリックします。
　→外部クライアントアプリケーションが使用されていない場合は、[ 図_調査方法A-２] のように表示されます。この場合、対応不要です。
 

※上記「１．外部クライアントアプリケーション OAuth 利用状況」「２．外部クライアントアプリケーション OAuth　利用状況」が表示されない場合は、対応不要です。

対応方法

１．外部クライアントアプリイケーション設定をConnect REST API に切り替えます。

 
①：図_対応方法A-1：[設定] の [クイック検索] ボックスに「外部クライアント」 と入力します。
②：図_対応方法A-1：[設定]をクリックします。
③：図_対応方法A-1：「Metadata APIをクライアントアプリケーションの子シューマーの秘密へのアクセスを許可」をオフにします。
④：図_対応方法A-1：「Reset APIを使用した外部クライアントアプリケーションのコンシューマーの秘密へのアクセスを許可」をオンにします。
 

２．対象の外部クライアントアプリケーションを選択します。

 
⑤：図_対応方法A-2：[設定] の [クイック検索] ボックスに「外部クライアント」 と入力します。
⑥：図_対応方法A-2：[外部クライアントアプリケーションマネージャー]をクリックします。
⑦：図_対応方法A-2：対象の外部クライアントアプリイケーション名をクリックします。
 

３．新しいログイン情報 Connect REST API を使用するように外部クライアントアプリケーションを更新します。

 
⑧：図_対応方法A-3：[設定]タブをクリックします。
⑨：図_対応方法A-3：「OAuth設定」横の下矢印をクリックします。
⑩：図_対応方法A-3：「 Connect REST API リソース」を「選択したOauth範囲」に移動します。
⑪：図_対応方法A-3：[保存]をクリックします。
 

※接続するアプリケーション側での設定の変更は必要ありません。

参考サイト

• REST API を使用した外部クライアントアプリケーション OAuth コンシューマーログイン情報へのアクセス (リリース更新)
• 外部クライアントアプリケーション
• 外部クライアントアプリケーション権限の設定
• REST API の概要
• Connect REST API 開発者ガイド
• メタデータ API を使用した外部クライアントアプリケーションの作成
• ExtlClntAppGlobalOauthSettings

Salesforce Winter’25 リリースに関する情報をお届けします。
 

対象エディション

 
この変更は、Enterprise、Unlimited、Developer、Essentials、および Professional エディションの Lightning Experience に適用されます。
 

概要

Spring ’24より、新しい Lightning 記事エディターと記事のパーソナライズが使用できるようになります。記事のパーソナライズを使用すると、ユーザー、ユーザー権限、およびレコードに基づいて項目を非表示または表示するカスタム表示ルールが作成できます。

影響

• 新しい Lightning 記事エディターが使用できます。
• 記事のパーソナライズを使用すると、ナレッジコンテンツがビジネスニーズに合わせて調整されます。
• アクセシビリティに対応しているコンテンツの書式設定機能と高度なテーブル編集ができます。
• 記事を作成し、エディターのサイズを好みに合わせて変更できます。
• ソースコンテンツのデザインを維持しながら、Google ドキュメントや Web サイトなどの外部ソースからコンテンツをシームレスにコピーして貼り付けることができます。
• 組み込みのアクセシビリティチェッカーツールを使用して、記事が W3C アクセシビリティ基準に準拠していることを確認できます。
• 表示ラベルをローカライズし、左から右へ記述される言語と右から左へ記述される言語の両方で作成できます。
• アコーディオン (折りたたみ可能なセクション) を追加して、大きな記事の読みやすさが向上されます。
• ソースコードエディターで、コードのコピー機能とコードの拡大/縮小機能が使用できます。
• エディターメニューから直接横線を追加できます。
• ユーザーのロケールに基づいて日付と時刻を表示できます。
• リストの番号の付け直しがサポートされます。
• クイックテキストが挿入できます。
• その他のユーザビリティが改善されます。

調査方法

ナレッジの Lightning 記事エディターと記事のパーソナライズを有効にします。

1. ナレッジが有効になっているか確認します。

　有効になっていない場合は[Lightning Knowledgeを有効化]にチェックを入れます。

 



 

2. [設定] の [リリース更新] に移動し、更新を見つけて使用を開始します。

 



 

3. リリース更新を有効にする。

　古い記事エディターは新しい Lightning 記事エディターに置き換えられます。

更新前：

更新後：

対応方法

• これらの更新の有効化後、現在のエディターの代わりに、新しい Lightning 記事エディターがユーザーに表示されます。それに応じて会社の内部トレーニング資料の更新が必要になる可能性があります。
• 記事のパーソナライズの有効化後、ナレッジレコードページは自動的に変更されないため、Lightning アプリケーションビルダーからシステム管理者が設定する必要があります。

参考サイトURL

• ナレッジの Lightning 記事エディターと記事のパーソナライズを有効化（リリース更新）

Salesforce Winter’25 リリースに関する情報をお届けします。
 

対象エディション

利用可能:：Salesforce Classic (一部の組織) と Lightning Experience の両方です。
利用可能なエディション：Group、Essentials、Professional、Enterprise、 Performance、Unlimited、Developer の各エディションです。

概要

 
Winter ’25 では、Salesforce は Sandbox、Developer Edition 組織、パッチ組織、スクラッチ組織、および Trailhead Playground での従来の(非拡張) 私のドメイン URLのリダイレクトを停止します。本番組織とデモ組織は、Spring ’25で停止します。
組織が2020 年 10 月より前に作成された場合、Salesforce は同じスケジュールで、インスタンス名を含み、私のドメインの名前を含まないホスト名のリダイレクトを停止します。影響を受けるホスト名と、これらのリダイレクトの終了をテストする方法を確認してください。
 

影響

組織内でＵＲＬによる遷移等を使用している場合、従来の(非拡張)私のドメインＵＲＬを利用している場合リダイレクトができなくなります。

調査方法

方法Ａ：VScodeでメタデータを取得し、影響を受ける URL の使用場所を確認します。

1. VScodeよりプロジェクトを作成します。
2. VScodeにpackage.xmlを作成します。

　package.xmlの内容はすべてのメタデータを想定します。

3. VScodeの検索機能を利用して影響を受けるURLを検索します。

　※対象のURLは「対象となるURLの表」を参照します。

方法B：リダイレクト時にメッセージを表示することで確認します。

1. [設定] より  [私のドメイン]を開きます。
2. [リダイレクト] セクションで、[編集] をクリックします。
3. [以前の [私のドメイン] URL を現在の [私のドメイン] にリダイレクトする]を選択します。
4. [現在の [マイドメイン] URL にリダイレクトする前にユーザーに通知する]を選択します。
5. [現在のサイトのURLにリダイレクトする前にユーザーに通知する]を選択します。
6. [警告付きでドメイン内の同じページにリダイレクト]を選択します。
7. 作業時にリダイレクトが発生した際に表示されるメッセージをもとに確認します。

方法C：リダイレクトログの記録による確認をします。

1. [設定] より  [私のドメイン]を開きます。
2. [編集] をクリックします。
3. 「ログリダイレクト」を選択し、変更を保存します。
4. 「マイドメイン設定」から「リダイレクト ログのダウンロード」をクリックして、リダイレクト ログをダウンロードします。

対応方法

このリリース更新で問題が発生する場合、どのように対応を行うことで問題発生を防ぐことが出来るのかその方法を記載します。

方法Ａ：調査方法Aで確認されたURLを置換します。

1. 調査方法Aの1～3を実行します。
2. 検索されたURLを「対象となるURLの表」を参照に置換します。

方法B：調査方法B,調査方法Cで確認されたURLを置換します。

1. 調査方法Bまたは調査方法Cを実行します。
2. 以後操作の際にリダイレクトが発生した際に表示されたメッセージをもとにURLの使用箇所を特定します。
3. URLを「対象となるURLの表」を参照に置換します。

対象となるURLの表

本番組織の URL 形式の変更します。

拡張ドメインがデプロイされたときに「Visualforce、Experience Builder、Site.com Studio、 およびコンテンツ ファイルの URL を安定化する」設定が有効になっていなかった場合は、これらの本番 URL 形式が変更されます。

拡張ドメインがデプロイされたときに「Visualforce、Experience Builder、Site.com Studio、 およびコンテンツ ファイルの URL を安定化する」設定が有効になっていなかった場合は、これらの本番 URL 形式が変更されます。

サンドボックス組織の URL 形式の変更

拡張ドメインがデプロイされたときに「Visualforce、Experience Builder、Site.com Studio、 およびコンテンツ ファイルの URL を安定化する」設定が有効になっている場合、これらのサンドボックス URL 形式は変更されます。

拡張ドメインがデプロイされたときに「Visualforce、Experience Builder、Site.com Studio、 およびコンテンツ ファイルの URL を安定化する」設定が有効になっていなかった場合は、これらのサンドボックス URL 形式が変更されます。

マイドメインなしでインスタンス化された URL

参考サイト

• 拡張ドメインの導入に伴う My Domain の URL 形式の変更
• ドメインホスト名のリダイレクトをログに記録する
• 私のドメインのホスト名
• ドメインリダイレクトの管理
• 以前の Force.com サイト URL のリダイレクトを無効にする
• マイドメインのログインポリシーを設定する

Salesforce Winter’25 リリースに関する情報をお届けします。
 

対象エディション

 
この変更は、Lightning Experience (すべての組織で利用できるわけではありません) およびすべてのエディションの Salesforce Classic に適用されます。
 

概要

 
セキュリティを強化するため、’25 Winter 以降、ログイン URL のクエリ文字列パラメーターとしてユーザー名とパスワードを渡して Salesforce にログインする「強制ログイン」が無効になります。この変更により、URL 経由の強制ログインを使用している実装やサードパーティインテグレーションや、直接ログイン (自動ログイン) リンクが壊れます。
サービスの中断を避けるため、強制ログインを使用しているインテグレーション機能を更新してください。拡張ドメイン適用前のURLにアクセスした際のリダイレクトが Sandboxは Winter’25、本番環境はSpring ’25より廃止されます。
 

影響

winter’25の更新により利用していた直接ログインのリンクが壊れるため、対応前のURLを使ったログインができなくなります。また、直接ログインを利用している実装(組み込みログインなど)や、AppExchangeでインストールしたアプリケーションも利用できなくなる可能性があります。
外部クライアントアプリまたは接続されたアプリへの強制ログインを使用する統合は、このリリース更新によって妨げられるため、それらがある場合は確認してそれに応じて移行する必要があります。DataloaderバッチからSalesforceにログインする際も、URLクエリ文字列内にログイン情報が含まれたものを利用する場合、正常にログインできない可能性があります。恐らく、URL クエリ文字列内のログイン資格情報のみが無効になります。

調査方法

 
組織での強制ログインの使用状況を確認します。

1. [設定]から、[クイック検索] ボックスに「ログイン履歴」と入力し、[ログイン履歴] を選択します。
2. 過去 6 か月間にわたる組織のログイン履歴を表示およびダウンロードします。
3. HTTP メソッド列を確認します。

　　HTTP メソッドが GET で、[ログインサブ種別] に値が入力されていない場合は、強制ログインが使用されていることを示します。
　　※HTTP メソッドはパスワードをリセットするためにも GET を表示しますので、[ログインサブ種別] の値がパスワードのリセットを反映していないことを確認してください。

対応方法

 
強制ログインの無効化までに最新向けの対応を実施します。

1. 強制ログインを使用しているユーザーを見つけた場合は、近日中に変更が行われることを通知し、Winter’25 までに設定を更新するように促してください。
2. 外部クライアントアプリケーションや接続アプリケーションへの強制ログインを使用しているインテグレーションがあれば、すべて更新・移行してください。

参考サイト

• Winter’25 で強制ログインが永久に無効に（リリース更新）
• Does “Forced Login is Permanently Disabled in Winter ’25” impact admin-initiated password resets?
• URL クエリ文字列を使用したログイン情報を無効化

こんにちは！眼鏡が本体ヤマです。

先日に続きDreamforce2022 Day3について、お知らせしたいと思います。

本日は朝からTech & Media Keynoteのセッションに参加しました。

写真を見てわかる通り着ぐるみがやたらでかいです。

セッションはメディア業界における活用を事例も含め、事例となった会社の担当者の方が説明してくれました。

公衆から個人化に向けて進んでいる中でTV業界もサブスクのようになる未来が見えてきている。

その中でSalesforceで何ができるのかといったお話でした。

本日二つ目のセッション「Innovation Keynote」に参加しました。

有名なF1の会社での活用事例も添えての内容でした。

ユーザが使いこなせない蓄積された複雑なデータをGenieで解決することで、

さらに個人ごとに特化した対応を実現していくとのことでした。

5年で色々変える！ということをF1の方が仰っていたので、どう変わるかが楽しみです。

ここでもCustomer360,Genieが出てきてますね。

写真はないのですが、この後 Communications Keynote のセッションにも参加しました。

その後、Salesforce Towerのすぐ目の前のSalesforce Westに行き、Dreamforce Wrap Up Sessionに参加しました。

今回のDreamforceの総集編を説明いただき、おさらいすることができました。

初参加のDreamforce で3日間セッションや会場、イベントを見て回った感想としては、

• アメリカが先に試したノウハウを学んで日本で実装できる点が有利であることを再認識。
• 3日間のための内装や会場の外装がすごい。上の写真のようなホールが10会場以上。日本でこのレベルの3日間をやる企業はあるのだろうか。
• 気候変動、サステナブルの話題が多く、そこをアピールできお金をかけられる環境ができているように感じた。

海外、特に日本語が通用しない観光地ではないところでの生活という時点で刺激はありましたが、

Dreamforceという大きな刺激も受け、日本に戻ってからの活力にしていきたいと思います。

簡単に参加できるような旅費と参加費用ではありませんが、是非皆様も一度参加いただければと思います。

最後まで読んでいただきありがとうございました。

こんにちは！眼鏡が本体ヤマです。

先日に続きDreamforce2022 Day2について、お知らせしたいと思います

朝はSalesforce Towerにお邪魔しました。

最上階の61階「Ohana Floor」です。

一口で食べられるお菓子やピンチョス的なものと、コーヒーなどがもらえるカウンターがありました。

ぱっと見た感じお寿司っぽくて全体的に和な雰囲気を感じます。

61階はスカイツリーのように360度窓になっていて、壮観でございます。

意外と海が近いんですね。

Tower Tourの後にブース見学をしまして、Trailblazer Questを進めた後、Tableau Keynoteに参加しました。

「Tableau Genie」今回は大体Genieが付きます。

GenieでデータをまとめてTableauで表現する。

将来はAIで予測に加えて意思決定もできるようになるとのこと。

これは画面左のGold会員とBasic会員とNon-Loyalty会員の購入経路について表したものです。

Tableau Keynoteの後にMarcBenioff氏とBono氏の対談セッションに参加しました。

その後展示場を案内してもらえるツアーに参加しまして、SalesCloudとServiceCloudの事例をメインに説明してもらいました。

さすがDreamforceにブースを出しているだけあって、ものすごく活用していました。

18時からOracle Park で開催されるDreamfestに参加しました。

Red Hot Chili Peppers!!

ありきたりですが、すごい迫力でした。

人数的に考えて当然ではあるのですが、前の立ち見は満員なんですが、観客席は結構空いていて、それもまた贅沢な感じでした。

こんにちは！眼鏡が本体ヤマです。

やってきましたDreamforce！

9/20が初日ということで、基調講演を受けたり、フラフラと見学したりなどをした後にJapanNightに参加しました。

写真と一緒にDreamforceの雰囲気をお伝えできればと思います。

まずは基調講演。見てわかるように満席です。

三つのキーワードが印象に残りました。

一つ目のキーワード「Genie」です。

Genieを通して今まで手動で対応していた顧客対応が自動化されていくとのこと。

詳細についてまでは説明がなかったためわかりませんが、とりあえず人気出そうなウサギだということはわかります・・。

二つ目のキーワードは「One Platform」です。

写真はGenieです。OnePlatformの写真が見当たらず、すみません。

写真にある「Magic」もよく出てきました。

三つ目は「Customer 360」です。

「Powered by Genie」により形になっていくところであると考えます。

こちらは地下のブースです。ビッグサイトの展示場と同じぐらいの広さです。

これと同じ広さのものや小さなものが別の階や違うビルにあり、回るだけでも1日では難しそうです。

Genie推しがすごい。

Genie推しがすごい２。

Genieの詳細についての説明はなかったため、私の中で構築イメージができていませんが、GenieとCustomer360とOne Platformという単語はとりあえず覚えました。

コロナの影響なのか、今まで聞いていた規模とは違って少しおとなしくなった感じはありましたが、それでも十分お祭りな感じで街の至る所にDreamforce関係の看板や広告などがありました。

では2日目に。

こんにちは！

Spring ’23から全てのSalesforce組織でICUロケールが有効化されますが、

一体ICUロケールとは何なのか、具体的に何が変わってどう対応する必要があるのか

まとめているサイト等が少なかったため今回はICUロケールの影響や有効化に伴う修正について

具体的な手順を踏まえてご紹介します。

目次

1. 1.ICUロケールとは？
2. 2.ICUロケールの適用時期と影響
3. 3.実際に必要な作業
4. 4.まとめ

1.ICUロケールとは？

国や言語ごとに日付や時刻、数値などを表示するために形式を規定するものをロケールと呼び、

Salesforceでは以下の二つの形式が存在します。

一つ目はJDKロケールです。 JDKとはJava Development Kitの略称で、Oracleが提供しているJavaの開発環境に則った形式のことです。

Winter ’20よりも前に作成されたSalesforce組織で使用されていたロケールはこちらになります。

しかしこちらのJDKロケールには以下の三つの問題点があります。

・定期的な更新が行われない
・国際標準との整合性が不足
・より新しいバージョンのJDKでは使用できない

新しいロケール形式に切り替える理由は？

これらの理由により全ての組織が次のICUロケールへと切り替わっていくこととなりました。

ICUとはInternational Components for Unicodeの略称です。

このロケールは最新の国際標準に対応でき、国際的なメンテナンスと管理が行われているため、

JDKロケールの問題点を全て対処することが出来ます。

Winter ’20以降に作成されたSalesforce組織では、ICUロケール形式がデフォルトで有効になっています。

しかしWinter ’20以前に作成された組織においてはデフォルトがJDKロケールであり、

この更新によって既存機能が正常に動かなくなる可能性があります。

よって一部のプログラムを修正する必要が出てきます。

どちらのロケールを現在使用しているかわからない方は

こちらのナレッジ記事の対応を行って確認することが出来ます。以下がその対応となります。

組織で ICU 形式が使用されているかどうかを判断するには、リリース更新を確認します。

・[設定] から、[クイック検索] ボックスに「リリース更新」と入力し、[リリース更新] を選択します。 　
　[アーカイブ済み] タブに [ICU ロケール形式を有効化] が表示され、完了とマークされている場合は、 　
　リリース更新が完了しており、組織でICU が使用されています。 　
　リリース更新カードに緑のチェックマークが付いていて、右上隅に「完了」と表示されます。

・[ICU ロケール形式を有効化] リリース更新がリリース更新コンソールの別のタブに表示されている場合は、 　
　[開始] をクリックして更新の詳細を確認します。 　
　「ステップバイステップガイドに従って、この変更の影響を理解して最小限に抑える」セクションに 　
　「この更新は、テストできる状態になりました。」と表示された場合は、組織で ICU 形式が使用されています。 　
　それ以外の場合は、組織で JDK 形式が使用されています。

2.ICUロケールの適用時期と影響

ICUロケールの適用時期について、初めはSpring ’22に適用されるという話だったのですが、

2021年11月29日にリリースノートの変更で延期がアナウンスされ、Spring ’23での適用となりました。

具体的には2023/1/10以降に適用されます。

また、この適用で何が変わり、どのような影響を受けるのかについてですが、 ロケールを日本語（日本）にしている場合、次のような変化があります。

新しいロケール形式での変更点は?

これによってパッケージまたはコードなどで明示的に今回対象となる部分(日付等)の

フォーマット(表示形式)指定をしている場所は影響を受けることが予測できます。

3.実際に必要な作業

作業内容についてはこちらのHelpを参考に具体的な手順をまとめました。

新しいロケール形式の採用方法 また、ICUロケール有効化の際は初めにSandBoxで

確認してから本番環境の有効化を行ってください。

実際に影響を調査・修正を行う為の手順は以下になります。

1. 1.ICUロケール有効化前の確認
2. 2.ICUロケール有効化前のApex等のプログラム修正内容の整理
3. 3.プログラムの修正
4. 4.ICUロケール有効化
5. 5.ICUロケール形式有効後の動作確認
6. 6.本番環境へリリース、本番環境での動作確認

ICUロケール有効化前の確認 まずsalesforce組織にインストールしたパッケージについて

ICU形式と互換性がある事をパッケージプロバイダに確認しましょう。

組織へインストールしているパッケージについては、下記手順から確認して互換性を調査確認してください。

「設定」　→　クイック検索ボックスに「パッケージ」を入力　→　「インストール済みパッケージ」を参照

例)パッケージ「A」と「B」をインストールしていた場合　→　AとB両方のヘルプページやサポートサービスを確認する

次に下記ヘルプページによるとICU形式はAPIバージョン45.0以降で使用可能となっている為、

ICU形式が使用可能なAPIバージョンかどうかを確認する必要があります。

この際、組織とAPEXのAPIバージョンを両方確認してください。

新しいロケール形式の採用方法

確認は以下の手順で行います。(Salesforcdeサポートに確認済み)

1.組織のAPIバージョンが45.0以上であることを確認
2.APEXのAPIバージョンが45.0以上であることを確認（SOAP APIやREST APIも対象）
3.APEXのAPIバージョンが45.0未満である場合、その対象が外部パッケージにて利用されている場合は、 　
　ご提供元企業様へ影響があるか確認する。
4.「APEXのAPIバージョンが45.0未満かつ外部パッケージ」以外について、
　バージョンアップが必要 　
　（バージョンアップを行わない場合、salesforceサポートは責任を持てないとのことなのでその際は自己責任となります。）

組織のAPIバージョンを確認する手順はこちらになります。

・Salesforce Classicの場合 　「設定」　→　クイック検索ボックス「API」入力　→　「開発」下の「API」クリック　→　
　「Enterprise WSDLの生成」クリック　→　 　Installed Packageの一覧で「Generate」ボタンをクリック
・Lightning Experienceの場合 　「設定」　→　クイック検索ボックス「API」入力　→　インテグレーション下の「API」クリック　→　 　
　「Enterprise WSDLの生成」クリック　→　「Generate」ボタンをクリック

※Sandbox環境の場合はGenerateせずにキャンセルをクリックしてください。（試したらエラーになりました。）

参考) Salesforce の Edition および API バージョンを確認する方法 　

ApexのAPIバージョンを確認する場合は 　

「設定」　→　クイック検索ボックス「Apex」入力　→　「カスタムコード」下の「Apexクラス」及び
「Apexトリガ」クリック　→　 　APIバージョン45.0未満の物がないか確認する

ICUロケール有効化前のApex等のプログラム修正内容の整理

APIバージョンに問題がない事が確認できたら修正内容を整理するため、組織のロケールを取得しましょう。

下記のSOQLを実行することで組織のロケール状況を確認することができます。

SELECT toLabel(LocaleSidKey) LocaleName, LocaleSidKey, Count(id) UserCount FROM User where IsActive=true GROUP BY LocaleSidKey

このような環境の場合、日本のユーザーしかいないため先ほど確認した変更点にのみ対応します。

（他の国、言語のユーザーがいる場合はそれぞれのロケールに基づいた変更に対応します。）

変更対象となるデータ型などを確認の上、Apexや各コンポーネントにおいての使用状況を整理しましょう。

確認対象は、レポート、数式、入力規則、自動ワークフロー、項目ルックアップ検索条件等です。

どこに注意して整理すればいいのか？

・例えば月の桁数が新形式では変化しているため(01　→　1)。年月日を桁数で取っている場合などは注意します。
・検索条件でハードコード化された日時値を使用している場合、 　検索条件が上手く機能せず、値を新しい形式に合わせる必要があります。
・日本ではありませんが、新しい形式で新たにカンマが追加されているロケールがあります。(英語（カナダ）等) 　
　カンマは検索条件の区切りに使用されるため、検索条件の誤動作に気を付けましょう。

また、Apexの調査をする際には下記の対象メソッド群をGrepして検索するなどして整理します。

Date.format(),Date.parse(),DateTime.format(),DataTime.parse(),DateTime.formatLong()等

Auraコンポーネントの場合、$Localeグローバル値プロバイダがSF Platformから形式を取得して使用しているため $Localeを使用している部分がないか整理する。

→$Localeについて プログラムの修正

影響のありそうな部分を整理出来たら実際に修正していきます。

注意点や公式Helpのコード例を参考に修正していきましょう。

修正を行った後は実際に有効化を進めます。

ICUロケール有効化

下記手順に従って有効化を行います。

「設定」　→　クイック検索ボックス「リリース更新」入力・選択　→　「ICU ロケール形式を有効化」 →　「使用開始」　→　手順に従って進める

※英語 (カナダ) ロケール (en_CA) では、下記に沿って個別の有効化が必要です。

「設定」　→　クイック検索ボックス「ユーザインタフェース」入力・選択　→　「通貨表示設定」の「en_CAロケールのICU形式を有効化」　→　「保存」クリック

ICUロケール形式有効後の動作確認

有効化後はまず「ICUロケール有効化前のApex等のプログラム修正内容の整理」にて整理した修正対象と実際の

修正内容から、テストケースを作成して、実行します。

※この時、単体レベル（各項目が正しく修正されていること）だけでなく、業務的な面まで全体的な処理が通ることまで確認できるようテストケースを作成するようにします。

問題なければSalesforce上などで動作確認します。

この際、有効後においてもレコードの詳細画面上表示の変化を確認できませんでした。（タイムゾーンや地域で日本を指定していた場合） 　

例：タイムゾーンが「日本標準時（Asia/Tokyo)」、地域が「日本語 (日本)」の場合 　
　　リリース更新（ICU ロケール形式）無効：（日付項目）2021/12/24 （マイナスの通貨項目）- ¥ 1,000 　
　　リリース更新（ICU ロケール形式）有効：（日付項目）2021/12/24 （マイナスの通貨項目）- ¥ 1,000

実際に表記の変更を確認できる手段としてChatterの日付が挙げられます。

変更後は投稿日日が2021/08/25/(11:31)のような形式から以下のように年月日表記となります。

もしICUロケール有効化前の確認でサードパーティアプリケーションを使用していた場合データが新形式で解析されることを確認します。

ほとんどのインテグレーションはデータ形式を中立保存するようですが、入力または出力専用でデータ形式が設定される場合もあるとのことです。

本番環境へリリース、本番環境での動作確認

「ICUロケール有効化」を参照の上本番環境でも有効化を行い、リリースします。その後テスト同様動作確認を行いましょう。

問題がなければ対応は終了です。

4.まとめ

・今後は全ての組織がSpring’23(2023/1/10)にICUロケールへと切り替わる。
・切り替わることによって既存機能に不具合が起きる可能性がある。
・Winter ’20以前に作成された組織ではJDKロケールを使用している可能性があるため 　現在の形式を確認する。
・ICUロケールを使用していない場合は手順に従って有効化を行う必要がある。
・レコードなどの表示形式は変わらないが、ロケールに基づくメソッドを使用した箇所など影響の出そうな場所を 　
　修正する必要がある。