When we tried testing it by requesting an entitlement, the account was provisioned to the user. However, when we check the account, the Account Name was set to “–”. What could be causing this issue and how do we resolve it? Aggregating the source after account creation does not solve it.
I tried changing the username to userName in the response mapping, but still getting the same result. Should I also change the account schema from username to userName?
I did this and the account name is still “–”. However, when I checked via the API endpoint, the account was created successfully. I just have to perform an aggregation for the account name to reflect in ISC
Have you added a get object operation for single account aggregation ? after each operation, the webservice connector get object to aggregate the created or modified single account details.
Hello Jasmine. Since the Account Name appears after aggregation, your email schema attribute and Account Aggregation mapping are working. So this does not look like a username / userName issue, and I would not rename the schema attribute for this.
The remaining gap is only right after Create Account, before an aggregation refreshes the account. I would work it in this order:
Check the Create Account response first. If it already contains email, make sure the email schema attribute is mapped to the correct Attribute Path in the Create Account Response Mapping. That should let ISC populate email from the Create response without a separate Get Object call.
If the Create response does not return email, configure or check a Get Object operation. Web Services supports calling Get Object during Create provisioning to read the newly created account back without waiting for an aggregation. SailPoint also provides the skipGetObjectInCreate setting to skip that Get Object call when it is present during Create provisioning.
For Get Object, verify that its response returns email, that email is mapped correctly in its Response Mapping, and that it retrieves the new account by its Account ID, commonly $getObject.nativeIdentity$.
I think the original issue may have been the value for userName in the response not matching what you configured in the mapping and schema. On create, this may have caused it to not retrieve the value back when it did the get object. From here, since it could not find the value, it set to —. When you updated the schema, it found the value and was able to set it when you aggregated again.
I was also going to suggest checking the “skipGetObjectInCreate” flag as a possibility for this. It sounded like the account was not being read back and the nativeIdentity value (account name) not getting set. When you do the aggregation, it is reading back in and setting correctly. However, this would only have been if this was still happening right after a create, before a full aggregation.
Hello Jasmine. Thanks for sharing the screenshots. I think I see where the issue might be.
In your first screenshot, the operation is named Single Account Aggregation, but the Operation Type is still set to Account Aggregation. I would change that to Get Object, since these are two different operation types in Web Services. You can keep the GET method if that is what your API expects.
I would also check two things:
Response Mapping: your screenshot shows userName → username. If your schema still uses username as the Account ID, keep username on the left and use the actual API response field on the right. For the Account Name, email → email should work if the response contains that field.
Get Object during Create: check that skipGetObjectInCreate is not set to true, since you want ISC to read the account back after creation.
I would correct the Operation Type first and test again.
If you still get an error, could you share the exact error message and the JSON returned by the GET endpoint? We can then check whether $getObject.nativeIdentity$ is passing the value your API expects.
