データローダーエラー対応まとめ
現場でよくある「データローダ権限まわりのエラー」+「対応方法の流れ」+「各エラーの原因と対策」 をまとめます。
この内容はあくまで勉強内容のアウトプットとなります。
- 「データローダの失敗 = 権限不足」がかなり多い
- 権限不足といっても「オブジェクト」「項目」「参照」「共有」とレイヤーがある
- 現場では「エラーを読み → ※どのレイヤーの問題か切り分け → 管理者に依頼」が基本
※レイヤーの問題切り分けについて
データ操作が失敗したときの原因は1つではなく、「権限」にはいくつかの層(レイヤー)があります。下記内容が切り分けの内容となります。
1,オブジェクトレベル → オブジェクト全体のCRED権限があるか
2,項目レベル → 特定の項目が「読み取り専用」になっていないか
3,レコードレベル → そのレコード(1件のデータ)にアクセス権があるか(所有者か?共有されているか?)
🔹 現場でよくあるエラーと対応の流れ
1. オブジェクトに対する権限不足
-
エラー例:
INSUFFICIENT_ACCESS: insufficient access rights on object id
- 原因:そのオブジェクトに「作成」「編集」「削除」権限がない
-
現場での対応手順
- 自分の プロファイル を確認(対象オブジェクトに対して「※CRED権限」があるか)
- 不足していれば、管理者に「○○オブジェクトに対する編集権限が必要です」と依頼
※ Create(作成),Read(参照),Edit(編集),Delete(削除)を総称でCRED権限
2. 項目に対する権限不足
- エラー例:更新したい項目だけ失敗する
- 原因:項目が「読み取り専用」になっている(項目レベルセキュリティ)
-
現場での対応手順
- [設定] → [プロファイル/権限セット] → 「項目レベルセキュリティ」で確認
- 更新が必要なら、管理者に「○○項目の編集権限をください」と依頼
- もし「システム的に読み取り専用(例:作成日、最終更新者)」なら更新不可 → 諦めるしかない
3. 関連オブジェクト参照権限不足
- エラー例:エクスポートで「親オブジェクトの項目」が取れない
- 原因:関連オブジェクトに「読み取り権限」がない
-
現場での対応手順
- どの参照項目で失敗しているかを確認
- 対象オブジェクトの参照権限を確認
- 「参照権限追加」を依頼
4. 共有設定(Sharing Rules)が原因
- エラー例:特定のレコードだけ更新できない
- 原因:オブジェクト権限はあるけど、そのレコードを「所有者でも共有対象でもない」ため操作不可
-
現場での対応手順
- そのレコードの「所有者」や「※公開範囲(OWD)」を確認
- 公開範囲が「非公開」の場合 → ロール階層や共有ルールを見直す必要がある
- 自分で対応できないので、管理者に「共有設定の確認依頼」を出す
※OWD
OWD(Organization-Wide Defaults) は、オブジェクトごとに「そのデータを誰まで見られるか・編集できるか」を決める設定です。
確認方法: [設定] → [共有設定] を開く
「組織のデフォルト」に各オブジェクトの公開範囲
(例:公開/親レコードに従う/非公開)が表示されます
例: 公開 → 全員が見れる
非公開 → 所有者と共有された人しか見れない
5. 検証ルール・トリガーで弾かれる
-
エラー例:
FIELD_CUSTOM_VALIDATION_EXCEPTION
やApex trigger failed
- 原因:検証ルールやトリガーの制御で保存できない
-
現場での対応手順
- エラーメッセージをよく読む(「必須項目不足」「条件未満」など出る)
- ルールに従ったデータに修正する
- どうしても一括で入れたい場合(過去データの移行や一時的な例外処理)は一時的に検証ルールやトリガーを無効化する → 管理者に依頼して対応
🔹 現場での「エラー対応の基本の型」まとめ
-
まずエラーメッセージを読む
→ 英語でも、insufficient access
,required field missing
,validation failed
などキーワードを拾う -
エラーの種類を分類する
・権限不足?(オブジェクト / 項目 / 参照 / レコード共有)
・データ不備?(必須項目・入力形式)
・システム制御?(検証ルール・トリガー) -
どこを確認するか決める
・権限系 → プロファイル・権限セット・共有設定
・データ系 → CSVや入力内容の見直し
・システム系 → 管理者や開発チームに確認 -
自分で直せない場合は依頼する
・「エラーメッセージ」と「操作内容」を具体的に伝えると現場では好印象
🔹 権限確認チェックリスト
✅ オブジェクトレベル
・対象オブジェクトにCRED権限があるか?
✅ 項目レベル
・更新したい項目に「編集」権限があるか?
✅ レコードレベル
・レコードの所有者は誰か?
・OWDの設定は「非公開」になっていないか?
✅ システムルール
・検証ルールに引っかかっていないか?
・トリガーで制御されていないか?
✅ その他
・CSVの項目名は正しいか?
・参照先データは存在するか?
🔹 Salesforceエラーメッセージ対応まとめ表
エラーメッセージ | 意味(ざっくり) | 確認場所 | 確認・対応手順 |
---|---|---|---|
INSUFFICIENT_ACCESS |
アクセス権不足 | プロファイル / 権限セット / 共有設定 | 1. [設定] → [ユーザー] で対象ユーザーを開く 2. プロファイルを確認 → 該当オブジェクトの CRED 権限があるかチェック 3. [権限セットの割り当て] で追加権限があるか確認 4. レコードにアクセスできない場合 → [共有ボタン] から共有範囲を確認 |
INVALID_FIELD |
項目名が間違っている or 権限なし | オブジェクトマネージャー / プロファイル / CSV | 1. オブジェクトマネージャーで対象オブジェクトを開き、項目API名がCSVのカラム名と一致しているか確認 2. [プロファイル] → [オブジェクト設定] で項目レベルセキュリティを確認(参照・編集権限があるか) |
REQUIRED_FIELD_MISSING |
必須項目が空欄 | オブジェクトマネージャー / CSV | 1. オブジェクトマネージャーで対象オブジェクトを開き、必須(必須チェック有)項目を確認 2. CSVに必須項目の値が入っているか確認 3. 必須条件がビジネス要件で不要なら → 管理者に依頼して「項目の必須チェック」または「ページレイアウト必須」設定を見直す |
FIELD_CUSTOM_VALIDATION_EXCEPTION |
検証ルール違反 | オブジェクトマネージャー / 検証ルール | 1. オブジェクトマネージャーで対象オブジェクトを開き → [検証ルール] を確認 2. どの条件に引っかかっているかエラーメッセージから判断 3. データ修正して再投入 or 管理者に依頼して一時的にルール無効化 |
INVALID_CROSS_REFERENCE_KEY |
関連オブジェクトが参照できない | オブジェクトマネージャー / CSV / 関連データ | 1. CSV内の参照項目(例:AccountId)が正しいIDか確認(IDが存在するか?) 2. [設定] → [オブジェクトマネージャー] で参照関係を確認 3. ユーザーに参照先オブジェクトへの「参照権限」があるか確認 |
STORAGE_LIMIT_EXCEEDED |
ストレージ容量超過 | 設定 → 記録管理 / ストレージ使用状況 | 1. [設定] → [記録管理] → [ストレージ使用状況] で使用率を確認 2. 古い不要データや一時データを削除できるか検討 3. 無理なら Salesforce サポートへ容量拡張を依頼 |
🔹 ポイントまとめ
- プロファイル / 権限セット → [設定] → [ユーザー] → 対象ユーザーを開いて確認
- オブジェクト設定 → [設定] → [オブジェクトマネージャー] → 対象オブジェクト
- レコード共有状況 → レコードを開いて「共有」ボタンから確認(UIにより表示場所は違う)
- ストレージ → [設定] → [記録管理] → [ストレージ使用状況]
各エラーの原因と対策
💪 データローダ・デバッグ筋トレ
Q1 エラー:ORA-00933: SQL command not properly ended
シチュエーション:
抽出条件で以下のようなSQLを設定してジョブを実行したところ、エラー発生。
SELECT * FROM employees WHERE department_id = 10;
解説:
データローダやETLツール上でSQLを記述する際、末尾のセミコロン「;」は不要です。
セミコロンはSQL*PlusやSQL Developerなどで複数ステートメントを区切るための記号であり、ETLツールでは文としてそのまま送られるため、セミコロンがあると不正なSQLとみなされます。
Q2 エラー:ORA-00904: "EMP_NAME": invalid identifier
シチュエーション:
データローダで employees
テーブルから EMP_NAME
を指定してデータを抽出しようとしたところ、上記エラーが発生しました。
解説:
ORA-00904 は、指定したカラム名や関数名が存在しない、もしくはスペルミスなどで無効なときに発生します。
・カラム名の誤字(例:EMP_NAME ではなく EMP_NAME_C)
・カラム名の大小文字が一致していない(ダブルクォーテーションで囲まれていた場合)
・カラムがそもそも存在しない(定義されていない)
Q3 エラー:ORA-01722: invalid number
シチュエーション:
salary
カラム(数値型)に対して、WHERE salary = 'abc'
という条件を指定してジョブを実行しました。
解説:
ORA-01722: invalid number は、数値型のカラムに対して文字列など数値でない値を渡したときに発生します。
Q4 エラー:Data length mismatch
シチュエーション:
データローダで CSV
形式のファイルを読み込んで Oracle テーブルにロードする処理を実行したところ、データ長の不一致
というエラーが発生しました。
解説:
「Data length mismatch」は、以下のようなケースでよく発生します。
・CSVの列数と、インポート対象のテーブルカラム数が一致していない
・データ型と実データの不一致(例:文字列型に数値型の長さで入れてる)
・ファイルの区切り文字が意図通りに扱われていない(例:カンマ区切りだと思ってたらタブ区切り)
Q5 エラー:ORA-00001: unique constraint (SCHEMA.PK_EMPLOYEES) violated
シチュエーション:
employees
テーブルに対してデータをインサートする処理を実行したところ、主キー制約違反のエラーが発生しました。
解説:
このエラーは、既に同じ主キー値のレコードが存在するのに、もう一度その主キーで挿入しようとしたときに発生します。
・挿入データに重複がある
・主キーの自動採番がうまく動いていない(手動指定になっている)
・ロード元データに主キー重複があるのにチェックしていない
Q6 エラー:INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY
シチュエーション:
取引先責任者(Contact)のデータをデータローダで一括登録しようとしたところ、一部レコードでこのエラーが発生。外部ID経由で取引先(Account)を紐づけている。
解説:
このエラーは、「参照先のオブジェクト(Account)に対するアクセス権限が不足している」場合に発生します。
外部IDでAccountが見つかっても、そのAccountレコードを参照する権限がなければエラーになります。
主な確認ポイント:
- OWD(組織全体の共有設定)が「非公開」になっていないか
・🔍設定 → セキュリティ → 共有設定 → Accountの公開設定を確認 - 実行ユーザーが対象Accountレコードを参照できるか
・🔍そのユーザーでログインし、対象Accountを画面から検索できるか確認 - 共有ルールやロール階層でアクセスできるようになっているか
・🔍設定 → 共有ルールやユーザーのロール設定を確認
Q7 エラー:FIELD_CUSTOM_VALIDATION_EXCEPTION: 郵便番号を都道府県に合わせて入力してください
シチュエーション:
商談データをデータローダで一括登録しようとしたところ、数件のレコードでこのエラーが発生。
解説:
このエラーは、Salesforceのバリデーションルール(数式によるデータチェック)に違反したことを意味します。
この場合、郵便番号と都道府県の組み合わせが、ルール上正しくないと判断されています。
主な確認ポイント:
- バリデーションルールのロジック内容
・🔍設定 → オブジェクトマネージャ → 商談 → バリデーションルールを確認
・該当ルールで「郵便番号」「都道府県」が含まれているか - エラーになったレコードのデータ内容
・🔍CSVファイルで該当レコードを確認し、郵便番号・都道府県の組み合わせが妥当か照らし合わせる - 必要に応じてルールの一時的な無効化(要検討)
・🔍バリデーションルールを一時的に非アクティブ化して再試行(テスト環境推奨)
Q8 エラー:INVALID_FIELD: Foreign key external ID: 12345 not found for Contact
シチュエーション:
ケース(Case)をデータローダでインポートした際、外部IDを使って取引先責任者(Contact)と紐づけようとしたが失敗。
解説:
指定した外部IDの値に一致するContactレコードが存在しないため、関連付けができずエラーになったという意味です。
主な確認ポイント:
-
指定した外部ID項目に一致するデータがContactに存在するか
・🔍データローダやSOQLで該当外部ID(例:会員番号__c = 12345)を検索SELECT Id FROM Contact WHERE 会員番号__c = '12345'
-
使用している項目が「外部ID」として正しく設定されているか
・🔍オブジェクトマネージャ → Contact → 項目 → 該当項目を開き、[外部ID]と[一意]のチェックがONか確認 -
外部IDがNULLや重複していないか(外部IDは一意(重複していないもの)である必要あり)
・🔍重複レポートやSOQLで確認
外部ID設定
・オブジェクトマネージャ → 項目とリレーション → 外部IDとして使うカスタム項目を開く
・「外部IDにする」チェックON
・「一意にする」チェックON
Q9 エラー:なし(成功と表示されるが、関連付けがされていない)
シチュエーション:
商談明細(OpportunityLineItem)をデータローダで登録したが、Product2(商品)との関連がされていなかった。
解説:
Salesforceでは、指定した外部IDに一致する商品(Product2レコード)が見つからなければ、空欄のまま登録されてもエラーは出ない仕様です。
主な確認ポイント:
-
Product2オブジェクトに、指定した外部ID項目が正しく設定されているか
・🔍オブジェクトマネージャ → Product2 → 該当項目 → 「外部ID」「一意」属性がONか -
データローダでのマッピングが正しいか
・🔍PricebookEntry:Product2.商品コード__c などの外部ID指定形式になっているか -
外部ID値に一致するProduct2が登録されているか
・🔍SOQLで該当する値が存在するか確認SELECT Id FROM Product2 WHERE 商品コード__c = 'ABC123'
Q10 エラー:CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY、トリガーで例外が発生しました: List has no rows for assignment to SObject
シチュエーション:
リード(Lead)をデータローダで登録した際に一部レコードでエラーが発生。リード登録時にApexトリガーが動く仕様。
解説:
Apexコード内で List
から SObject
に直接代入しようとした際、レコードが1件も取得できなかったためにエラーが発生しています。
これは SELECT ~ INTO SObject
構文を使っていて、0件のときに例外が投げられるパターンです。
主な確認ポイント:
- トリガーでどんなSOQLが書かれているか確認する
・🔍開発者コンソール or VSCode でトリガーを開き、[SELECT ...]
の条件を確認 - 該当レコードのデータで、そのSELECT条件を満たすレコードが存在するか
・🔍SELECT条件とレコード内容を突き合わせ、存在しないケースを再現 - コードが「レコード0件でも落ちないようになっているか」確認
・🔍List<Account> accs = [SELECT Id FROM Account WHERE Name = :lead.Company];
のように修正すべき
Q11 エラー:Too many batch retries
シチュエーション:
リードを大量にUpsertした際、途中でこのエラーが発生。特定レコードの処理で繰り返し失敗した。
解説:
データローダのバッチ処理中に、同一レコードで複数回失敗すると、このエラーになります。処理対象レコードに起因するトリガーやワークフローの例外が主な原因です。
主な確認ポイント:
- エラーが出ているレコードのみに限定して再実行してみる
・🔍 データローダの「エラーファイル」から対象レコード抽出して個別検証 - 対象レコードに関連するトリガー/フローの内容確認
・🔍 オブジェクトマネージャ → 該当オブジェクト → トリガー・フローを開いて確認 - バッチサイズを小さくして再試行
・🔍 データローダ設定 → バッチサイズを1に設定して1件ずつ処理し原因を特定
Q12 エラー:System.LimitException: Too many SOQL queries: 101
シチュエーション:
Accountデータのバルク登録時、Apexトリガーが動作して、SOQL制限を超えてしまった。
解説:
1つのトランザクションで101回以上のSOQLクエリを実行すると、このリミット例外が発生します。典型的には「ループ内でSOQLを実行」するコード構造が原因です。
主な確認ポイント:
- トリガー内のSOQL実行箇所の確認(ループ内にないか)
・🔍 開発者コンソール → Apex トリガー →for
ループ +SELECT
の有無を確認 - ハンドラクラスの構造(SOQLをまとめて使うように)
・🔍 SOQLを事前にMapで取得してループ内で参照する形に変更 - デバッグログで実行されたSOQL数をチェック
・🔍 設定 → デバッグログ → 「クエリ数」セクションで回数を確認
Q13 エラー:INVALID_FIELD_FOR_INSERT_UPDATE
シチュエーション:
子オブジェクトのUpsert時、マッピングで親オブジェクトの項目を更新しようとして失敗。
解説:
Upsertの対象に「更新できないフィールド(例:親レコードのフィールド)」が含まれている場合に発生します。参照関係の構成ミスによるものです。
主な確認ポイント:
- マッピングファイルに親の項目(例:Account.Name)が含まれていないか
・🔍 データローダでマッピング画面を確認 - 子オブジェクトに紐づく外部IDでの参照設定が正しいか
・🔍 「Account:外部ID名__c」など、正しいリレーションキーを使っているか確認 - 親オブジェクトの更新は別プロセスに分ける設計へ
・🔍 親と子を分けて登録処理を実行
📌参照関係の構成ミスの例は以下のようなケースです:
- データローダで親オブジェクトの項目(例:Account.Name)を直接更新しようとしている(子オブジェクトのUpsert時)
- 子オブジェクト側で参照している親レコードが存在しない
- マッピングで 親オブジェクトの「非編集項目」 を指定してしまっている
つまり「子の更新処理の中で、親に手を出そうとしている」ことが構成ミスです。
Q14 エラーなし/レコードが重複登録された
シチュエーション:
Contactを外部IDでUpsertしたが、同一レコードが重複して登録された。
解説:
外部ID項目が「一意(ユニーク)」設定されていない、または値が空だった場合に、UpsertはInsertとして動作してしまいます。
主な確認ポイント:
- 外部ID項目が「一意」「外部ID」になっているか
・🔍 オブジェクトマネージャ → Contact → 該当項目 → 「外部ID」「一意にする」がONか確認 - CSV内の外部IDに空白・重複がないか
・🔍 ExcelやSOQLでNULL
や重複
をチェック - 正常にUpsertできているか、対象レコードの履歴確認
・🔍 データローダの成功ファイルでIDが返されているか確認
Q15 エラー:ERROR_PROCESSING_RECORD
シチュエーション:
「処理に失敗しました」としか表示されず、詳細が不明なケース。
解説:
データローダの出力にエラー詳細が出ない場合、内部でApex例外やバリデーションエラーが発生している可能性が高いです。
主な確認ポイント:
- デバッグログを有効にして、詳細エラーを確認
・🔍 設定 → デバッグログ → 該当ユーザーにログを付与 - Apexトリガー・バリデーションルールを確認
・🔍 オブジェクトマネージャ → 該当オブジェクト → バリデーションルール一覧 - 該当レコードで
addError()
が使用されていないか確認
・🔍 Apexコード内のaddError()
の出力内容を確認
Q16 エラー:INDEX_OUT_OF_BOUNDS
シチュエーション:
CSVファイルを読み込んだ際に、想定外の列数やマッピングミスによってエラーが発生。
解説:
「INDEX_OUT_OF_BOUNDS」は、データローダがCSVの列に対応する値を探す際に、存在しない列(配列の外)を参照しようとして起こるエラーです。
主な確認ポイント:
-
CSVファイルの各行の列数がヘッダーと一致しているか
・🔍 ExcelやGoogleスプレッドシートでCSVを開いて、空白セルがある行を確認
・🔍 行によって列数が異なる場合、データクレンジングが必要 -
区切り文字の誤り(カンマ、タブなど)がないか
・🔍 テキストエディタ(例:Notepad++)で開き、区切り文字が正しいかチェック -
マッピングファイル(.sdl)に対応するフィールドが存在するか
・🔍 データローダのマッピング画面で「未対応」や「不明な項目」がないか確認
このエラーの原因はほぼCSV側の問題です(列数がバラバラ、空行が混ざってる、区切り文字が不正など)
📌マッピングファイルについて
.sdl は Salesforceの項目名とCSVの列名を結びつけるマッピングファイルです。
例えば以下のような内容
Name=Name
Email=Email__c
Phone=Phone__c
マッピング設定画面でこのファイルを使って設定する。これにより、データローダがどのCSV列をSalesforceのどの項目にマッピングすべきかを理解します。
⚠️ もしSalesforce上に Email__c が存在しなければエラーになります。
Q17 エラー:MIXED_DML_OPERATION
シチュエーション:
ユーザ情報とリード情報を同一トランザクションでInsert/Updateしようとしたところ、エラーになった。
解説:
標準オブジェクト(User、Groupなど)と、カスタムオブジェクト(取引先、リードなど)を同一処理内で更新しようとすると、Salesforceのガバナールールによりこのエラーが発生します。
主な確認ポイント:
-
トリガーやプロセスビルダーでUser更新を同時に行っていないか
・🔍 トリガーコードやフローでUserオブジェクトが関与していないか確認 -
処理の分離(非同期処理)を設計しているか
・🔍@future
メソッド、Queueable Apexで別トランザクションとして実行する設計に変更 -
単一トランザクションにまとめてしまっていないか
・🔍 Salesforceの混在DMLルールを参照して設計を見直す
📌同一トランザクションでの処理について
Salesforceでは1回の処理(=トランザクション)内で「User」と「Lead」など異なる種別のオブジェクトを同時に更新しようとするとエラーになります。
データローダでは基本的に「1つのオブジェクトに対する処理」を1回ずつ実行します。なので同時にUserとLeadを更新する、などはデータローダ単体では発生しません。
Mixed DMLが発生する時の例:
Leadのinsert時(データローダ)
CSVを使ってLeadを登録
↓
トリガーで「関連するUserを更新する」処理が自動的に動く
↓
1回の処理の中でLeadとUserを更新 → Mixed DMLエラー
DML制約により、「標準オブジェクト(User)とカスタムオブジェクト(Lead)」を同じトランザクションで更新できない
対処法:
・User などの標準オブジェクト更新処理を 非同期(@future や Queueable)にする
・処理を分ける(インポート手順を2回に分ける)
・トリガーでUserを更新しないよう制御する(条件付きで処理)
Q18 エラー:処理中にタイムアウト・中断が発生
シチュエーション:
大量レコード(10万件以上)を一括インポート中、処理が途中で停止したり、エラーなしに完了しなかった。
解説:
APIタイムアウト、バッチサイズが大きすぎる、ネットワーク不安定などが原因で発生します。Salesforce側の処理制限を超えている可能性もあり。
主な確認ポイント:
-
バッチサイズが大きすぎないか(100〜200が推奨)
・🔍 データローダ設定 → バッチサイズを50や100に減らして再実行 -
ネットワークやVPNの影響を受けていないか
・🔍 スピードテストやVPN切断で環境を変えて試す -
トリガーやフローが大量の処理をしていないか(処理遅延)
・🔍 デバッグログで処理時間を確認 → 長時間かかっている処理を特定 -
並列実行設定が競合していないか
・🔍 「並列実行しない(Serialモード)」に切り替えて処理
Q19 エラー:UNABLE_TO_LOCK_ROW
シチュエーション:
複数のデータロード処理が同じレコードを更新しようとした際に発生。
解説:
対象レコードが他のトランザクションでロック中だったため、更新できなかったことを意味します。並列実行や他ユーザー処理との競合が原因。
主な確認ポイント:
-
並列処理をしていないか(Parallelモード)
・🔍 データローダ設定 → 「シリアルモード」で再実行(チェックボックスをON) -
他のバッチ処理やワークフローで対象レコードが使われていないか
・🔍 開発者コンソールでロック競合対象のオブジェクトをSOQLで確認 -
更新対象レコードの分割戦略が必要か
・🔍 対象を複数グループに分割して順番に処理
📌Parallelモードについて
データローダがレコードを「複数スレッドで同時並列に処理」する設定です(デフォルトはON)
- メリット:速い
- デメリット:同じレコードを複数バッチが同時に触ると「ロックエラー」になる
Parallelモード設定手順:
データローダを起動
メニュー:[設定] > [設定]
チェックボックス:✅ 「Bulk APIの並列処理を使用する」(これがONだとParallelモード)
チェックを外すと、Serialモード(1バッチずつ処理)になります。
Q20 エラー:INVALID_SESSION_ID
/ INVALID_CLIENT
シチュエーション:
データローダで定期処理を行っていたが、ある日突然ログインできなくなり、このエラーが発生。
解説:
セッションIDの有効期限切れ、OAuth認証情報の破損、接続アプリ設定ミスなどが原因。特にCLIでの認証情報キャッシュ破損が多い。
主な確認ポイント:
-
データローダのログインを再実行してみる
・🔍 GUI版なら手動でログインし直し、CLIなら認証情報(sfdx auth:login
)を再取得 -
Connected Appの設定が変更されていないか(OAuth認証)
・🔍 設定 → アプリケーション → 接続アプリケーション → 対象のOAuth設定を確認(コールバックURL、スコープ) -
秘密鍵やトークンファイルが破損していないか
・🔍 CLIでは.sfdx
フォルダを削除 → 再認証
📌OAuth認証情報
OAuth認証情報とはSalesforceに安全にログインするための仕組みです。
「ユーザー名+パスワード」ではなく、「アクセストークン」を使ってログインします。
このような設定一式の事をOAuth認証と言います。
Salesforce 権限・共有設定の構成要素と確認場所まとめ
項目 | 説明 | Salesforce上での確認場所・手順 |
---|---|---|
① プロファイル | オブジェクト単位の「作成・編集・削除」などの操作権限 | 🔹設定 → ユーザー → プロファイル 🔸対象ユーザーのプロファイルをクリック 🔸「オブジェクト設定」セクションで対象オブジェクトを選択 → 作成・編集・削除・参照などのチェック有無を確認 |
② OWD(組織全体の共有設定) | オブジェクトのレコード単位のデフォルトの公開レベル(公開/非公開) | 🔹設定 → セキュリティ → 共有設定 🔸「組織全体のデフォルト」セクションで、各オブジェクトの公開レベルを確認 (例:取引先 → 非公開 / 公開) |
③ 共有ルール | ②で「非公開」にしても、特定ユーザーにレコードを共有できる設定 | 🔹設定 → セキュリティ → 共有設定 🔸ページ下部の「[オブジェクト名]の共有ルール」セクションで確認 🔸共有先(ユーザー・ロール・グループ)と共有レベル(閲覧のみ/編集など)を確認 |
④ ロール階層 | 上位ロールのユーザーは、下位ロールのユーザーのレコードを閲覧できる(階層構造) | 🔹設定 → ユーザー → ロール → ロールの管理 🔸組織のロール階層をツリー形式で確認 🔸「このロールのユーザーが所属するレコードは上位ロールに見える」かどうかを把握できる |
補足:設定画面のナビゲーションのヒント
探したいもの | 検索窓に入力すべきキーワード(設定画面上) |
---|---|
プロファイル |
プロファイル または Profiles
|
共有設定(OWD & 共有ルール) |
共有 または Sharing Settings
|
ロール階層 |
ロール または Roles
|