【Salesforce】Salesforceで退職者の所有レコードを引き継ぐ時の所有者変更

Salesforceを運用していると、社員の退職や異動に伴い、そのユーザーが所有しているレコード(取引先、商談、ケースなど)を別のユーザーに引き継ぐ必要が生じます。所有権を正しく変更しなければ、レコードが誰も管理しない状態になり、営業活動やサポート業務に支障が出ます。本記事では、退職者の所有レコードを引き継ぐ際の所有者変更方法について、具体的な手順から注意点、失敗パターンまで詳しく解説します。この記事を読めば、スムーズにレコードを引き継ぎ、業務の継続性を確保できるようになります。

退職者のレコード引き継ぎにおける所有者変更の基本

Salesforceでは、各レコードに「所有者」という項目があり、そのレコードを管理する責任者を示します。所有者はユーザーまたはキュー(共有グループ)のいずれかです。退職者が所有するレコードを引き継ぐには、その所有権を別のアクティブユーザーまたはキューに変更する必要があります。所有者を変更する方法はいくつかあり、変更するレコードの数や運用ルールに応じて適切な方法を選びます。

基本的な所有者変更は、レコード詳細ページの「所有者」フィールドを編集するか、リストビューから一括で変更できます。しかし、大量のレコードを扱う場合や、特定の条件に基づいて変更する必要がある場合は、データローダーやApexを使用したバッチ処理が必要になることもあります。

所有者変更を実行する前の確認事項

所有者変更を行う前に、以下の点を確認しておかないと、操作中にエラーが発生したり、意図しない権限設定になったりします。

必要な権限の確認

所有者を変更するには、変更を実行するユーザーに以下の権限が必要です。

• 「すべてのデータの参照・編集」権限(システム管理者プロファイルなど)
• 対象オブジェクトに対する「転送」権限(プロファイルまたは権限セットで設定)
• 新しい所有者となるユーザーがアクティブであること

権限が不足している場合、所有者変更フィールドが表示されなかったり、変更操作が拒否されたりします。その場合は、システム管理者に権限付与を依頼してください。

レコードの参照整合性と共有設定

所有者を変更すると、そのレコードの共有設定が再計算される場合があります。特に、親子関係を持つレコード(取引先と商談など)では、所有者変更が子レコードの共有にも影響することがあります。また、キューに割り当てられたレコードをユーザーに変更する際は、キューが適切に設定されているか確認してください。

大量レコード変更時の制限

Salesforceにはガバナ制限があり、1回のトランザクションで更新できるレコード数やDMLステートメント数に上限があります。リストビューからの一括変更では最大200件まで、データローダーではバッチサイズを調整することで大量レコードを扱えますが、トリガやプロセスが起動する場合はタイムアウトに注意が必要です。

所有者変更の具体的な手順

ここでは、代表的な3つの方法について手順を説明します。

方法1:個別レコードの所有者を変更する

対象レコードが少数(数件程度)の場合は、1件ずつ手動で変更するのが確実です。

1. 退職者が所有するレコードの詳細ページを開きます。
2. 「所有者」フィールドの横にある編集アイコン(鉛筆マーク)をクリックします。
3. 検索ボックスに新しい所有者のユーザー名またはキュー名を入力し、候補から選択します。
4. 「保存」をクリックします。確認ダイアログが表示されたら内容を確認して「保存」します。
5. 変更後、レコードの所有者が更新されたことを確認します。

この方法は手間がかかりますが、変更履歴が個別に残るため監査に適しています。

方法2:リストビューから一括で所有者を変更する

数十件から200件程度のレコードをまとめて変更する場合に便利です。

1. 対象オブジェクトのリストビューを開き、表示フィルタで退職者が所有者のレコードを抽出します。
2. 一覧の左端のチェックボックスで、変更したいレコードをすべて選択します。
3. リストビュー上部の「編集」ボタンをクリックします。一括編集モードになります。
4. 「所有者」列に新しい所有者を入力するか、検索アイコンから選択します。すべての行に同じ所有者を設定する場合は、列ヘッダーの「すべてを同じ値に変更」を利用すると効率的です。
5. 「保存」をクリックします。変更内容の確認画面が表示されるので問題なければ「保存」します。

注意点として、リストビューで表示できるレコード数は最大200件のため、それ以上のレコードを変更する場合はデータローダーを使用します。

方法3:データローダーを使用して大量レコードの所有者を変更する

数百件以上のレコードを一括で変更する場合、Salesforceのデータローダー(Data Loader)を利用します。データローダーはデスクトップアプリケーションで、CSVファイルを使ってレコードを更新できます。

1. 事前準備: データローダーをインストールし、Salesforce組織のログイン情報を設定します。
2. エクスポート: まず退職者が所有するレコードのIDと現在の所有者IDをエクスポートします。データローダーの「エクスポート」機能を使い、SOQLで対象レコードを抽出します(例: SELECT Id, OwnerId FROM Account WHERE OwnerId = ‘退職者のユーザーID’)。CSVファイルを保存します。
3. CSV編集: エクスポートしたCSVのOwnerId列を、新しい所有者のユーザーID(またはキューID)に変更します。新しい所有者IDは事前にSalesforce上で確認しておきます。
4. 更新: データローダーの「更新」機能を選択し、編集済みのCSVファイルを指定してマッピングを確認し、実行します。
5. 結果確認: 実行ログで成功・エラー件数を確認し、実際のレコードが更新されたか検証します。

データローダーを使用する際は、バッチサイズ(デフォルト200)を調整することで大量データの処理が可能です。ただし、組織のAPI制限やガバナ制限に注意してください。

