Provisioning failure when coming from Success factor . Need Input and Solution to this problem

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

[“sailpoint.connector.ConnectorException: Provisioning failed for Onboarding User [108831] Error : Permission employee_import_user_admin is required for creating or updating a user”]

Please consider addressing the following when creating your topic:

  • What have you tried?
  • What errors did you face (share screenshots)?
  • Share the details of your efforts (code / search query, workflow json etc.)?
  • What is the result you are getting and what were you expecting?
2

This appears to be a permission issue. Please verify whether the account used for provisioning has the required employee_import_user_admin permission to create or update the user.

3

Quick question well the script is creating other users properly . Why all of sudden this permission issue came .

4

@inmitkus , just to clarify, is the same script still creating other users successfully while only user 108831 fails, or was it working previously and has now started failing for everyone?

5

Hello @inmitkus

Since other users are provisioning successfully, this doesn’t look like a general SailPoint script issue. Specifically check the SuccessFactors permissions/target population for user 108831. I would first compare user 108831 with a successful user:

  • Is this employee in a different company/legal entity, business unit, department, location, or target population?
  • Does the integration/service account have permission to manage this employee ? Recent credential change for the service account.
  • Was something recently changed in the user’s organizational assignment?
  • Does the provisioning operation for this particular user trigger a create/update path that the other users don’t?

Please test by retry another user with organizational attributes similar to 108831.

6

Hello Kushagra. I assume if the same script is creating other users successfully and only user 108831 is failing, I would not assume the service account is missing its provisioning permissions altogether.

Rohan’s permission suggestion is a good starting point. SAP documents this exact error in KBA 3282705. For users processed through the ExternalUser / ExternalLearner onboarding APIs, the service account needs both User Search and User Import, not just User Import.

A few things I would check with your SuccessFactors admin:

  1. Permissions: In Manage Permission Roles, verify the service account’s role has both General User Permission → User Search and Employee Central Import Settings → Import Employee Data (or Manage User → Employee Import for non-Employee Central instances).
  2. Target population: User Search for the External User / Learner APIs can be restricted to a target population. Check whether user 108831 falls outside the population that role covers, since that could explain why other users work while this one does not.
  3. Compare with a working user: Check whether 108831 and a successful user go through the same API endpoint and operation. If 108831 follows a different onboarding path, that could explain the difference.

I would start with the permission and target-population checks before changing anything in your script. It would also help to confirm whether the other successfully provisioned users are onboarding users going through the same API.

7

Yes this script send mails to successfully created user managers . Its only failing for this one.

8

Hello @inmitkus. Thanks, that helps. Since the script creates your other users and emails their managers successfully, this appears to be specific to 108831 rather than a general provisioning failure.

The exact error you posted is the one SAP documents in KBA 3282705 for the ExternalUser / ExternalLearner (onboarding) path, where the account needs User Search on top of User Import. That points to two things to check for 108831:

  1. Is 108831 specifically an onboarding or external user, while the others are regular employees? If so, only 108831 hits the path that requires User Search, which would explain why it is the single failure.
  2. Is User Search granted, and does its target population include 108831? User Search for the External User / Learner APIs can be restricted by target population, so the permission can be present but still not effective for this particular user.

If you can share the full SuccessFactors API response for the 108831 call, with any sensitive details removed, it may help confirm whether User Search is the missing piece. I would check these before changing anything in the script.

SAP KBA 3282705

9

Its internal user coming as part of success factor which synch the data ans get in the Sailpoint.

Rest the user API I need to get access , Will see if I can get the acess and share the same.

10

Hello Kushagra. Thanks for clarifying. Since 108831 is an internal employee whose data comes from SuccessFactors into SailPoint, I would first check which provisioning operation is actually failing. Your error does mention “Provisioning failed for Onboarding User”, so I would not rule out an onboarding operation back to SuccessFactors just yet.

While you arrange SAP API access, could you check two things?

  1. SailPoint activity: Check whether there is a failed provisioning record for 108831. If it is available, compare the source, operation, and error with a successful user. If not, the script or connector logs may help identify the failing API call.
  2. SuccessFactors status: Ask your SF admin to confirm whether 108831 is an active internal employee or still carries an onboarding / external status, and which API operation is being called for it.

If the failing operation uses the ExternalUser / ExternalLearner upsert API, then SAP KBA 3282705 applies, and the service account (the acting account, not 108831) needs both User Search and User Import permissions. If it is a different operation, the required permission set may differ, so confirming the operation first avoids changing the wrong thing.