Native Identity: Target application generates GUID during account creation and shared back as response
Issue:
In IdentityIQ (IIQ), a master provisioning plan is generated for account creation without a native identity being set, causing IIQ to treat the request as a new account creation with the Create operation. The plan is expanded based on the Create Provisioning Policy and currently adds a single attribute: active = true
The account is successfully created on the target system, and the returned GUID is correctly captured in the access request. However, IIQ is unable to complete the request lifecycle and the request remains in the Verifying state, even after running the Perform Identity Request Maintenance (PIRM) task multiple times.
Verification steps confirm that:
The account is successfully created on the target system.
The account is subsequently aggregated back into IIQ during account aggregation.
The GUID is captured correctly.
Despite these successful provisioning and aggregation events, the access request does not close and continues to remain in the Verifying state.
Have you tried the account aggregation then Perform Identity Request Maintenance. ?
If possible, not sure but somewhere timeout configuration if there try to increase.
Can you check on the Access Requests page under the Provisioning Engine section do you see that all the items have Status as Finished. If some have another status like committed or pending then those items are not able to verify.
I see everything is finished or committed and nothing failed. I did verify in target application too and confirm account is created & attributes are set
The ones that are still showing committed but not finished are the ones that are still pending verification. There may be several reason for this. One possible reason being your schema attribute has different case (uppercase,lowercase) or type than the one you have used in your provisioning policy. This though is not an issue for provisioning but the verification is not completed due to different case.
I verified all attributes along with attribute type(Boolean, String) and found that type differences was causing issue here. Updated one of the attribute type to Boolean in account scheme and it worked.
Yeah, it is because of whatever you have provisioned that is not confirmed by the system, meaning after aggregation is completed, SailPoint is not able to confirm that it is not available in the application after you have provisioned. The reason could be many things; sometimes whatever the attribute you are sending to update might not support doing it (SailPoint will not throw an error either) or failed in the application itself but did not return the failure message response, or maybe the schema you defined does not match exactly. So it could be many reasons.
Hi Team,
I have onboarded a web services SCIM application. The account has created and provisioned to user after aggregation but the access request still failed without any error message when I check the identity request XML it show error message “task_msg_identity_request_verification_noaccountId” not able to resolve it. Please help me out as tomorrow is my demo session.