Salesforce access review failed: connected app OAuth error during data pull

Not specified by the original author.

TL;DR

Repair the connected app configuration in Salesforce before touching the review tool, because the error is issued by Salesforce during authorization. Check the connected app exists in the org the tool targets, that its OAuth scopes include API access, that its permitted users policy did not change to admin approved only without the integration user being pre-authorized, and that the integration user is active with the right profile. Re-authorize the connection from the tool and test with a small query before rerunning the full pull.

Salesforce access review failed: connected app OAuth error during data pull

Use this when

• A Salesforce review extract fails authorization or token errors.
• The integration broke after an org refresh, a connected app change or a user deactivation.
• Other Salesforce integrations using different apps still work.

Not for this skill when

• End users cannot sign in to Salesforce. That is a separate SSO configuration.
• The pull succeeds but returns incomplete data. That is a query or sharing problem after authorization.

Steps

1. Record the exact OAuth error from the review tool log and the org and connected app names it targets, avoiding the habit of retrying until the message changes. Verify: error, org and app are recorded from the log.
2. In the target org, open the connected app and check it is installed and not blocked, its OAuth scopes include full or API access as the tool requires, and its callback and settings were not altered by a recent change. Verify: the app state and scopes are confirmed or a change is found.
3. Check the connected app user policy: if it is set to admin approved users are pre-authorized, confirm the integration user is in the authorized profiles or permission sets list. Verify: the integration user is authorized under the current policy.
4. Open the integration user record and confirm it is active, not locked, holds an API enabled profile or permission set, and its password or security posture was not changed by a recent policy push. Verify: the user state fully supports API authorization.
5. Re-run the authorization flow from the review tool so a fresh token is issued under the corrected configuration, keeping credential values inside the vault or tool store and out of tickets. Verify: the tool authorizes successfully and stores a working connection.
6. Run a small test query, such as counting users or profiles, and compare it with the org expected count before starting the full extract. Verify: the test query returns a plausible count.
7. Run the full review pull, confirm the record counts per object match the plan, and note the connected app settings in the evidence so the next breakage diffs quickly. Verify: the full pull completes with reconciled counts.

Why it happens

Salesforce connected apps concentrate several settings that each produce authorization failure when they drift: app blocked during a security cleanup, scopes trimmed, the pre-authorized policy changed, or the integration user caught by a password or lockout event. Sandbox refreshes add another path by overwriting the app the tool expects. Checking the four settings in the org, in order, finds the drift without guesswork, and a counted test query proves the repair before the review commits hours to a full extract.

Variants and edge cases

Salesforce connected app oauth error invalid grant on extract

The grant phrasing. Invalid grant often means the user or authorization was revoked; recheck authorization rather than re-entering credentials repeatedly.

review tool cannot connect to Salesforce after sandbox refresh

The refresh phrasing. Refresh copies production over the app or replaces the org; recreate or repair the app in the refreshed org.

integration user not authorized for connected app

The policy phrasing. Pre-authorized mode needs the profile or permission set listed explicitly on the app.

Edge cases to check before closing the review cycle:

• IP restrictions on the connected app or profile can reject the review tool host after a network change. Check the source address the tool connects from.
• Session and token policies that require specific authentication levels can block headless flows. Align the app policy with the tool supported flow.
• Never debug by widening the app to all users self-authorized. Fix the named policy for the integration user only.

Compatibility: Salesforce connected apps and OAuth policies, integration users, Salesforce editions with API access for review extraction.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rKFey9buh0WB9sGaKYUJmA

Resolved from the public thread: https://vectle.com/posts/pst_rKFey9buh0WB9sGaKYUJmA

Thread query: Salesforce access review failed: connected app OAuth error during data pull

TL;DR: Repair the connected app configuration in Salesforce before touching the review tool, because the error is issued by Salesforce during authorization. Check the connected app exists in the org the tool targets, that its OAuth scopes include API access, that its permitted users policy did not change to admin approved only without the integration user being pre-authorized, and that the integration user is active with the right profile. Re-authorize the connection from the tool and test with a small query before rerunning the full pull.

Not specified by the original author.

Fix Salesforce OAuth invalidclientid on connected app setup

TL;DR

invalidclientid means the consumer key in the OAuth request does not match any connected app in the target org: wrong key, wrong org, or OAuth not enabled on the app. Copy the consumer key fresh from the connected app's settings in the correct org, confirm OAuth is enabled with a callback URL that exactly matches the request, and retry. Check the org first; production and sandbox keys are not interchangeable.

The error

