Unable to create Account in ServiceNow

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

8.5 P1

Share all details about your problem, including any error messages you may have received.

We are trying to create account in ServiceNow. Whenever we are trying to create a new account, we receive this error.

Failed to create the account. [ ObjectAlreadyExistsException ]
[ Error details ] The account ‘mowahipe_adm’ already exists in the ServiceNow instance. Invalid table

i have tried multiple option by passing the group entitlement, or without passing any entitlements. It keeps giving same error.

I have tried to create a new account through Bruno using the same Service account that is used in Sailpoint. There we are able to create successfully. Below is the body of the POST request from Bruno

{
"user_name": "WJtingWJ_adm",
"first_name": "Dimiv",
"last_name": "Togupo"

}

Below is my Provisiong plan from Sailpoint which gives error. Tried with multiple users and keep receiving same error.

<ProvisioningPlan nativeIdentity="00456366" targetIntegration="ServiceNow" trackingId="79263e758764467eaa4a36ef3ecf7e70">

<AccountRequest application="ServiceNow" assignmentIds="d10a75206a0d4da885cc452f3320298a" op="Create">
<AttributeRequest name="first_name" op="Set" value="Pejyv"/>
<AttributeRequest name="last_name" op="Set" value="Mowahi"/>
<AttributeRequest name="user_name" op="Set" value="mowahipe_adm"/>
</AccountRequest>
<Attributes>
<Map>
<entry key="requester" value="spadmin_eng"/>
<entry key="source" value="Batch"/>
</Map>
</Attributes>
<Requesters>
<Reference class="sailpoint.object.Identity" id="0a2da10d865e10298186c9d4dfbe2213" name="spadmin_eng"/>
</Requesters>
</ProvisioningPlan>

By Passing the required group also same error

<ProvisioningPlan nativeIdentity="00456366" targetIntegration="ServiceNow" trackingId="79263e758764467eaa4a36ef3ecf7e70">
  <AccountRequest application="ServiceNow" assignmentIds="d10a75206a0d4da885cc452f3320298a" op="Create">
    <AttributeRequest name="groups" op="Add" value="841d185ddbcb7810791cdae2f3961909"/>
    <AttributeRequest name="first_name" op="Set" value="Pejyv"/>
    <AttributeRequest name="last_name" op="Set" value="Mowahi"/>
    <AttributeRequest name="user_name" op="Set" value="mowahipe_adm"/>
    <AttributeRequest name="sys_class_name" op="Set" value="User"/>
  </AccountRequest>
  <Attributes>
    <Map>
      <entry key="requester" value="spadmin_eng"/>
      <entry key="source" value="Batch"/>
    </Map>
  </Attributes>
  <Requesters>
    <Reference class="sailpoint.object.Identity" id="0a2da10d865e10298186c9d4dfbe2213" name="spadmin_eng"/>
  </Requesters>
</ProvisioningPlan>
2

Hi @sahoos9

Based on what you’ve shared, the provisioning plan itself looks reasonable. Since the same service account can create users successfully through Bruno, I don’t think the issue is with the XML payload.

The combination of ObjectAlreadyExistsException and Invalid table points more toward the connector configuration than the provisioning plan.

I would compare the following between Bruno and the IIQ application configuration:

  1. The REST endpoint being called (for example, whether IIQ is posting to the same table/API as Bruno).

  2. The HTTP method and request body generated by IIQ.
    The object class and sys_class_name mapping.

  3. The Create Account operation in the Web Services connector configuration.
    Any Before/After Provisioning Rules that may be modifying the request before it is sent.

Since the error occurs even when using different user_name values and regardless of whether groups are included, it doesn’t appear to be caused by the provisioning plan itself. I would enable connector debug logging and compare the exact HTTP request generated by IIQ with the successful Bruno request. That comparison should quickly identify whether the endpoint, payload, or mapping differs. If the endpoint is incorrect, ServiceNow can return an “Invalid table” response, while IIQ may surface it as an ObjectAlreadyExistsException.

3

Hello Sapan. Your provisioning plan looks fine. I think adding the group or sys_class_name won’t fix this.

Bruno isn’t testing the same path. It posts directly to /api/now/table/sys_user, but the SailPoint connector provisions through import-set tables and transform maps. So the same service account can work in Bruno and still fail through IIQ.

The Invalid table part might help us to troubleshoot. I would check with the ServiceNow team:

  • The SailPoint Identity Governance Connector app is installed correctly.
  • The SailPointSysUsers import-set table exists and the connector account can access it.
  • The SailPointSysUser transform map is active and targeting sys_user.
  • No failed transform scripts, ACLs, or business rules are blocking the insert.
  • The connector service account has the import_admin role along with the required connector permissions.

Also check whether those failed users were actually created in sys_user. SailPoint documents that when import_admin is missing, provisioning can complete on the ServiceNow side but fail returning the result. The next retry then correctly throws ObjectAlreadyExistsException.

Quickest way to confirm is to open the import-set history in ServiceNow and check the failed row in SailPointSysUsers. That will show the actual table, ACL, or transform error behind the generic message IIQ is surfacing.

4

Thanks Harish. Application team found that Transform Map was not enabled. Enabling it resolved my issue. Thanks a lot for your help