I’m working on a Web Services application using SOAP APIs in SailPoint IIQ 8.4p2.
During account creation, the SOAP request completes successfully, and the account link is created. However, I see the following error in the logs:
Cannot insert the value NULL into column 'native_identity', table 'identityiq.spt_link'; column does not allow nulls.
My configuration:
Custom authentication retrieves the JSESSIONID from the Teamcenter login API. SailPoint’s cookie management can reuse it across subsequent operations, avoiding repeated logins and manual cookie handling.
A Before Operation Rule iterates through the provisioning plan’s attribute requests, builds the SOAP payload, and updates the endpoint.
Account creation and entitlement assignment use separate API endpoints and payloads.
CreateAccountwithEntitlement is set to False.
The account creation response returns a unique ID, which is mapped to the identity attribute.
processedResponseObject appears to contain the expected values:
Hello Nitin. Since the SOAP create succeeds and you can already see the Link in IIQ, I would first check which provisioning step is throwing the SQL 515 error. It looks like IIQ is attempting to insert a Link without a native_identity, but we need to find out why.
A few things I would suggest checking:
Identity Attribute: Your processedResponseObject contains both personUID and uid. Could you confirm which one is configured as the Identity Attribute in the Account schema? Also check whether the Create Account response mapping and Root Path correctly populate that attribute.
Get Object: If you have configured Get Object, IIQ can call it after account creation. Check whether the identity attribute is available from the provisioning plan or Create response, and whether Get Object returns the expected account identifier. See the Supported Operations documentation.
After Operation Rule: If you are using one to modify the account response, make sure the returned data contains the identity attribute (After Operation Rule docs).
Regarding the Before Operation Rule running twice, with createAccountWithEntReq=false, IIQ creates the account first and processes entitlements separately. So multiple executions may be expected. I would check the logs to confirm which operations are invoking it.
One other possibility: a similar issue was reported with password provisioning, referencing IIQETN-11720. If your Create policy includes a password and you see Hibernate errors, that may be worth investigating too.
I would start with the stack trace before changing anything. Could you confirm which attribute is configured as the Identity Attribute, whether Get Object is enabled, and which operation is failing? That should help us narrow down where the native identity is getting lost.
Identity Attribute: is uid processedResponseObject[{personUID=A9mpMKTVlFfngA, uid=A9ppMKTVlFfngA, user_id=u307243, license_level=0, default_group=wwGF1KMMlFfngA}]
Get Object: getObject is getting the native identity as unique generated value.
After Operation Rule: i have observed that issue for create account only. i had removed all other operations kept only create account. nothing in my after-operation rule. still getting the same error.
Hello Nitin. Thanks for checking. Since uid is present in processedResponseObject and the error still occurs with only Create Account configured, I would leave the response mapping as it is for now and check where IIQ is failing to save the Link.
A few things I would suggest:
Existing Link: In Identity Debug, check whether the Link’s nativeIdentity matches the uid returned by Create Account (A9ppMKTVlFfngA). Also check whether the Link belongs to this provisioning attempt or an earlier one.
Get Object and After Operation Rule: When you tested with only Create Account, was Get Object also removed? And is the After Operation Rule completely unassigned?
Before Operation Rule: Is it still executing twice? If yes, check the actual SOAP requests to confirm whether Create Account is being called more than once.
Could you also share the relevant SQL 515 stack trace? That should help us identify which IIQ operation is attempting the Link insert. Does your Create plan include a password attribute? A similar issue involving IIQETN-11720 reported the same SQL error along with a Hibernate LazyInitializationException on identity.bundles.
I would start with the stack trace and existing Link before changing anything else. Those should help us narrow down the actual cause.
I would recommend checking the native_identity mapping in the Create Account response and verifying that the returned unique ID is correctly assigned to the account’s native identity before SailPoint creates the link. Even if processedResponseObject contains the expected values, the connector may not automatically use them as native_identity.
Also, check why the Before Operation Rule executes twice and compare the provisioning operation and response data from both executions. This could help identify whether the issue is related to repeated processing or response handling.
I’d start by enabling detailed connector logs and confirming which response attribute SailPoint IIQ 8.4p2 actually uses to populate native_identity. That should help narrow down the root cause.