はじめに
Salesforce組織の「私のドメイン（My Domain）」を変更する手順とその影響をまとめた。組織で使用しているサービスや環境によって、細かい手順や影響は異なるのであくまで参考程度に。
こんな人向け
- Salesforce組織のドメイン変更の必要に迫られているシステム管理者
- Salesforce組織をブランディングしたい人
ドメインの変更とは
ドメイン（URLの頭の部分）を任意の文字列に変更すること。あえて設定しない限りは自動で設定された文字列を使うことになる。
私のドメインとは
Salesforce 組織の URL 内にお客様固有のサブドメイン名を使用して、会社のブランドを示します。[私のドメイン] を使用することで、https://mycompany.my.salesforce.com のように URL に会社名を含めることができます。これらの組織固有の URL を使用して、カスタムログインページの設定、カスタムログインポリシーの設定、シングルサインオンの提供、ソーシャルアカウントによるユーザーのログインの許可を行うことができます。[私のドメイン] では、同じブラウザー内で複数の Salesforce 組織で同時に作業することもできます。
出典：私のドメイン
なぜドメインを変更するのか
ドメインを変更しようがしまいが、Salesforceの機能に違いはない。ではなぜドメインをわざわざ変更するかというと、自社名や自社サービスを使用することでそのSalesforce組織全ユーザー間で共通のブランド意識を持つため等のケースが挙げられる。
利用環境
- Sales Cloud
- Enterprise Edition（Winter ’24）
- システム管理者プロファイル
- 拡張ドメイン有効化済み（ほとんどの組織は有効化済みのはず、参考）
ドメイン変更による影響
ドメイン変更適用時に全ユーザーが自動でログアウトされる
途中で作業しているときに自動でログアウトされるとまずいので、混乱を避けるためにもユーザーに事前通知しておく必要がある。本番環境でのドメイン変更は誰も作業していない時間帯に設定することを推奨する。
今まで使っていたリンクを更新する必要がある
ブラウザのブックマークやリンクを新ドメ インのURLに変更する必要がある。 設定でリダイレクトを許可していれば古いドメインでも新しいドメインにリダイレクトされるが、リダイレクトをいつまでも使い続けるのは非推奨とされている。なのでユーザーにはなるべく早く新しいドメインに切り替えることを伝えるべき。
また、外部アプリの接続がある場合は再接続の必要があるかSandboxでテストする必要がある。
[私のドメイン] の変更後のリダイレクト
[私のドメイン] の詳細への変更をリリースするたびに、以前の私のドメイン] のホスト名が現在 の[私のドメイン] のホスト名にリダイレクトされます (このリダイレクトを無効にしている場合を 除く)。 ただし、[私のドメイン] を複数回変更した場合、 組織の最後の[私のドメイン] の URL セッ トのみがリダイレクトされます。 以前の [私のドメイン] のリダイレクトがあるかどうかを確認す るには、私のドメイン] ページの [リダイレクト] セクションを確認します。 詳細は、Salesforce へ ルプの「私のドメイン] のリダイレクト」 を参照してください。
出典: [私のドメイン] の考慮事項
リダイレクトの理解
[私のドメイン] の URL リダイレクトは中断を回避するのに役立ちますが、 永続的なソリューショ ンとして意図されるものではありません。 すべてのサービスでリダイレクトが正常に機能すると は限りません。 また、リダイレクトによって最終 Web ページの読み込みプロセスに1つのステッ プが追加されます。 また、 拡張されていないドメインのリダイレクトも Winter ’25 で停止されま す。 Sandbox では2024年8月から停止されます。 新しい [私のドメイン] をリリースするとき は、テスト中にリダイレクトを無効にして、 古い URLへのすべての参照を更新することを強くお 勧めします。
出典:以前の [私のドメイン] のホスト名によるリダイレクトの理解
ログインへの影響は多要素認証の方法によって異なる
出典：多要素認証の検証方法（図の一部） 多要素認証の方法によってはログインできなくなる
影響がないケース
ログイン時のMFA（多要素認証）に、以下のいずれかの方法を使用している場合は問題なし。
- Salesforce Authenticator
- サードパーティ認証アプリケーション（Google Authenticator等）
Before the scheduled deployment of your My Domain change, instruct affected users to register Salesforce Authenticator or a third-party authenticator app as a backup verification method. These types of verification methods aren’t affected by My Domain changes.
(私のドメインの変更を予定どおりにリリースする前に、影響を受けるユーザにバックアップの 認証方法として Salesforce Authenticator またはサードパーティの認証アプリを登録するよう指示してください。 これらのタイプの認証方法は、私のドメインの変更の影響を受けません。)
出典: Preserve Login Access During a My Domain Login URL Change
影響があるケース
以下、2つの方法でログインしている場合はドメイン変更による影響が起きる。
- セキュリティキー
- 組み込みAuthenticator
そのため、閉め出しを食らわないためにバックアップとしてSalesforce Authenticatorかサードパーティ認証アプリケーションの認証をしておく必要がある。
データローダーのServer Hostを変更する必要はない
ドメイン変更後に、データローダーを起動して通常通りログインすれば自動でServer Hostも変更されている。
Account Engagement（旧Pardot）に影響はない
事前に調べた限り、また実際にドメイン変更した結果、Account Engagement（旧Pardot）※を使用している組織でのドメイン変更による影響や事前対応事項はなかった。
影響なくとも、Account Engagementのユーザーにもドメイン変更する旨は通知することを推奨する。
※Salesforceのマーケティングオートメーションツール
変更手順
概観
図の「A. Active」に載っているドメインが各フェーズでアクセス可能なものを表している。
[私のドメイン] のプロビジョニングおよびリリース（図の一部）
変更の流れは以下の通り。
- スケジュールを組む
- 事前チェック
- Sandbox環境でテスト
- ユーザーに事前通知する
- 本番環境でドメイン変更
- ユーザーに完了通知する
1. スケジュールを組む
新ドメインのリリースしたい日から逆算し、Sandboxでの検証も含めたスケジュールを組む。前述の通り、リリースすると自動でログアウトされるため、ユーザーが作業をしていない時間帯にリリース日時を設定する必要がある。
また、プロビジョニングには最大24時間かかる可能性もあるとのことなので、プロビジョニング～リリースを丸１日取った余裕のあるスケジュールにすることを推奨する。
[設定] の [私のドメイン] ページに [ステップ 2: プロビジョニングが進行中] が表示される場合、新しいドメインをプロビジョニング中です。プロビジョニングプロセスは通常数分で終了しますが、最大 24 時間かかることがあります。
出典：[私のドメイン] の変更のリリース
2. 事前チェック
自組織で確認すべき事項を洗い出し影響確認し、作業が発生する場合は変更スケジュールに組み込む必要がある。
以下は実際に作業した際の一例。
- 変更前のドメインがハードコードされていないか（後日方法をまとめた記事をUP予定）
- 本番環境からメタデータをエクスポートしてテキストエディタで変更前URLを検索する
- ハードコードされたものをチェックし、該当するものがあれば相対参照する等の修正をする
- 外部接続しているアプリの有無
- 接続にURLを指定している場合はドメイン変更後に再接続等の作業が発生する可能性がある
- 社内のホワイトリスト（アクセス許可）の申請
- 社内のルールによるが、URLを指定して申請などを行っている場合は再申請が必要かどうか等
チェック項目の参考として、[私のドメイン] の変更プロセスについてで公開されているチェックリストや[私のドメイン] の変更の準備とスケジュールが役に立った。
3. Sandbox環境でテスト
いきなり本番でやるとトラブルが起きた場合に取り返しがつかないので、事前に必ずSandboxでテストすべき。
一般ユーザーとしてのログインテストのためにテスト用ユーザーも作成する。
私のドメインの設定>リダイレクトで「編集」をクリックする。
「～ユーザーに通知」をONにすると、リダイレクトするたびにユーザーにその旨を表示するページに遷移してから目的のページに遷移するようになる。
「リダイレクトを記録」をONにすると、変更前ドメインからのリダイレクト履歴が記録されるようになる。
リリース（変更適用）可能になるまで数分~24時間と幅があるので、本番の変更スケジュールには余裕を持つことをおすすめする。
リリースするまでは組織に何の影響も出ないので、この時点で何かしらの考慮漏れがあった場合はキャンセルすればOK。
問題なければ「新しいドメインをリリース」をクリックする。
普段通りの利用が問題なく可能か確認する。
- 自分（システム管理者）がログインできるか
- テスト用ユーザーがログインできるか
- データローダーが使えるか
- リダイレクトが正しくされるか
- ドメイン変更にあたって更新したもの (外部接続しているアプリ、ハードコードがあったApexやフロー等) が問題なく利用できるか
4. ユーザーに事前通知する
以下を網羅した通知を全Salesforceユーザーに実施する。
- ドメイン変更する背景
- 変更内容（変更前後のドメイン名等）
- リリース日時
- 影響
- 対応事項（影響によりユーザーに何かしらの対応をお願いしたい内容）
- 不具合や不明点があった場合の問い合わせ先
5. 本番環境でドメイン変更
事前に通知したスケジュールで、プロビジョニングとリリース（Sandboxでのテストと同様）を実施する。
6. ユーザーに完了通知する
完了した旨と、あればトラブルシューティングの方法や問い合わせ先をユーザーに通知する。内容はほぼ事前通知と同じ。
まとめ
実際にドメイン変更作業を行った際に確認した項目や影響、手順について説明してきた。
繰り返しになるが、使っているサービスや環境によって確認すべき項目や影響範囲、作業内容が変わってくるため、本記事の内容はあくまで参考程度にとどめて、よく公式ドキュメントを読んだうえで自組織に必要な確認項目や作業を洗い出してから進めてほしい。
参考
作業するにあたって、特に以下の公式ドキュメント記事が参考になった。
コメント