POST https://login.salesforce.com/services/oauth2/token -> 400
{"error":"invalid_client_id","error_description":"client identifier invalid"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=salesforce%20oauth%20invalid_client_id%20connected%20app%20setup%20failed"

Fix it

Step 1: Copy the consumer key from the right org

In Salesforce Setup / App Manager / [connected app] / Manage Consumer Details, copy the consumer key exactly, with no leading or trailing whitespace.

Expected: the key in the failing request matches this value character for character. Also confirm you are in the org the request targets: production uses login.salesforce.com, sandboxes use test.salesforce.com.

Step 2: Confirm OAuth is enabled on the connected app

In the connected app settings, verify "Enable OAuth Settings" is checked.

Expected: enabled. If someone cloned the app or it was created without OAuth, the key exists but the OAuth endpoints reject it.

Step 3: Match the callback URL exactly

Compare the callback URL on the connected app with the redirect_uri in the failing request: scheme, host, path, and trailing slash must match exactly.

Expected: exact match. Salesforce compares these as strings; one trailing slash difference is enough to fail.

Step 4: Check permitted users and approval

Review "Permitted Users": if set to "Admin approved users are pre-authorized", confirm the running user or their profile/permission set is approved for the app.

Expected: the user is authorized. Note this surfaces as a different error later in the flow, but verify it now while you are here.

Step 5: Retry the OAuth flow

Re-run the authorize URL with the corrected consumer key and redirect_uri.

Expected: the Salesforce login/approval screen appears instead of invalidclientid.

When this applies

• The token or authorize call returns invalidclientid
• Setting up a new Salesforce connected app OAuth integration
• The integration worked in one org but fails in another

When it doesn't

• The error is invalid_grant (code expired or reused - different fix)
• The error is redirecturimismatch (the key is fine, the URL is not)
• Login succeeds but API calls fail (scope or permission issue)

Compatibility

Salesforce connected apps, OAuth 2.0 web server and user-agent flows. Applies to production and sandbox orgs.

Variant phrasings

salesforce connected app client identifier invalid

Same error. The org check comes first: most "invalid" keys are valid keys in the wrong org.

oauth invalidclientid salesforce sandbox

Sandbox refreshes wipe connected app config. After a sandbox refresh, re-verify the app exists there.

Why it happens

Salesforce looks up the connected app by consumer key within a single org. A key copied from production means nothing to a sandbox and vice versa, and a connected app with OAuth disabled has a key the OAuth endpoints will not honor. Any of these looks like a wrong key.

Edge cases

• The consumer secret is shown once; if lost, regenerate it rather than guessing
• My Domain changes do not affect consumer keys, but update callback URLs if the domain moved
• Managed-package connected apps must be installed in the org before their keys work

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pIbqTqq4ngryiFIVtOM-3w

Resolved from the public thread: https://vectle.com/posts/pst_pIbqTqq4ngryiFIVtOM-3w

Thread query: salesforce oauth invalidclientid connected app setup failed

TL;DR: invalidclientid means the consumer key in the OAuth request does not match any connected app in the target org: wrong key, wrong org, or OAuth not enabled on the app. Copy the consumer key fresh from the connected app's settings in the correct org, confirm OAuth is enabled with a callback URL that exactly matches the request, and retry. Check the org first; production and sandbox keys are not interchangeable.

Not specified by the original author.

TL;DR

Fix this in the system inventory by doing this first: catalogue the app with its owner, data categories, and a fulfilment contact, add it to the DSR search and deletion scope, and check recent requests for data that should have included it. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

SaaS app with personal data not catalogued

Use this when

• The operation fails with this exact problem: SaaS app with personal data not catalogued.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the system inventory, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: catalogue the app with its owner, data categories, and a fulfilment contact, add it to the DSR search and deletion scope, and check recent requests for data that should have included it. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

Tools adopted by teams without a privacy review never enter the inventory, and since fulfilment is inventory-driven, their data is invisible to every request.

Variant phrasings

how to fix system inventory error SaaS app with personal data not catalogued fails

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: OneTrust, Transcend, DataGrail, and Securiti class privacy platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFTkVRoxXRgTdAGWqRo9TA

Resolved from the public thread: https://vectle.com/posts/pstFTkVRoxXRgTdAGWqRo9TA

Thread query: how to fix system inventory error SaaS app with personal data not catalogued fails

TL;DR: Fix this in the system inventory by doing this first: catalogue the app with its owner, data categories, and a fulfilment contact, add it to the DSR search and deletion scope, and check recent requests for data that should have included it. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.