Post Tokyo upgrade, certain users RITM email replies no longer update the recordIssue Before the Tokyo upgrade, when a user replies to the email received from a RITM, the instance would still process and add the user's reply to the record.After our Tokyo upgrade, the same user's reply is still received by the instance, however, it is no longer added to the RITM record comments because the user's reply has the 'Target' SN message field as '(empty)'. It loses the reference to 'Table name' (Requested Item) and Document (RITMXXXX).CauseIf your inbound action is not customized and is using the out-of-the-box code version then if you compare the code version history and the code block between the current instance copy which is on Tokyo Vs the previous instance version copy of the inbound action "Update Request Item", you would be able to see that the additional code block of "current.canWrite()" was not present in the Rome version and it got added in the Tokyo version hence the reason the inbound action does not process the update from the received email to the target record in Tokyo version.Sample reference to the Tokyo upgrade history # https://instance.service-now.com/nav_to.do?uri=sys_upgrade_history.do?sys_id=904eda228702211014528735dabb35dc ☞ Sample reference to the upgrade history of the update made to the Inbound action "Update Request Item" # https://instancename.service-now.com/sys_upgrade_history_log_list.do?sysparm_query=file_name%3Dsysevent_in_email_action_1e33e31f0a0a3c74015b770ccb3467c4 ResolutionThis is working as expected. As a workaround, you can consider removing the "current.canWrite()" line from the inbound action "Update Request Item" code block as shown below. Related LinksIf you would like to have the inbound action to the out-of-box code version, roll back the change to the Tokyo version and make necessary changes to the ACL to allow the guest user to process an email and update the RITM.Also, to avoid a similar issue in any of the upcoming versions, consider the below points before upgrading your prod instance and after upgrading your non-prod instance to the next version. Review the changes applied by the system from the upgrade history and compare it with the current code in prod to evaluate what change has been made.After upgrading your non-prod instance to another version, consider performing some regression testing on the key features.This is an optional step. Have one of the non-prod instances available in the older system version at least for two weeks after prod is upgraded to evaluate issues like these.