SNOW CSM Multiple inbox challange

[D Trivedi]

Currently there are multiple mailboxes are receiving emails from the clients for different purpose and getting forwarded to SNOW for case creation creating difficult challenges

Current Challenges

The existing RPA-driven process is complex, difficult to maintain, and prone to ticket misrouting.
Duplicate tickets are often created when retailers do not reference existing case numbers.
Spam and irrelevant emails can enter the process and generate unnecessary tickets.

I want to achieve solution

ServiceNow-first approach using Flow Designer for email ingestion, filtering, routing, and ticket creation.
Utilise a central Customer Care mailbox as the primary intake channel.
Automatically populate ticket fields and transfer email attachments into ServiceNow.
Implement controls to minimise spam, duplicate tickets, and invalid requests.

In your opinion, what will be the best approach here?

Thank you

[Abhishek Pal]

Hi @D Trivedi ,

I would definitely move away from the RPA-based approach and make ServiceNow the actual email intake/routing layer.

For CSM, there are two OOB designs available:

Option 1:
Email -> Case

Option 2:
Email -> Interaction -> Case only when required

Considering your current problems with duplicate tickets, spam and incorrect routing, I would recommend Option 2 if your CSM licensing/application setup supports Email Interaction.

Recommended architecture:

Customer Email
-> ServiceNow Email Account
-> Email Filters
-> Inbound Email Flow
-> Email Interaction
-> Routing / validation
-> Agent review
-> Create Case only when investigation is required

Why I prefer this approach:

Every incoming email does not automatically need to become a Case.

With Email Interaction, ServiceNow creates an Interaction first. The agent can:

- Respond directly
- Resolve simple requests
- Route the interaction
- Create a Case only when further investigation is required

This significantly reduces unnecessary Case creation.

1. Remove the RPA forwarding layer

CSM supports multiple incoming email addresses OOB.

Navigate through the CSM Email Channel configuration and configure the required incoming email accounts.

You can have:

orders@company.com
returns@company.com
support@company.com
retailers@company.com

ServiceNow can maintain multiple incoming addresses and associate them with specific products/channels.

Therefore, technically you do not need to force everything through one Customer Care mailbox.

If the business still wants:

customercare@company.com

as the public-facing address, that is also fine, but I would keep routing logic inside ServiceNow rather than in RPA.

2. Use Inbound Email Flows rather than custom Inbound Actions

For new implementations I would use:

Workflow Studio / Flow Designer
-> Inbound Email Trigger

ServiceNow CSM supports inbound email flows specifically for creating and routing Cases/Interactions.

Inbound Email Flows also take precedence over Inbound Email Actions, so avoid having both processing the same email unless there is a deliberate design.

3. Filter unwanted email BEFORE creating a Case

Configure:

System Mailboxes
-> Administration
-> Filters

ServiceNow provides Email Filters for:

- Spam
- Ignored subjects
- Ignored headers
- Calendar messages
- Junk email

You can also create custom filters.

For example:

Sender is known automated/no-reply address
-> Ignore

Subject contains known irrelevant pattern
-> Ignore

Spam header detected
-> Move to Junk

This ensures unwanted email does not reach your Case creation logic.

4. Duplicate Case handling

I would not create a duplicate Case only because the sender did not include the existing Case number.

First handle normal replies using ServiceNow's email threading/reference information.

For emails where no Case reference can be identified, avoid automatically merging records based only on the subject because:

"Order issue"

could genuinely represent two different requests.

If you use Email Interaction, this problem becomes easier:

New email
-> Interaction
-> Agent determines whether this belongs to an existing Case
-> Link existing Case OR create new Case

Current CSM Email Interaction also maintains email conversation context and can associate subsequent communication with the related Case/Interaction.

If the business insists on automatic Email-to-Case, add a controlled duplicate check before creation.

For example:

Look for OPEN Case where:

Contact = email sender
AND
Product = identified product
AND
Normalized subject is similar/equal
AND
Created within a defined business time window

If exactly one strong match exists:

-> Update/link existing Case

Otherwise:

-> Create new Case

Do not automatically merge when multiple possible Cases are found.

5. Auto-populate Case information

Create routing/mapping logic based on:

Incoming mailbox
Sender
Contact
Account
Subject
Email body
Product
Retailer
Keywords

Then use CSM Flow Designer actions such as:

Create Case
Assign Case
Update Case

Example:

returns@company.com
-> Product = Returns
-> Category = Return Request
-> Assignment Group = Returns Support

orders@company.com
-> Product = Orders
-> Category = Order Issue
-> Assignment Group = Order Support

If you use one central mailbox, derive those values from the email content or another reliable business identifier.

Where possible, using separate incoming email addresses is usually cleaner than trying to infer everything from free-text email content.

6. Attachments

Inbound email attachments should also be considered part of the process.

If you build a custom Flow and need to explicitly move attachments from the inbound Email record to the target Case, ServiceNow provides the OOB:

Copy Attachment

Flow Designer action.

For multiple attachments:

Look up attachments
-> For Each
-> Copy Attachment
-> Target = Case

