Share all details about your problem, including any error messages you may have received.
We are seeing many identityRequests are getting failed with time out error, but in the identity request all items are provisioned success and finished, so any reason why this error coming in Access request,
@venumgm235 Please confirm if the attributes provisioned via access requests are the same which are available in the application schema as well?
If there is a mismatch, you’ll see items timing out during verification.
I attached the all Access request xl as well right, if you see all are finished, it’s means verification is also success right ? incase if any schema attribute not available it shows as not verifiable right ?
Hello Venugopal. From the IdentityRequest XML, this looks like a verification timeout, not a connector provisioning error. All Azure AD items reached provisioningState="Finished" except one:
name="physicalDeliveryOfficeName" ... provisioningState="Commited" value="MGM Resorts International Operations, Inc."
So physicalDeliveryOfficeName is the item IIQ could not verify. The account create and group add both came back ProvisioningResult status="committed", so provisioning was accepted; the request stalled at verification.
Since optimisticProvisioning="false", IIQ waits for the provisioned value to be read back and matched before finishing the item. The Perform Identity Request Maintenance task does this check, and its option “Number of days to attempt to verify the request with the Identity model before failing” controls how long it keeps trying. An item it cannot verify stays at Committed or Pending, which is what timed out this request.
I would check:
That physicalDeliveryOfficeName is present in this Azure AD application’s account schema.
That the user’s Link contains this attribute with exactly MGM Resorts International Operations, Inc., since verification is a value match.
If not, run an Azure AD account aggregation, confirm the Link again, then rerun Perform Identity Request Maintenance.
The “The application: Workday does not exists in ‘ServiceNow Ticketing Application’ custom object” line is stored separately as an Info message from your own ticketing customization, so it does not appear to be the cause of this timeout.
Thanks for the reply, at the time of account creation physicalDeliveryOfficeName attribute value is same as access request but after 2hr location updated to different value as the location changed in HR system and it’s expected, so attribute updated before the Perform identity request maintenance so might be the reason it’s failed to verify ? in that case how over come this case ?
@venumgm235 Attribute values should remain same between provisioning and next aggregation+ PIRM task. If the value is getting changed, then that particular attribute will become non verifiable.
@neel193 but that is expected right attribute value can be changed at anytime, if that’s the case all AR’s may get failed right, so instead of getting failed, can we updates as warning or something ?
We identified an issue with the PIRM task verification logic. Currently, it checks the request date instead of the completion date.
Because approvals often take several days, our disconnected applications fail immediately after approval completion because the PIRM verification window has already expired.
We need to update the logic so that the verification date aligns with the actual completion date rather than the initial request date.
Hello Venugopal. Yes, that explains it. If physicalDeliveryOfficeName was provisioned with one value and HR changed it before PIRM verified the request, IIQ is now matching the original requested value against a different current value, so the item cannot verify even though both changes were valid.
For an attribute that is expected to change independently of the access request, increasing the verification period will not really help, since the original value may never come back. I would handle it in one of these ways:
First check whether physicalDeliveryOfficeName really needs to participate in access-request verification. If HR owns the value and it can change at any time, it is not a good candidate for strict request verification.
If it must remain in the account creation policy, a community-reported PIRM task entry has been suggested for excluding a specific attribute from verification:
This is not in the current PIRM documentation, and in the thread where it comes up it was suggested rather than adopted as the fix (that case was a Web Services connector and ended up being resolved by a schema mapping correction). So I would validate it on your 8.5p1 in a lower environment before relying on it. Since it is set on the PIRM task rather than on an individual request, I would also treat its scope cautiously until confirmed. Discussion here: PIRM ignoredVerifiedAttributes.
I do not see a documented option to convert an unverifiable item into only a warning. The documented behavior is that an unverified item stays Committed or Pending until the verification window expires.
Your disconnected application observation looks separate. The documentation defines the verification period but does not state whether it starts from request creation or provisioning completion. If you can reproduce a request expiring right after a long approval cycle, I would raise that with SailPoint Support for 8.5p1 with the request timestamps, PIRM configuration, and task logs.
I had a similar discussion with one of the SailPoint employee regarding this and they suggested this approach to ignore that attribute from PIRM task. If this attribute is HR managed, why do you even need to send it from IIQ. You can ignore that attribute and let HR team take care of it.
