Forum Discussion
Update list when Send email with options sends successfully
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.
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.
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?
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.
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!
- 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?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.
