Flow logic for email replies - ideas and discussion

[Maks]

We have one flow for processing (a) new/forwarded emails, and (b) for processing reply emails.

(a) is pretty straightforward - create a task, prepopulate some fields, and assign it to the right team.

(b) is more subject to opinion. This is the one I want to focus this discussion on.

Here's what we do at our company, let me know if you do things differently at yours:

(1) The easiest one - the incident is still open (but not resolved). In this case we just add an additional comment so that the fulfiller knows that there is an update from the user.

(2) The incident is resolved. Here, we do the same as in (1) - we add the additional comment and notify the assigned to person. But the difference is - if the subject of the email contains "please reopen" we will change the state back to "in progress". We have a button on the email template that prepopulates the subject to "please reopen" when they're not satisfied with the resolution provided.

(3) And finally, the incident is closed or cancelled. At our company, we don't reopen cases. We create a new incident and assign it to the same team that was dealing with the original one. But first we check if an active incident already exists for this conversation.

Question: Do you do things differently at your place? What are your tips?

Question: How do you treat replies from people who are CC'ed on the email but are not the caller on the incident? Do you add them to the watchlist on the incident? Do you let the system notify the caller again of these replies? (which could mean they will receive the same update twice)

Question: Do you have subflows that help you reuse some of the logic across the flow? For example, we have a "create incident generic" subflow that creates a generic incident and then we assign it to the correct team, but the problem with this is that it increases the reassignment_count on the incident record...

[Mark Manders]

- If the incident is closed, we trigger an event that sends out an email to let the sender know that the ticket is already closed and that they should create a new one. Replies to the current ticket/email won't result in updating the existing ticket.

- replies from cc's shouldn't be able to update existing incidents, unless they are ITIL users. Only the caller/opened by and watchlist have access to the ticket. So if you cc anyone, those should be added to the watchlist when sending, to ensure their replies are added as well. (at our company the watchlist is updated with the people the email is send to, if they have an existing user record). We are only sending our updates to the customer, not those from the email (external).

- If you are using the subflow in multiple flows, it makes sense. If not, just use the 'create record' action. You can only prevent reassigning if you have a way of knowing the correct assignment (assignment rules could help). If you assign through the flow, you can add the logic there, but if it is not known upfront, you will always have an extra assignment step to do yourself. Technology can't resolve things we don't know.