Avoid custom GlideSysAttachment scripting unless the OOB action cannot satisfy the requirement.

7. Routing

Once the Case/Interaction is created, use CSM routing rather than maintaining routing logic inside the email-processing script.

For example:

Email
-> Interaction/Case
-> Product/Category populated
-> Assignment logic
-> AWA / appropriate support queue

This keeps email ingestion separate from assignment.

8. Recommended production design

I would implement:

Multiple legacy customer mailboxes
|
v
ServiceNow Email Accounts
|
v
Email Filters
Spam / ignored / automated messages
|
v
Inbound Email Flow
|
v
Identify Contact + Account + Product
|
v
Email Interaction
|
+---- Existing Case identified
| -> Link/update Case
|
+---- Simple query
| -> Agent responds and closes Interaction
|
+---- Investigation required
-> Create Case
-> Populate required fields
-> Route to correct group
-> Copy attachments

This gives you:

- No RPA dependency
- Centralized email processing
- Better routing
- Fewer duplicate Cases
- Spam filtering
- Attachment handling
- Better email conversation tracking
- Easier support/maintenance
- More OOB CSM functionality

If every customer email is contractually required to create a Case, then use the OOB Email-to-Case capability instead.

But if your primary issue is that too many unnecessary/duplicate Cases are currently being generated, I would strongly evaluate:

Email Interaction
-> Case only when required

rather than:

Every Email
-> Case

Official ServiceNow references:

Email Channel:
https://www.servicenow.com/docs/r/customer-service-management/c_CustomerServiceEmailCommunication.ht...

Email to Case:
https://www.servicenow.com/docs/r/customer-service-management/email-to-case.html

Email Interaction for CSM:
https://www.servicenow.com/docs/r/customer-service-management/using-email-interaction-customer-servi...

Configure CSM Inbound Email Flows:
https://www.servicenow.com/docs/r/customer-service-management/creating-flows-incoming-emails-create-...

Email Filters:
https://www.servicenow.com/docs/r/platform-administration/c_EmailFilters.html

Copy Attachment Flow Action:
https://www.servicenow.com/docs/r/build-workflows/workflow-studio/copy-attachment-flow-designer.html

CSM Flow Designer Actions:
https://www.servicenow.com/docs/r/customer-service-management/csm-flow-designer-actions.html

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal

[D Trivedi]

Thank you sir. My biggest problem is adding additional resource to monitor the interactions, and then same people will have to work on the cases. 

Current process entails; Organization is using keyword mapping from the MS Power App and they want to move away from that and instead create and assign cases to specific Assignment groups based on type(there are closer to 100s). How to accommodate this? We cannot send certain contractors to use portal so email case creation has to run

[Abhishek Pal · Accepted solution]

Hi @D Trivedi ,

Thanks, that additional context changes my recommendation.

If introducing Email Interactions means the same team has to monitor another queue before working the actual Cases, then I would not add that extra layer.

In your situation I would use:

Email
to
Email Filters
to
Inbound Email Flow
to
Create Case
to
Determine Case Type
to
Decision Table
to
Assignment Group

This keeps email as the intake channel for the contractors while still removing the current Power App/RPA dependency.

The important part is to separate Case creation, classification, and assignment.

1. Create the Case directly from email

Use the CSM inbound email flow:

Create Case from Email

The inbound email flow should primarily:

Identify the sender/contact/account where possible

Populate description and email information

Create the Case

Copy/process attachments as required

Do not put 100 routing conditions directly inside this flow.

1. Create a Case Type field if you do not already have one

For example:

Type = Order Issue

Type = Returns

Type = Invoice Query

Type = Delivery Issue

Type = Contract Issue

etc.

If you have close to 100 business types, that is fine.

The important design is that Type should represent what the Case is about, while Assignment Group represents who currently owns it.

Do not combine those two concepts.

1. Use a Decision Table for Type to Assignment Group mapping

This is where I would replace the Power App keyword-routing logic.

Create a Decision Table such as:

CSM Case Routing

Inputs:

Case Type

Optionally:

Product

Account

Region

Country

Customer type

Priority

Outputs:

Assignment Group

Example:

Type = Return Request
Output = Returns Support

Type = Invoice Query
Output = Billing Support

Type = Delivery Issue
Output = Logistics Support

Type = Contract Query
Output = Contract Management

Then your flow becomes very simple:

Create Case

Determine Type

Make a Decision

Decision Table = CSM Case Routing

Set:

Case.Assignment Group = Decision Table result

This is much better than having 100 IF/ELSE branches or 100 separate inbound email flows.

If tomorrow Type 42 needs to move from Group A to Group B, you update one Decision Table row instead of modifying the Flow.

1. The key question is how you determine the Type

This is the part I would clarify with the business.

If the incoming email already contains a reliable structured identifier such as:

A specific mailbox

A subject code

Product

Customer/account

Request code

Contractor type

or another consistent field

then use that value to populate Case Type.

For example:

Subject contains:

TYPE: RETURN

Then:

