Facing issues with the Inbound Email Action

[Shashank_Jain]

Hello Community,

I'm facing an issue with an Inbound Email Action in ServiceNow.

I've created an Inbound Email Action with Action type set to "Record Action" and Type set to "Reply". I removed the condition from the Condition field and, in the Action Script, I'm simply trying to print a log for testing—but it’s not working.

Use case: When a new case is created, an email notification is sent. When we reply to that email, it should update the Additional Comments field of the corresponding case.

However, the script inside the Inbound Email Action doesn’t seem to execute. Even when I remove all logic and just try to log a message, it still doesn't work.

In the email log, I’m seeing this error: "Unable to determine origemail"

Could this be preventing the Inbound Email Action script from running?

Any help would be appreciated. Thanks!

[Ankur Bawiskar · Accepted solution]

@Shashank_Jain 

there is a standard process based on which system checks which inbound action to process

Inbound email action processing 

If my response helped please mark it correct along with other ones from my response so that it benefits future readers.

[Ankur Bawiskar]

@Shashank_Jain 

it means something is blocking the access and hence cannot update.

the user who is replying has READ and WRITE Access to that table record?

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Shashank_Jain · Accepted solution]

Thank you for the responses, @Ankur Bawiskar  — they were really helpful.

One of the issues I was facing was understanding why the inbound action was not running. I tried adding logs, and after some investigation, I realized that the inbound action was indeed running, but it was within a scoped application. Because of this, the logs were not being printed with gs.log().

I updated the script to use logger.log(), and the logs started printing correctly. Initially, I was confused and thought it might be an issue with cross-scope privileges, but it turned out not to be the case.