When the approver approves/rejects the case via email, the case receives email and the case is updated but the approver's organization unit is updated as 'Unit' when the approver has a different Organization Unit in his her user profile.
What sort of request is being sent from the email to the server and by what mechanism does the server pick up the respond? You might need to use an HTTP debugger (like Fiddler) to get some insight. Does the server respond using the operator's authenticated requestor/access group? My guess is probably not. That means that you're probably using the batch requestor. At least to start things off (though it may get switched in flight).Have you traced the approval using the platform tracing tools? You might want to try that as well, to get some insight into what does/doesn't happen on click.
Thank you for the information. I have used the tracer by approving from the portal and found that the OOB activity Work-.RecalculateAndSave, Step 2 sets the value to .pxUpdateOrgUnit property as pxRequestor.pxOrgUnit. If the approver approves from the portal, the system accurately identifies the clipboard property to set the value of the organization unit. The issue arises here because the manager is approving from the email and the update happens when the email is processed by the agent and the pxOrgUnit is set as 'Unit'. I need to find how agent processing is setting the Orgunit as 'Unit'.
The audit history looks like what you have attached. The pxUpdateOperator accurately dispalys the operatorID of manager. However, the pxUpdateOpName displays the approver name followed by [ClassName.pyUserName].AgentName on which I also have a question.