Okta to Salesforce provisioning push failed profile update failed because th

Not specified by the original author.

TL;DR

Force a profile push or reactivate the target app account to match Okta: the target app user is deactivated while Okta shows active, so reactivate in the target (or correct Okta's status if the deactivation was deliberate) and clear the skipped push, because lifecycle sync will keep skipping while the states disagree. Prove it on one failing hire before rolling it to the rest of hires in the same sync or flow, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Okta lifecycle state sync failed "user is deactivated in target app but active in Okta, profile push skipped"

Use this when

• You see this exact error or symptom: Okta lifecycle state sync failed "user is deactivated in target app but active in Okta, profile push skipped".
• The failure is in the provisioning path named in the title (HR source, identity provider, and target app), and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one failing hire first and capture the evidence before changing anything: check the provisioning log entry for the one failing user in the identity provider (Okta system log, Entra provisioning logs, or the target app's SCIM log), and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Force a profile push or reactivate the target app account to match Okta: the target app user is deactivated while Okta shows active, so reactivate in the target (or correct Okta's status if the deactivation was deliberate) and clear the skipped push, because lifecycle sync will keep skipping while the states disagree. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Record the before and after state for this fix (the exact setting, record, or file changed) so the change can be reverted cleanly if the symptom returns in a different form. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun provisioning for that single user (on-demand provisioning or a sync cycle) and confirm the target account exists with the right attributes and status. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of hires in the same sync or flow in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

user is deactivated in target app but active in Okta, profile push skipped fix

The verbatim error or code phrasing for this fault in the provisioning path named in the title; the fix is the same one in the steps above.

Okta lifecycle state sync failed "user is deactivated in target app but

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix Okta lifecycle state sync failed "user is deactivated in

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Okta, Microsoft Entra ID, Google Workspace, AWS IAM Identity Center, SCIM 2.0 targets and Terraform providers as named in the title.

Why it happens

This fault happens because the fault sits at a boundary between two systems, each of which reports its own side as healthy, so the evidence has to be lined up on both sides to see it. In this case the condition is the one named in the title, in the provisioning path named in the title (HR source, identity provider, and target app): the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

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

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

Thread query: Okta lifecycle state sync failed "user is deactivated in target app but active in Okta, profile push skipped"

TL;DR: Force a profile push or reactivate the target app account to match Okta: the target app user is deactivated while Okta shows active, so reactivate in the target (or correct Okta's status if the deactivation was deliberate) and clear the skipped push, because lifecycle sync will keep skipping while the states disagree. Prove it on one failing hire before rolling it to the rest of hires in the same sync or flow, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

Link the hire to the existing application account instead of forcing a second create. In Okta, open the application assignment for the affected user, use Import or the provisioning log to find the matching app profile, confirm the username and email match the Okta universal profile, then choose Link or Match and re-run provisioning. Only delete the orphan app account when it is a confirmed stray with no sessions, data, or license history.

user already exists in application

Use this when

• An Okta provisioning task fails for one user while other hires provision cleanly.
• The target app already holds an account with the same username or email as the new hire.
• The System Log shows a create failure and the app assignment stays in an error state.

Not for this skill when

• The user cannot sign in to Okta at all. Fix authentication first, then return to provisioning.
• The failure affects every assignee at once. Check the app provisioning credentials and API connection instead.

Steps

1. Open Okta Admin Console, go to Applications, open the target app, and check Assignments and the Provisioning tab error list for the affected hire. Note the exact username the push tried to use and the timestamp of the failure so you compare the right records later. Verify: the error entry names the same user and app shown in the query
2. Search the target application directory or its admin console for that username and email, including deactivated and suspended accounts, because Okta treats a dormant account as an existing account. Record its app user id and status before changing anything. Verify: you find exactly one pre-existing account or confirm none exists outside Okta search results
3. In Okta, open Directory, People, open the hire profile, and compare login, email, first name, and last name with the app profile field by field. Fix any case, suffix, or domain difference in the authoritative source, usually the HR feed or Okta profile mapping, rather than editing only one side. Verify: all four fields match character for character after the correction
4. Return to the app Provisioning settings and run Import if the integration supports it, then match the imported app user to the Okta user and select the link option instead of create. If Import is unavailable, unassign the user, save, reassign, and pick the existing profile when prompted. Verify: the assignment changes from error to active without a new create call
5. Re-run provisioning for that single user from the app Tasks view and watch the System Log for a successful update event rather than another create attempt. Check the target app to confirm profile attributes updated and no second account appeared. Verify: the log shows an update success and the app still holds exactly one account for the hire
6. Document the match rule you used, for example email as the match key, in the provisioning runbook so the next rehire or contractor conversion links automatically. If duplicates keep appearing, tighten the profile mapping so the match attribute is required and unique. Verify: a test assignment for a known existing user links instead of erroring

Why it happens

Okta provisioning defaults to creating a new app account when no link exists between the Okta user and the app profile. Rehires, pre-provisioned vendor accounts, manual admin creates, and earlier partial runs all leave an account in the target app before Okta pushes. Because the create uses a username or email the app already holds, the app rejects it as a duplicate. Linking establishes the persistent identifier pair Okta needs, so later pushes become updates. The fix is therefore identity matching, not retrying the create, which will fail identically on every cycle until the link exists.

Variants and edge cases

Okta user already exists in application for rehires

Rehires are the classic case because the old app account was suspended rather than deleted. Reactivate and link that account so group memberships, historical records, and audit trails stay attached to one identity instead of splitting across two accounts.

Username matches but email differs

When the login matches and the email does not, trust the HR source of truth and update the stale app email before linking. Linking on a mismatched email creates password reset and notification problems that surface weeks later as apparent sign-in failures.

No account found in the app yet Okta still errors

Check for a soft-deleted or archived account in the target app, including recycle or trash views, and check a second tenant or sandbox that shares the same provisioning connection. Restore or fully purge the hidden record, then link or create once.

Compatibility: Applies to Okta Classic and Identity Engine orgs using app provisioning with Create and Update enabled, including Salesforce, Microsoft 365, and custom SCIM apps. Requires an Okta admin role with application assignment rights.

Provenance

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

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

Thread query: Okta provisioning failed with error "user already exists in application" how to fix

TL;DR: Link the hire to the existing application account instead of forcing a second create. In Okta, open the application assignment for the affected user, use Import or the provisioning log to find the matching app profile, confirm the username and email match the Okta universal profile, then choose Link or Match and re-run provisioning. Only delete the orphan app account when it is a confirmed stray with no sessions, data, or license history.

Not specified by the original author.

TL;DR

Enable provisioning on the app with the right capabilities and credentials, then assign again. Open the app integration settings, turn on provisioning with the create and update options the onboarding design expects, connect the app API credentials, run the test, map the required attributes, and only then re-run the group assignment that failed.

Okta app assignment failed for group: provisioning feature not enabled

Use this when

• Assigning a group to an Okta app fails or succeeds without creating accounts, with an error naming provisioning.
• The app was added for SSO only and onboarding now expects account creation.
• The app Provisioning tab is missing or shows provisioning as off.

Not for this skill when

• The business wants SSO-only access with manual accounts. Document that model instead of enabling provisioning.
• Provisioning is on but pushes fail on credentials. Repair the API connection instead.

Steps

1. Open the Okta app Assignments and Provisioning tabs plus the System Log assignment event for the affected hire and capture the full error detail, the operation that failed, and the identifiers involved, rather than working from the summary banner alone. Keep one hire as the test case for every change so cause and effect stay clear. Verify: the full error detail and one test hire are recorded
2. Open the app and confirm its current mode: check the Sign On and Provisioning tabs to see whether provisioning was ever configured, and note which capabilities the vendor integration supports, such as create, update, deactivate, and sync. Verify: the app current provisioning state and supported capabilities are documented
3. Enable provisioning in the app integration settings, supply the app API connection details the vendor requires, and run the connection test Okta offers before saving any mappings, so credential problems surface before assignments depend on them. Verify: the connection test passes with the supplied credentials
4. Apply the correction in Okta and save it, then re-run provisioning for the single test hire only and read the fresh log entry end to end. If it still fails, treat the new detail as the current cause and do not stack further changes on top. Verify: the test hire provisions successfully or a new specific detail replaces the old one
5. Configure the provisioning options deliberately: enable create and update for onboarding, decide deactivate behaviour for leavers with the app owner, and review the attribute mappings Okta proposes, adding the role or group values the app needs. Verify: the saved options match the onboarding design for the app
6. Re-run the failed group assignment and confirm accounts are created in the target app for a sample of group members, with the attributes and roles the mapping promised. Verify: the hire downstream checks pass in the target app

Why it happens

Okta separates sign-on from provisioning: an app can federate sign-in perfectly while creating no accounts, because provisioning is a distinct feature that must be enabled with its own API connection and capability choices. When onboarding design assumes accounts will appear and the app was built SSO-only, group assignment either errors or silently grants a sign-in path to accounts that do not exist. Enabling provisioning with deliberate capability and mapping choices closes the gap, and the connection test ensures the new path works before hires depend on it.

Variants and edge cases

Vendor app has no provisioning support

If the app offers no SCIM or provisioning API, keep SSO-only and add a manual account task to the onboarding checklist for that app.

Provisioning enabled but deactivation unwanted

Some apps should never auto-deactivate, such as alumni tools. Enable create and update only and document the manual offboarding step.

Group assignment works, individual fails

Check user-level assignment settings and profile completeness for that user; the feature is proven on by the group success.

Compatibility: Applies to Okta app integrations with optional provisioning in Classic and Identity Engine orgs. Requires Okta app admin rights and target app API credentials.

Provenance

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

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

Thread query: Okta app assignment failed for group: provisioning feature not enabled error fix

TL;DR: Enable provisioning on the app with the right capabilities and credentials, then assign again. Open the app integration settings, turn on provisioning with the create and update options the onboarding design expects, connect the app API credentials, run the test, map the required attributes, and only then re-run the group assignment that failed.