Case Type = Return Request

However, if the business wants ServiceNow to understand approximately 100 different request types from completely free-text emails, then replacing keyword mapping requires a classification capability.

You cannot completely remove classification logic and still expect the platform to know which of 100 Types an unstructured email belongs to.

There are two realistic approaches.

Option A - Deterministic classification

Use reliable business data such as:

Incoming mailbox

Sender/domain

Account

Product

Subject prefix/code

Structured email template

Then determine the Type.

This is the simplest and most predictable option.

Option B - Predictive Intelligence

If your licensing and implementation support Predictive Intelligence, you can train a Classification Solution using historical Cases.

For example:

Inputs:

Short description

Description

Email content

Prediction:

Case Type

The model can learn from previously categorized Cases and predict the Type for a newly created Case.

Then:

Email
to
Case
to
Predict Type
to
Decision Table
to
Assignment Group

This would be the approach I would evaluate if the organization specifically wants to move away from maintaining a large keyword library.

I would still define a confidence/fallback path.

For example:

Prediction is confident
-> Set Type
-> Decision Table
-> Assignment Group

Prediction is uncertain
-> Route to a General Triage group

Do not automatically force a low-confidence prediction into one of the 100 support groups.

1. Keep Assignment Group logic separate

Even if you use Predictive Intelligence to identify the Type, I would not necessarily train the model to directly predict Assignment Group.

I prefer:

Email text
-> Predict Type
-> Decision Table
-> Assignment Group

because Type is a business classification.

Assignment Group is an operational configuration and may change frequently.

For example:

Today:

Invoice Query
-> Billing Support

Tomorrow:

Invoice Query
-> Finance Operations

You should be able to change that mapping without retraining the classification model.

1. You do not need 100 mailboxes

You can still keep a central address such as:

customercare@company.com

The architecture can be:

Contractor
-> customercare@company.com
-> ServiceNow
-> Create Case
-> Determine Type
-> Decision Table
-> Assignment Group

If some existing mailboxes already provide reliable business context, you can keep them and use the receiving address as another classification input.

I would not create 100 different email addresses just to represent 100 Types.

1. Keep spam and duplicate controls before/around Case creation

I would still retain the controls from my earlier recommendation.

Email Filters
-> Reject/ignore spam and irrelevant email

Email threading/reference
-> Update an existing Case when ServiceNow can identify the existing conversation

New legitimate request
-> Create Case

This prevents the routing redesign from recreating the duplicate/spam problem you are trying to solve.

1. Recommended architecture for your requirement

I would implement:

Contractor Email
to
ServiceNow Email Account
to
Email Filters
to
Inbound Email Flow
to
Create Case
to
Identify Contact/Account
to
Determine Case Type
to
Decision Table
to
Set Assignment Group
to
Optional AWA for agent-level assignment

If Type cannot be reliably derived from structured information:

Contractor Email
to
Create Case
to
Predictive Intelligence Classification
to
Predicted Type
to
Decision Table
to
Assignment Group

with a General Triage group as the fallback for low-confidence/unclassified emails.

This gives you:

Direct Email-to-Case

No additional Interaction monitoring team

No dependency on the current Power App/RPA routing layer

No 100-condition Flow

Centralized and maintainable routing

Clear separation between business Type and Assignment Group

Ability to change routing without changing the email-ingestion Flow

Optional AI/ML classification if free-text classification is required

Optional AWA later if you need intelligent agent-level assignment within the selected group

One important point:

Before selecting Decision Table only versus Predictive Intelligence plus Decision Table, I would ask the business one question:

"Where does the Type come from today?"

If there is already a reliable Type/code in the incoming email, use it directly and a Decision Table is enough.

If Type is currently determined only by reading free-text email keywords, then some form of classification is still required. In that case, Predictive Intelligence is worth evaluating rather than rebuilding another large keyword engine.

Official ServiceNow references:

ServiceNow Documentation - Email to Case
https://www.servicenow.com/docs/r/customer-service-management/email-to-case.html

ServiceNow Documentation - Define rules to process incoming emails
https://www.servicenow.com/docs/r/customer-service-management/define-process-incoming-emails.html

ServiceNow Documentation - Configure process rules for incoming emails
https://www.servicenow.com/docs/r/customer-service-management/create-rules-incoming-emails-create-as...

ServiceNow Documentation - Decision Tables
https://www.servicenow.com/docs/r/build-workflows/workflow-studio/decision-designer-overview.html

ServiceNow Documentation - Predictive Intelligence Frameworks
https://www.servicenow.com/docs/r/intelligent-experiences/predictive-intelligence/predictive-intelli...

ServiceNow Documentation - CSM Case Routing and Assignment
https://www.servicenow.com/docs/r/customer-service-management/case-routing-and-asign.html

Hope this helps!

If this response helped, please mark it as Helpful. If it resolves your question, please Accept it as Solution so it can help others with the same requirement.

Kind Regards,
Abhishek Pal

[D Trivedi]

Thank you, it makes sense and i loved the respone. I will propose to my client and let them make the decision.