Update list when Send email with options sends successfully

[Jason Barnes]

From the docs, the "Send email with options" action sends an email with multiple options and waits for the recipient to respond back with one of the options. I'm trying to log the sending action by updating a Yes/No column and setting a date column with a timestamp.

Something like this:

- Trigger: new item created

- Email sends

- list updates item that was created, sets "email sent" flag to Yes, sets timestamp.

- Recipient responds, capture response and update list

Unfortunately the action waits until the response, so I cannot log when the email was actually sent. I don't want to do the update before the message is sent, because I want to make sure the send action is successful. But I don't want to wait until after the recipient of the message responds, because it's not accurate.

Any suggestions?

[#2]

Hi @Jason Barnes  you could consider a parallel action which runs at the same time as the send email (see screenshot). So run the first update to the list item which runs concurrently with the sending of the email, and then update based on the response once the email button is clicked by the user.

[#3]

What if you used a proxy timestamp instead? If you're willing to sacrifice up to a couple seconds, you can use the Current Time action immediately after your Send Email with Options action is completed and use that to populate your "Email Sent" field in your List.

*Possibly dumb question, are you trying to log the time the email was sent, or the time that the recipient of the Send Email with Options email responds?

[#4]

The problem with that approach is it doesn't actually tell me if the email was successfully sent. It only tells me when the flow ran. So one branch, the update, could be successful, but the other branch, which sends the email, might not be successful.

[#5]

I'm actually trying to log when the email was sent AND when the recipient response. I'd like to have a view where it shows all the info - email sent (yes/no), email sent date, response (a, b, or c), response date.

In theory I could set a variable when the send email runs and update the list after the response using that variable, but it doesn't give the visibility I'm after to know which items have had an email sent but not responded to. Hopefully that makes sense and adds some clarity.

[#6]

You could always work on the assumption that it fails, and handle the error of the email being sent accordingly (See screenshot). If the email is going to fail to send, you'll get the failure almost immediately and so you can a further update to either log the error in the list or remove the sent date. This would be your "has failed" step, whereas the "is successful" will continue to wait until the response comes back.

It's not quite the nice and shiny solution which you're looking for but it should do the job.

[#7]

You could always work on the assumption that it fails, and handle the error of the email being sent accordingly (See screenshot). If the email is going to fail to send, you'll get the failure almost immediately and so you can a further update to either log the error in the list or remove the sent date. This would be your "has failed" step, whereas the "is successful" will continue to wait until the response comes back.

It's not quite the nice and shiny solution which you're looking for but it should do the job.

[#8]

I think if I combine your 2 suggestions I can get what I want. If I update the "Email Sent" flag and set a timestamp parallel to (or prior to) the send email with options, I assume it will send successfully and it logs the info accordingly. Then on fail I can update "Email Sent" to No and clear out "Email Sent Date". That would let me run a recurrence and I could re-try those fails automatically by querying the list for any items where "Email Sent" equals "No". 

Do you see any problems with that approach or any gotchas I might be missing or failing to consider?

[#9]

Recognizing that I'm only just now realizing that the "wait" you mentioned is buried in the "Send Email with Options" step, your plan makes sense. I don't know of a benefit to having the timestamp step being parallel (I'm assuming Prior To gets you the same result), and it sounds like you've covered your bases in case of a failure by making a branch to clear out the timestamp and Email Sent status.

In what scenario might sending the email fail? Is that just the assumption that something, someday, always goes wrong, or is there something about your process that leaves open the possibility of an address being invalid or unavailable?

[#10]

As @Matt Coats correct says, you don't necessarily need to run the parallel step if you're going to handle the error in the way we have discussed. Realistically there are only a couple of scenarios which I can think of off the top of my head which would result in failure:

• Invalid/missing email address
• Invalid/broken connection associated with the action

To pick up any that have failed you could either created a scheduled Flow, or you could consider starting the Flow directly from the list item itself. There are a number of options available to you depending on how you would like handle the errors.

[#11]

From my perspective, yes - someday it'll go wrong. But it's more for providing better data for the customer. When the customer looks at the list, they can see did the email send, when did it send, did the recipient responded, when did the recipient respond. The customer can start to get a feel for response times, and they have something that confirms the email actually sent without having to look into the flow logs.

[#12]

Failures - Once or twice I've had it where the connection, ie. my credentials, "expired" (or something) and had to be refreshed, but you're right, it's not a common thing. I will probably look at a scheduled flow to capture any that are missed, and perhaps send myself a summary for review so I can see why things didn't work the first time.

Thank you and thankyou to @Matt Coats for your help with this!