所有者変更時に発生しがちな失敗パターンと対処法

実際の業務でよく見られる失敗例とその対処法をまとめます。

失敗パターン	原因	対処法
所有者変更フィールドが表示されない	権限不足(転送権限がない)	システム管理者に権限セットまたはプロファイルの「転送」権限を付与してもらう
「所有者の変更が許可されていません」エラー	新しい所有者がアクティブでない、または共有設定で制限されている	新しい所有者がアクティブユーザーであることを確認。キューに変更する場合はキューが存在するか確認
一括変更で一部のレコードが更新されない	トリガやワークフローによるエラー、参照整合性違反	エラーログを確認し、対象レコードを個別に修正。関連するカスタムオブジェクトの所有者も同時変更が必要な場合がある
データローダー更新中にタイムアウト	大量トリガが起動してガバナ制限超過	バッチサイズを小さくする(例: 200→100)。または夜間など負荷の低い時間帯に実行

これらの失敗に遭遇した場合、まずエラーメッセージを記録し、Salesforceの設定画面で権限や共有ルールを再確認してください。特にカスタムオブジェクトの所有者変更は、親オブジェクトとの整合性が原因で失敗することが多いため、関連レコードも含めて一括更新することを検討します。

キューや共有ルールを活用した代替方法

退職者のレコードを引き継ぐ際、所有者を特定の個人に変更するのではなく、キュー(キュー)に割り当てる方法もあります。キューは複数のユーザーでレコードを共有でき、チームで対応する場合に便利です。キューを使用するには、事前にキューを作成し、メンバーを追加しておく必要があります。

また、共有ルールを使って、退職者のレコードを特定のユーザーやグループに自動的に共有することも可能です。ただし、この方法では所有権は移らないため、レコードの所有権自体を変更したい場合は不十分です。所有権を変更せずにアクセス権だけ付与したい場合に検討します。

キューと所有者変更の比較を以下に示します。

方法	対象規模	手間	注意点
個別変更(画面)	数件〜数十件	中	変更履歴が明確だが手作業が多い
リストビュー一括変更	200件まで	低	表示上限に注意。全件更新には不向き
データローダー	数千件〜数万件	高(準備が必要)	バッチサイズ調整、API制限、トリガ影響を考慮
Apexバッチ処理	大規模(数十万件)	非常に高(開発者が必要)	カスタム開発が必要。管理者以外は推奨しない

管理者が確認すべき設定

所有者変更を実施した後、または実施する前に、システム管理者は以下の点を確認します。

監査ログの確認

所有者変更の履歴は監査ログ(設定 > 監査ログ > 監査ログのダウンロード)で確認できます。また、個別レコードの変更履歴(フィールド履歴)も有効にしていると追跡可能です。退職者のレコード引き継ぎが適切に行われたことを証跡として残すために、監査ログを定期的にエクスポートしておきましょう。

権限セットとプロファイルの見直し

退職者のユーザーは速やかに非アクティブ化する必要がありますが、その前に所有レコードを引き継がないとレコードが孤児になります。また、退職者に付与されていた権限セットを新しい所有者に付与する必要があるか検討します。例えば、商談の所有者変更後も同じ価格表や承認プロセスを使い続けるなら、権限を移行します。

自動化プロセスの影響評価

ワークフロールール、プロセスビルダー、フロー、トリガなどが所有者変更をトリガーに起動する場合があります。新しい所有者にメールが送信されたり、関連レコードが更新されたりする可能性があるため、事前にシミュレーションすることをお勧めします。Sandbox組織でテストしてから本番に適用しましょう。

よくある質問

Q1. 退職者が削除済みユーザーの場合、所有者変更はできますか?
削除済みユーザーが所有者のレコードは、システム管理者であれば所有権を変更できます。ただし、削除済みユーザーはリストビューのフィルタで選択できないため、データローダーやSOQLで該当レコードを特定する必要があります。ユーザーを非アクティブ化(削除)する前に所有者変更を完了させることを推奨します。

Q2. 所有者変更を元に戻すことはできますか?
変更後、レコードの履歴が残るため、以前の所有者を確認することは可能ですが、単純に「元に戻す」機能はありません。誤った所有者に変更した場合は、再度正しい所有者に変更し直します。大量レコードの場合はデータローダーなどで再実行してください。

Q3. 複数のオブジェクトにまたがるレコードを一緒に所有者変更するには?
取引先とその子レコード(商談、ケースなど)の所有者を同時に変更したい場合、データローダーでオブジェクトごとにCSVを用意して更新するか、Apexバッチで一括処理します。ただし、親子関係で共有ルールが異なるため、整合性に注意してください。

Q4. キューを所有者に設定すると、レコードは誰が管理するのですか?
キューに割り当てられたレコードは、キューのメンバー全員が参照・編集できます。所有権はキューにあるため、個人で管理する必要がなく、チームでの対応に適しています。ただし、レポートの所有権や特定の機能で制約がある場合もあるため、運用ルールに合わせて使い分けてください。

まとめ

退職者の所有レコードを引き継ぐ際の所有者変更は、権限設定やレコード数に応じて適切な方法を選ぶことが重要です。少ないレコードなら画面からの個別変更やリストビュー一括変更で十分ですが、大量のレコードを扱う場合はデータローダーやキューへの割り当てを検討します。変更前には必ず権限や自動化プロセスの影響を確認し、Sandboxでテストしてから本番に適用することで、トラブルを未然に防げます。定期的に退職者レコードの棚卸しを行い、所有権の移行を計画的に進めるようにしましょう。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。