Recommended Approach for Email Classification Using Multiple Inbound Email Trigger Flows

[ShumaS]

Hello Community,

I would like to get feedback on the architecture of an inbound email processing solution.

## Background

We receive various types of emails that must be processed differently based on conditions such as sender, subject, and email content.

In addition, any email that does not explicitly match a defined processing rule should ultimately be classified as Junk.

## Proposed Architecture

I am considering implementing this using multiple Inbound Email Trigger Flows.

The system property `glide.hub.flow.inbound_email_trigger.show_advanced` would be enabled so that multiple flows can be configured and ordered.

### Processing Flow

1. An initial flow (Order = 0) receives the email and leaves it in the Inbox state.
2. Multiple business-specific flows (Order > 0) evaluate the email and perform their respective processing.
3. When a flow successfully processes the email, it updates the email status to `Received`.
4. A final flow (Order = 9999) evaluates the email:
- If the status is `Received`, no further action is taken.
- If the status is not `Received`, the email is classified as Junk.

### Goals

- Separate processing logic into independent flows.
- Simplify future maintenance and addition of new email-processing rules.
- Ensure that any email not matched by a processing rule is automatically treated as Junk.

## Questions

### 1. Is this architecture reasonable?

Has anyone implemented a similar pattern using multiple Inbound Email Trigger Flows?

In particular, are there any concerns with:

- Using the Order field to control processing sequence across multiple flows?
- Using the email status as a flag to indicate whether an email has already been processed?

### 2. Inbound Email Trigger Flow vs. Inbound Email Action

For this type of requirement, would you recommend:

- Inbound Email Trigger Flows
- Inbound Email Actions

I would appreciate recommendations from the perspectives of:

- Maintainability
- Scalability
- Processing order control
- Performance
- ServiceNow best practices

### 3. Status Update Visibility Across Flows

If multiple Inbound Email Trigger Flows are executed for the same email, can a later flow reliably determine whether an earlier flow has changed the email status (for example, to `Received`)?

Are there any transaction, execution-order, or timing considerations that could affect this design?

Any guidance, best practices, or alternative approaches would be greatly appreciated.

Thank you.

[Tarun Rekandar]

Hi @ShumaS ,

Thank you for explaining your perspective. I agree that separating business logic into independent flows offers better isolation of changes and allows each flow to be developed and tested independently.

My recommendation of a dispatcher pattern was mainly based on centralized routing and avoiding dependencies between flows through shared email status. However, I agree that it is not necessarily better than separate flows in every situation.

Your proposed approach of separate Inbound Email Trigger Flows followed by a catch-all flow is also worth considering, provided the platform's execution behavior supports it.

The key consideration is not simply maintainability, but ensuring that the catch-all flow runs only after the relevant processing rules have been evaluated and that an email is not incorrectly classified as Junk.

Before adopting this design, I would verify the following in the target ServiceNow release:

• Trigger evaluation: Whether multiple matching Inbound Email Trigger Flows execute independently or whether the platform stops or changes processing after a particular flow handles the email.

• Execution order: Whether the Order field guarantees the required sequence for these flows.

• State visibility: Whether updates made by one flow are reliably visible to subsequent flows during the same inbound email processing transaction.

• Failure handling: How the design behaves if a business-specific flow fails or does not complete successfully.

If these behaviors are confirmed through testing, separate flows with a catch-all may be a reasonable choice for your requirement. I would also recommend testing unmatched emails, multiple matching rules, and processing failures before implementing it in production.

Ultimately, I see the dispatcher pattern as one option rather than a universal best practice. Your preference for modularity is valid, and the final choice should depend on the verified platform behavior and the level of isolation your solution requires.

Thank you for the thoughtful discussion, Accept the solution if it assisted you with your question & Mark this response as Helpful.

Regards,
Tarun