Every morning, sitting in my Outlook inbox, is a daily health check from REDCap, taunting me to fill it out. Even though it only takes less than 10 seconds to fill it out, performing a menial task like this daily turns out to be a drag sometimes, especially if I'm submitting the same information every single time. Coincidentally, I came across this quote the other day:
"You're either the one that creates the automation, or you're getting automated"
And that's when I told myself, I don't want to be the latter anymore.
What it does
The bot monitors a dedicated email inbox, filled with daily health check requests from multiple users, and fills out each one accordingly. The user forwards their daily health checks emails to the email of the bot, with the following neccesary components in the email:
- REDCap Link
- Schedule (what days is the user on/not on campus)
The link and schedule is scraped from the email body, and the bot will fill out the form, based on the given schedule and today's date. Once the bot fills out the daily health check form, it will send a confirmation email as a reply to the forwarded email from the user.
How I built it
First step in the project is to grab the user's Outlook health check emails. Microsoft Power Automate allows me to create an automation to auto-forward all new health check emails to the bot's email inbox.
Next, I created a webhook using Integromat to detect when a new email shows in the bot's email inbox. Given the email is a health check email, the webhook will send the contents of the email's body to a scraping function for the link to the form and the schedule of the user.
Once these two criticial pieces of information are gathered, they will be sent to a function to fill out the form and submit it through a POST request.
If a 200 status code is returned, then a reply email is sent back to the user, confirming the form was filled out successfully, using Gmail API. If the status code is bad, then an email stating the error will be sent back to the user.
Challenges I ran into
A college-managed Outlook account has a lot of permisison restrictions, such as API access and auto-forwarding, which were major roadblocks to get read-access to my emails. The workaround for that was to use Microsoft Power Automate to forward Outlook daily health check emails to an permission-free bot email address.
Another problem is choosing how the form should be submitted. An interactive UI library that fills the form real-time requires less code, but your system needs to be on when the form is being filled out. Doing a POST request would be an ideal approach and usefully for multiple simultatenous requests, but required a lot of research into what exactly went into each request and formatting the request data.
Accomplishments that I'm proud of
Utilizing multiple technologies that do a lot of the heavy-lifiting for me, so that I don't have to reinvent the wheel. It enabled me to write minimal code for the project, and focusing on the bigger picture of how to make the application more user-friendly and secure
What I learned
All technologies I used in this project were completely new to me, so overocming the learning curve for each technology was a huge feat for this project. I also learned the fact that I don't need to code every single aspect of a project, rather find tools that do what I need to, and figure out a method to connect all of these tools together, to make a seamless application.
What's next for Daily Health Check Bot
As this bot is built for UTD Health Checks only, the logical next step would be to generalize this bot for all other colleges' health checks.
Right now, this application is centralized under my credentials, and while I use secure technologies, I do not carry a secure brand, so new users would be hesistant to use this application, and would rather just continue to fill the forms out daily, or try to make a bot of their own. If it is the latter, creating a document to replicate the steps I took to create this project would be useful, so they can deploy the technology on their side.