I’m working with the Web Services (SaaS) connector in SailPoint IdentityNow, and I’m encountering an issue with the Create Account operation where the $plan.Email$ placeholder is not being populated correctly during provisioning.
Issue Details:
Here is the request body I’m using for the create account operation:
{
"Email": "$plan.Email$"
}
However, I’m getting the following error during provisioning:
rust
CopyEdit
[ConnectorError] Account create failed. HttpClientWrapper.ts Response status :400 doesn't match to allowed success codes : 200,201,2**
Response: {"errorCode":"400","errorMessage":"Email is a required field."}
It appears the $plan.Email$ is not giving value, leading to a 400 error from the target application.
What I’ve Tried:
If I pass a static value in the body like:
json
CopyEdit
{
"Email": "Test@abcd.com"
}
The account gets created on the target, but the provisioning still shows an error in the IdentityNow event log:
css
CopyEdit
[ConnectorError] Account create failed. Response status: 400
Response: {"errorCode":"400","errorMessage":"The email address 'Test@abcd.com' is already in use."}
Interestingly, after aggregation, the account gets linked to the identity correctly.
Settings Checked:
The “Create Account With ‘Ent’ Request” option is enabled in the Additional Settings of the connector configuration.
Attribute mapping for Email exists in the Identity Profile and provisioning policy.
Looking for Guidance On:
Why is $plan.Email$ not resolving during the create account operation?
What might be missing in the configuration or provisioning policy?
Seems “Email” is the mandatory attribute that is required to create account in target system. In “Create Account” policy, how the value for email attribute is being fetched? Is it from Identity attribute?
Check if “Email” is the correct attribute/technical name that is being used in the target system, and it should match with the account schema.
You wouldn’t need this to be checked for the error you’re seeing. This is required to be checked if your entitlement attribute need to be part of the “Create Account” request JSON body.
Can you check if the “Work Email” identity attribute exists for the user that you’re testing this request against and if that value is of the format value@domain just to avoid the validation on target side. Just thinking out load that maybe your work email value in ISC for the user is “test” but the target system is enforcing a data validation that it is incorrect email format value. Helpful to rule out this possibility.
Value is exist for work Email, and it is in correct for which is required for creation account on target, as i can see if i am passing hardcode value in Email “Email”: “Julie.q@abc.com”, it is creating account on target but when i am writing it via $plan.Email$ , it is not assigning value ,
is there anything do we need to enable to get $plan attribute value in Body?
i am having one more doubt when i am passing hardcode value as “Email”: “Julie.q@abc.com” so it is creating account but showing error as
[“[ConnectorError] Account create failed. HttpClientWrapper.ts Response status :400 doesn\u0027t match to allowed success codes : 200,201,2**,2**,2** \n response : {"errorCode":"400","errorMessage":"The email address \u0027Julie.q@abc.com\u0027 is already in use."} (requestId: f44bb69c12f6415ea062fae0cac61b15)”]
now i can get data by $plan but it is giving me error in create account
[“[ConnectorError] Account create failed. HttpClientWrapper.ts Response status :400 doesn\u0027t match to allowed success codes : 200,201,2**,2**,2** \n response : {"errorCode":"400","errorMessage":"The email address \u0027Susan.Simpson@Sonoraquest.com\u0027 is already in use."} (requestId: 264390a6bfde4c93b14d1a374bec157c)”][“[ConnectorError] Account create failed. HttpClientWrapper.ts Response status :400 doesn\u0027t match to allowed success codes : 200,201,2**,2**,2** \n response : {"errorCode":"400","errorMessage":"The email address \u0027Susan.a@abc.com\u0027 is already in use."} (requestId: 264390a6bfde4c93b14d1a374bec)”]
Are you using email as accountID as an email in your webservice application? If yes then you need to use $plan.nativeIdentity$ instead of using $plan.Email$