Web Service Connector - Create Account Error : Identity Attribute was not Found

Hi everyone,

We’re currently implementing a web service connector and have encountered the following issues:

  • The attribute email, which is defined as the Account ID in the account schema, is not being included in the provisioning plan, even when referencing $plan.nativeIdentity$ or $plan.email$.
    Please note that this attribute is correctly configured in the Create Account schema.
  • To work around this, we temporarily assigned another attribute (tempId) as the Account ID. However, we now receive the following error during provisioning:
    Exception occurred while performing ‘Create’ operation on identity ‘xyz@yyy.com’:
    Error: Identity attribute [tempId] was not found.

For context, tempId is not a real attribute on the target system. It’s a placeholder we added to the account schema, which retrieves the same value as email during Account Aggregation and Get Object operations.
Interestingly, despite the error in SailPoint, we’ve confirmed via Postman that the account is successfully created on the target system.

We’d really appreciate any insight into why the Account ID attribute might not be injected into the provisioning plan, and how best to resolve this.

Thanks in advance for your help!

Hi @ama1 ,

can you share below things

  1. request body for create account
  2. provisioning policy for create and rule if there are any
  3. before provisioning rule
  4. create Api request body from postman

@ama1 what is you body can you paste here?

You will need to add the email attribute to your provisiongncreate profile

I’m struggling with a similar error message - not sure if it’s the same cause though. In my case, the account ID is generated on the source system and returned in the response body. When we try to return the id via response mapping we get the same error message you’re seeing.

So, are you sure it’s not being included in the provisioning plan? If account creation is working and you are mapping the value in response mapping, then it might be the case that the value is included in the provisioning plan and you could just remove it from the Response Mapping page.

Another thing would be to try “$request.nativeIdentity$” instead of “plan”.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.