ISC Access Request Approvals blames reassignment on wrong identity

[angelo_mekenkamp]

Hi all,

Short bug description:
The forwarderName attribute in GET /v2024/access-request-approvals/pending is displaying the wrong name.

Long bug description:
Have a role with manager as approval step for access request. Have 5 different identities (A,B,C,D,E) to be really clear on which values are being taken. Identity C must be the manager of identity B.

Log in as identity A and this role on behalf of identity B, whose manager is identity C.
Using the personal access token of identity D, fetch the data of GET /v2024/access-request-approvals/pending to get the id of the related pending approval, then call the API POST /v2024/access-request-approvals/:id/forward with the personal access token of identity D and forward the request to identity E, with comment TEST: reassigned from identity D.
Now look at GET /v2024/access-request-approvals/pending again and you will see the approval with the following attribute in forwardHistory:

"forwardHistory": [
  {
    "oldApproverName": "identity C",
    "newApproverName": "identity E",
    "comment": "TEST: reassigned from identity D",
    "modified": "2024-11-07T12:53:29.048Z",
    "forwarderName": "identity A",
    "reassignmentType": "MANUAL_REASSIGNMENT"
  }
]

The forwarderName attribute points to the original requester (identity A), but it should point to the identity who actually forwarded it (identity D), as can be seen by the documentation (and common sense): list-pending-approvals | SailPoint Developer Community

Tagging @jennifer_mitchell for awareness. I will submit a support ticket.
This looks like a similar issue as the bug below, but it occurs at a different location.

ISC Wrong variable content Email Templates Access Requests

Hi all, What problem are you observing? If you reject an access request, the requester and recipient will receive an email with this message. This will happen through email templates Access Request Decision and Access Request Decision For Other. They both can refer to the variable rejecterName which, if the request was denied, will contain: The display name of the identity who denied the request. However, this is not always the case. If we reject the request either through T…

I’ve got to say I am surprised to see this bug exists, but also that it either hasn’t been detected before or fixed already.

Kind regards,
Angelo

[angelo_mekenkamp]

Support ticket for my reference: CS0325443

[chirag_patel]

Even I was surprised when I checked details. It shows the requestor as forwarder name. I forwarded request manually from approver A to B and the audit logs show forwarder name as requestor himself.

[angelo_mekenkamp]

Update from SailPoint Support:

@SailPoint Support

We have submitted this to our engineering team as we were able to successfully replicate this as well.

We will keep you posted over the progress.

In the interim, we would request you to kindly bear with us.

[angelo_mekenkamp]

Got an update from SailPoint Support:

@SailPoint Support

The engineering team have enabled this fix on the dev tenant, can you please verify this for your dev tenant?

I checked this on my test tenant and the forwarderName is appearing correctly now.

I checked and although the API now shows the right value, the emails send from ISC still blame it on the wrong identity. I hoped that solving the above was sufficient, but unfortunately SailPoint has this configured wrongly in different spaces and rather than checking and analysing this themselves, I have to report back to SailPoint Support again that ISC Access Request Approvals still blame the reassignment on the wrong identity in order for this to get truly fixed.

[IIQUserOnCompass (Terry Yau)]

Looks like you’re treated as the bug hunter, and that SailPoint is only looking at the reported issue in a tactical fashion instead of the overall use case comprehensively.

[angelo_mekenkamp]

Perhaps, but I am not a bug hunter. I just want to properly test the functionality I want to implement for my clients, and I am quite dumbfounded that so many of the issues I find are not caused by me making a mistake during implementation, but simply because I stumble on so many bugs within ISC. Bugs that I would have expected to be found internally by either SailPoint employees or externally hired testers prior to releasing to partners and customers.

[IIQUserOnCompass (Terry Yau)]

@angelo_mekenkamp

I am quite dumbfounded that so many of the issues

I’m in the same boat. Not only issues, but quirks, OOTB limitations / lack of features / rigidness.

@angelo_mekenkamp

Bugs that I would have expected to be found internally by either SailPoint employees or externally hired testers prior to releasing to partners and customers.

Or even anytime in the past 7 years. Like, ISC is also a moving target, I get that…but it sure has some ‘noob’ bugs / issues / inconsistencies that you don’t expect from a ‘supposedly’ class-leading IGA vendor.

Personally, I’m looking at / assessing ISC as a whole separate product, regardless of SailPoint’s reputation from their on-premises history. Not letting that reputation cloud my judgment (pun not intended).

[angelo_mekenkamp]

@angelo_mekenkamp

I checked and although the API now shows the right value, the emails send from ISC still blame it on the wrong identity. I hoped that solving the above was sufficient, but unfortunately SailPoint has this configured wrongly in different spaces and rather than checking and analysing this themselves, I have to report back to SailPoint Support again that ISC Access Request Approvals still blame the reassignment on the wrong identity in order for this to get truly fixed.

I got an update from SailPoint Support that this has been fixed as well. I tested it and saw it works now on our tenant.

@community_moderators, please mark this post as fixed as I can’t do that myself.