Self Service request is going to error after final Approver.

Question

Hi,
Here we configured leave system through EIT and we are using self service (EIT) to make leave request. We have 3 level of approver for Annual Leave. Problem here is after final approver (3rd approver) approves the leave then request is going in to error. I traced the item key through Workflow Administrator > Status Monitor.
The error is Details are given below (Status Monitor)
Failed Activity     
Notify HR About Commit Application Error
Activity Type     
Notice
Error Name     
WFNTF_ROLE
Error Message     
3205: '[email protected]' is not a valid role or user name.
Error Stack     
Wf_Notification.Send([email protected], HRSSA, HR_EMBED_DEPT_COMMAPPLERR_MSG, WF_ENGINE.CB) Wf_Engine_Util.Notification_Send(HRSSA, 1649471, 195663, HRSSA:HR_EMBED_DEPT_COMMAPPLERR_MSG) Wf_Engine_Util.Notification(HRSSA, 1649471, 195663, RUN)
I appreciate if someone can help me.
Regards,
Jojo George

Answer 1

Okay, if the $PROFILES$ reference has been working for a long time that doesn't sound like a problem. I would then suggest this is an unusual data scenario where the value the user selected was temporarily available. Don't ask me how - it's your data! The user that submitted it might be able to shed some light. For example, this kind of thing might do it:
1) Manager logs on to ESS, starts an SIT transaction (the one in question) and Saves for Later. This sets $PROFILES$.PER_PERSON_ID to themself.
2) Manager then switches to MSS and views one of their employees - this sets $PROFILES$.PER_PERSON_ID to their employee, not themselves.
3) Manager then navigates to Homepage and continues the Saved for Later transaction from the Worklist (ie, without clicking on the ESS responsibility). Perhaps $PROFILES$.PER_PERSON_ID is still set to their direct report rather than themselves?
4) Manager then selects one of their employees contracts rather than their own (because of $PROFILES$.PER_PERSON_ID being wrong).
5) Manager submits the transaction.
I don't know if that's possible or even if that's how it behaves. But it sounds plausible and is an example of perhaps the weird set of circumstances that might have happened here. Regardless, I'd still maintain that this value was available to the user in the Value Set at the time they submitted it.
If it's just a one-off data problem and this has been working fine for a while I wouldn't worry about it. Bin the workflow, get the employee to re-submit. Job done.