Hi,
I’m facing an issue with the Web Service connector during the create account operation, the provisioning fails with a native identity error. Also, it’s something returned by the target application after the account is successfully created but the connector appears to be expecting the native identity…Any insights?
[“[ConnectorError] Native identity is neither present in the plan nor in the response (requestId: ee41b840c68f4771911c127383146aea)”]
Hi @ssel
The error indicates that the Web Services connector couldn’t determine the native identity after the Create Account operation. The native identity must either be available in the provisioning plan or be returned by the Create Account API and mapped to the schema attribute configured as the Account ID. If neither is available, the connector raises this error.
Could you share:
That will help determine whether the issue is due to response mapping, the API response, or the schema configuration.
Can you share your create account provisining policy and create account body request?
Hi @ssel ,
In your Create Account profile, did you map the userId attribute, or is it system-generated?
Even if the userId (which represents the nativeIdentity) is generated by the target application, you should still map it in your Create Account profile to an arbitrary Identity attribute (for example, username or uid).
This prevents ISC from blocking the account creation due to a missing required Identity attribute.
Also, make sure your target application returns the generated userId and that it is correctly mapped to the userId attribute defined in your account schema in the response mapping definition.
Sometimes the target userId is not immediately available after account creation. In that case, you can enable the following option in your source’s Additional Settings:
Hello Selvarani. One likely issue is the UserId response mapping path. UserId is configured as the Account ID, but it is not in the Create Account plan, so ISC needs to obtain it from the API response.
Most of your response paths use MobileUser.*, but UserId is mapped only as UserId. Could you check the masked Create Account response and the Root Path under Response Information? The correct path depends on that configuration:
UserId under MobileUser and no Root Path points there, try changing the path to MobileUser.UserId.$.MobileUser, then UserId is the correct attribute path. In that case, check whether the response actually contains a non-null UserId at that location.SailPoint prefixes the configured Root Path to each response attribute path. (Response Mapping documentation)
Skip getObject Call during Create Provisioning is already enabled, so the connector skips the Get Object call during account creation. Since the Account ID is also absent from the plan, the Create Account response must return and correctly map it. (Additional Settings documentation)
If the target generates UserId, I would suggest avoiding mapping an unrelated identity attribute to it just to include a value in the plan. The Account ID should match the actual identifier assigned by the target. Sharing the masked Create Account response and Root Path would help narrow it down further.
Thank you…Skip Object call is already enabled moreover I have a similar setup in the lower environment and it works fine… have deleted the source and deployed the same in production also double checked the configuration but it’s still not working. Also, will try the userid mapping and see.
The UserId is in the root path, also like I said previously, it works fine in Sandbox but not in production.
Additonally, I tested this in the postman, it creates the accout successfully
Thanks for sharing those details. The JSON you shared looks like the Create Account request body (the $plan.*$ placeholders show what ISC sends to the target), not the API response. And "UserId": null in the request confirms the native identity is not being supplied from the plan side.
Since you mentioned UserId is covered by the Root Path and the same configuration works in Sandbox, the mapping path itself is probably not the issue. The question is whether the Production API is actually returning a non-null UserId in its response.
A successful Postman call confirms the account gets created, but it does not necessarily confirm that the response contains a usable UserId. It would help to compare the raw Create Account response bodies from both Sandbox and Production. If you do not have the Postman response handy, the VA connector logs (ccg.log) from the production VA should also show the actual response the connector received.
UserId with a value, it would be worth verifying the exact JSON path matches the response mapping.UserId as null or does not include it, then the target API is the part that needs to return it so ISC can create the account link.With Skip getObject Call enabled and UserId absent from the plan, the Create Account response is the only place ISC can pick up the native identity. (Response Mapping docs)
The Sandbox vs Production response comparison should point to the exact cause.
Production Create Account Response: {
"UserId": 0,
"MobileUser": **null**,
"ErrorId": 2,
"MissingLicensesNames": **null**,
"ErrorDesc": **null**,
"PasswordValidationErrorId": **null**
}
But I got the UserID populated in Sandbox for the same request body
no, I haven’t tried that mapping. Below is the postman response without that mapping, {
"UserId": 0,
"MobileUser": **null**,
"ErrorId": 2,
"MissingLicensesNames": **null**,
"ErrorDesc": **null**,
"PasswordValidationErrorId": **null**
}
Can you try to mapped it with an arbitrary identity attribute like username for example ?
Hello Selvarani. The UserId → UserId response mapping appears correct, since Production returns UserId at the response root and the same mapping works in Sandbox. SailPoint extracts response values using the configured Root Path and attribute path. (Response Mapping docs)
The immediate issue is the Production response:
"UserId": 0,
"MobileUser": null,
"ErrorId": 2
This does not provide ISC with the actual Account ID that Sandbox returns. Since UserId is not in the provisioning plan and Skip getObject Call during Create Provisioning is enabled, ISC must obtain the native identity from the Create Account response. (Additional Settings docs)
It might be worth checking with the NowForce API team:
ErrorId: 2 mean on their side?UserId: 0 instead of the generated value?Once Production returns the actual UserId, the existing response mapping should be able to capture it. Mapping an unrelated identity attribute to UserId would not resolve the underlying Production response issue.
Thank you for all your responses, the issue has been fixed