ISC Wrong variable content Email Templates Access Requests

Hi all, :slight_smile:

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

  1. The API to reject access requests approvals /v3/access-request-approvals/:approvalId/reject
  2. Workflows action Deny Access Request

The email will show the name of the person who was at that point marked as owner of the access request approval. This is not always the person who triggers access request approval rejection as it could be caused by an admin or a workflow, so the value is wrong. This is then sending wrong information to the requester/recipient as it looks as if the request got rejected by someone else.

What is the correct behavior?

The email template should populate the variable rejecterName with the true name of the rejecter, not of the person who was currently assigned the access request approval.

What product feature is this related to?

Identity Security Cloud - Access Request - Email Templates

What are the steps to reproduce the issue?

As identity X, request access for identity Y, and ensure that identity Z is the approver of the access request. Then use the credentials of identity A (an admin) to call the API to deny the access request, and take a look at the mails send to identity X and identity Y. It should mention identity A but will mention identity Z. In addition, you can repeat this but then reject the pending approval similarly by using the workflow action.

Submitted a Support ticket: CS0323772

I just saw that this type of bug appears in other places as well. For example if you use the reassign API. It will wrongly say that the original approver reassigned the request, even though it actually was an admin.

Support confirmed they reproduced the bug

Did they confirm it is a bug or are they still checking if this is maybe “by design”? :slight_smile:

I did not receive an answer like this (yet), just that Support managed to replicate the issue and have contacted the engineering team. I have yet to receive anything more after this.

I just found a similar bug while testing: ISC Access Request Approvals blames reassignment on wrong identity

Perhaps SailPoint has tested this functionality using too few identities such that they could not see if the content was truly correct. Or something else strange is occurring.

1 Like

Update from SailPoint Support:

A fix might be there already, SailPoint Support will test first to be sure.