Email to ticket creation - Issue with Email account

SivaPrasadR3900
Mega Contributor
 
We have a new requirement to automate incident creation from emails. Currently, when users face an issue, they send an email to the Service Desk mailbox, and the Service Desk team manually creates an incident based on the email. To automate this process, I have developed an Inbound Email Action.

In the Dev environment, I configured a test service account (user mailbox), and the solution is working as expected. However, in Production, the existing Service Desk email account is a shared mailbox.

I also discussed this with the O365 team, and they confirmed that user mailboxes have credentials available for authentication, whereas shared mailboxes do not have their own credentials.

My question is: how should emails from the shared mailbox be routed to ServiceNow? Would it be appropriate to configure a forwarding rule from the shared mailbox to another user mailbox that ServiceNow can monitor, or is there a better/recommended approach for Production? Please suggest the best solution.

1 ACCEPTED SOLUTION

vaishali231
Kilo Sage

Hey @SivaPrasadR3900 

In this scenario, I would not recommend configuring ServiceNow to directly authenticate against the Microsoft 365 shared mailbox, especially if the O365 team has confirmed that the shared mailbox does not have its own credentials.

A better approach would be to create a dedicated mailbox/service account for the ServiceNow email integration.

The recommended flow would be:

User

 ↓

Service Desk Shared Mailbox

 ↓

O365 Mail Flow / Forwarding Rule

 ↓

Dedicated ServiceNow Integration Mailbox

 ↓

ServiceNow Inbound Email

 ↓

Inbound Email Action

 ↓

Create Incident

The O365 team can configure a controlled forwarding or mail-flow rule from the shared Service Desk mailbox to the dedicated ServiceNow mailbox.

I would also recommend validating that the original sender information is preserved during forwarding. This is important because the Inbound Email Action should identify the actual employee who reported the issue and populate that user as the Incident Caller, rather than using the shared mailbox or integration mailbox as the caller.

For authentication, I would use the authentication mechanism approved by the O365/security team, preferably a supported modern authentication/OAuth approach rather than maintaining a password-based shared mailbox integration.

So, in my opinion, shared mailbox → dedicated ServiceNow integration mailbox → Inbound Email Action is a cleaner and more supportable production design than trying to authenticate directly against the shared mailbox.

Also, before moving to Production, I would test sender preservation, attachments, email threading, duplicate email handling, and failure/retry scenarios

 

**********************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb





View solution in original post

2 REPLIES 2

vaishali231
Kilo Sage

Hey @SivaPrasadR3900 

In this scenario, I would not recommend configuring ServiceNow to directly authenticate against the Microsoft 365 shared mailbox, especially if the O365 team has confirmed that the shared mailbox does not have its own credentials.

A better approach would be to create a dedicated mailbox/service account for the ServiceNow email integration.

The recommended flow would be:

User

 ↓

Service Desk Shared Mailbox

 ↓

O365 Mail Flow / Forwarding Rule

 ↓

Dedicated ServiceNow Integration Mailbox

 ↓

ServiceNow Inbound Email

 ↓

Inbound Email Action

 ↓

Create Incident

The O365 team can configure a controlled forwarding or mail-flow rule from the shared Service Desk mailbox to the dedicated ServiceNow mailbox.

I would also recommend validating that the original sender information is preserved during forwarding. This is important because the Inbound Email Action should identify the actual employee who reported the issue and populate that user as the Incident Caller, rather than using the shared mailbox or integration mailbox as the caller.

For authentication, I would use the authentication mechanism approved by the O365/security team, preferably a supported modern authentication/OAuth approach rather than maintaining a password-based shared mailbox integration.

So, in my opinion, shared mailbox → dedicated ServiceNow integration mailbox → Inbound Email Action is a cleaner and more supportable production design than trying to authenticate directly against the shared mailbox.

Also, before moving to Production, I would test sender preservation, attachments, email threading, duplicate email handling, and failure/retry scenarios

 

**********************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb





Hemanth M
Tera Sage

Hi @SivaPrasadR3900 ,

 

It's tricky to configure email forwarding on the shared mail box using specific conditions - there could emails where we don't necessarily need to create an incident,

May i know

1)how end users find the ServiceDesk  email today? -

2)is it feasible to haven users send emails directly to the Production email account instead of the mailbox?

3)We can also do- ServiceDesk monitor the shared mailbox - forward necessary emails to the ServiceNow email address directly.

 

Hope this helps!

 

Accept and hit Helpful if it helps.

Thank you,
Hemanth
Certified Technical Architect (CTA), ServiceNow MVP 2024, 2025,2026