Understanding when OOB actions fires for Email's received and when/how inbound Flows execute

[EricG2]

is anyone else getting frustrated with Inbound Emails flows not executing consistently?

I've posted a couple of posts regarding using alias emails to find the SNOW user if the OOB Action fails.

Business Case:

Do to our domain separated environment, We have switched our user import from ActiveDirectory to a feed from HR.

(this was to remove duplicate user records being created.  E.G. IT users have user records in all domains, but work under only one).

How some users work in our environment:

Many users in our company have be converted from the lower companies and moved to our Parent one.

However, there are several users that use their Child credentials in business instead of their parent ones.

This is causing their emails being received to process as guest or approvals not updating.

From posts i've found, I've create an Inbound flow that checks if the sys_email record has a blank entry in the user_id field or comes from known email addess' (email user field, not user_id).  I'm calling it "2nd email process for Alias"

while I can "Test" my inbound email flow and get the desired results, when I try reprocessing the actual email record - the "2nd email process for Alias" flow is not being triggered.  I am able to use the email log message to determine which inbound flows are being skipped.  So from that, the alias inbound can't be found.

I've asked HI to explain how emails are handled and why this isn't being associated.  I've found no help.

I did get some insight that by adding the glide.hub.flow.inbound_email_trigger.show_advanced i can get additional properties.  These properties include Order (so i can set to lower number like inbound actions) and Stop processing check box (if unchecked, the system will continue processing others).

has anyone been able to successfully use Alias email to process inbound email, so that if the user table has a different email, we can use the "alias table" to update the email record and process it so that the appropriate user is assign to tickets.

Here is what my inbound trigger looks like

[vinay167]

Yes, dealing with Inbound Email Flows in ServiceNow, especially in a domain-separated environment, can be frustrating when they don't execute consistently. From what you've described, it sounds like your "2nd email process for Alias" is not triggering as expected when reprocessing actual email records, even though it works fine in the Test Mode.

Possible Issues & Solutions

1. Inbound Email Flow Execution Order

• Check if your "2nd email process for Alias" flow is being bypassed due to execution order.
• Try setting the Order of your inbound flow lower than the default inbound actions to ensure it executes earlier.
• The property glide.hub.flow.inbound_email_trigger.show_advanced gives more control over Order and Stop Processing settings, which might help in prioritizing your alias handling flow.

2. Stop Processing Issue

• If another inbound flow processes the email first and stops further execution, your alias flow may not run.
• Ensure the "Stop Processing" checkbox is unchecked in other inbound flows that might be processing before yours.

3. sys_email Processing Behavior

• When reprocessing an existing email record, ServiceNow does not trigger inbound flows again.
• Workaround: You might need to manually re-trigger your alias email process by:
  • Copying the email content into a new inbound email record (sys_email table).
  • Marking the new record as received so it gets processed again.

4. User Identification Issue

• Since your environment uses an HR-based user feed instead of Active Directory, users with child company email addresses might not be correctly associated.
• Consider creating an Alias Table that maps:
  • Alias email (child domain) → Primary email (parent domain)
  • Then, modify your inbound email flow to check this alias table when the user_id is blank.

5. Debugging & Logging

• Enable system logs (syslog) to see if your alias inbound email flow is being picked up at all.
• Check Email Processing Logs (sys_email_log) to verify which flows are executing.

Alternative Solution: Use Business Rules Instead of Flow Designer

If Flow Designer is inconsistent, you can try Business Rules on the sys_email table:

• Before Insert BR: Look for an alias match and update the user_id field.