Wednesday, June 28, 2017

Email Approval Considerations

Recently wrote a service for handling lazy approvals.  IE someone gets an email that they can reply to with an "approved" or "rejected" response and the system uses that to continue its workflow/process.

I can't share the code for it but wanted to overview some of the challenges/considerations I ran into in case anyone is looking to write their own.

1.  Validation:  I originally added a custom MessageId into the emails that I logged along with the recipient address so I could validate an email response was "valid".  However, replying to a message generates a new MessageId and the original wasn't available to me in the 3rd party IMAP library I used.

2. Parsing:  When trying to determine what request the email approval was in reference to there is parsing involved.  This can get tricky if the email has been forwarded, replied to several times, or the subject altered.  I found in one case when testing a peer replied and their web-based email client put some unexpected formatting into the message.  A good solution is to use TDD (test driven design) and build some good tests to validate these scenarios as they arise.

3. Responses: To allow for some flexibility I had to create a dictionary of words/phrases that tied back to the response I was expecting.  IE "approved" would be considered approved if the response was "yes" or "affirmative".

4. Approval process workflow:  What happens when you reply approved but quickly change your mind and reply rejected?  Does the last response become valid?  Is the 1st response valid?  If the response is invalid do you allow users to reply until a valid response is given?