Email flow designer & Inbound Action processing

[ashwanikumar]

Hi All,

I have some queries related to inbound actions & email flow designers:

1. What run first inboun actions or flow designers?

2. If 'Stop Processing' is true, will email flow designers still run?

3. Is it possible to add order in email flow designer?

e.g. run in following sequence: email inbound action1 > email flow designer1 > email inbound action2 > email flow designer2

Thanks,

KUMAR

[alexcorvino]

1. Flows will be evaluated for execution first, then inbound actions if no flows were executed or if the flow didn't issue a stop processing.
2. Stop processing means that if the flow executes then stop processing all other inbound email flows for that email and don't process any inbound actions for that email.
3. Yes, but not the way you've described. Turn on the advanced options and you'll get the order field. Your example can't happen though, the flows are all evaluated before any inbound actions are. It would go in the order: email flow 1 -> email flow 2 -> email action 1 -> email action 2. Also keep in mind that if flow 2 issued a stop processing then none of the actions would run. If flow 1 issued a stop processing then neither flow 2 or any of the actions would run.

Thanks,

Al

[apjohn2]

Hello @alexcorvino . I've been experimenting with this very thing tonight and in my instances it seems that execution of Flow Designer activities does not prevent Inbound Email Actions from running. I am curious if you can recommend something to ensure that once the Flow has executed that Inbound Email Actions for the record in question do not get processed?

My scenario involves 2 Flows, Flow #1 and Flow #2, and plays out as such:

1. Email received with subject "x y z" where x, y and z are specific values from an external, automated source (basically a sort of "System y is down" message)
2. The email triggers the create-incident Inbound Email Action and opens an incident (expected and desirable at this stage)
3. Flow #1 is triggered by the newly created Incident, where Short Description and Caller match given conditions, and then sets specific fields as needed for later processing
4. Email received with subject "x y r" where x and y are the same specific values mentioned above, but r indicates the system is back up (basically a sort of "System y is up" message)
5. Flow #2 is triggered by the this email, performs a "Look Up Incident Record" action based on Subject, then an "Update Incident Record" which resolves the Incident opened above

According to your description of execution order, it doesn't seem that the 2nd email should trigger the create-incident Inbound Email Action that opens an Incident, since Flow #2 has executed on the inbound email record (sys_email table).

The 2nd email does in fact trigger the create-incident Inbound Email Action, however, and this is not what we want to happen. In fact this particular email should never cause an Incident to be created, whether it meets the given criteria to cause the original system-down Incident to be resolved or not. (If it doesn't resolve the Incident, the Incident will be escalated, so to speak, via Flow #1).

Do you have any advice on this? I'm sure I could add a new condition in our generic create-Incident Inbound Email Action which ignores these emails, but I'm not sure that's the best course for maintainability and scalability considerations.

I'm happy to share any more details as needed if it will help. Thank you in advance!

Truly yours,

-Aaron

[alexcorvino]

If I'm reading this scenario right it's:

1. First new email comes in

2. First new email doesn't trigger any flows so execution falls through to inbound actions where Create new incident is run

3. Second new email comes in

4. Second new email triggers a flow

5. Execution of second new email still goes through to inbound actions where Create new incident is run

If this is the case then execution should stop at step 4 if the flow has the stop processing flag set to true, which is what it is set to in the UI by default. This flag doesn't show in the UI without the glide property glide.hub.flow.inbound_email_trigger.show_advanced set to true. I'd start by enabling that flag and make sure that stop processing is checked. If it's not then check the checkbox, save and republish the flow and you should be set. If it is, then I'd advise looking at custom scripts and business rules to see if there's something there that's doing something that's unexpected.

Thanks,

Al