Appointment Reminders with Ruby and Rails

Ready to implement appointment reminders in your application? Here's how it works at a high level:

1. An administrator creates an appointment for a future date and time, and stores a customer's phone number in the database for that appointment
2. A background process checks the database on a regular interval, looking for appointments that require a reminder to be sent out
3. At a configured time in advance of the appointment, an SMS reminder is sent out to the customer to remind them of their appointment

Building Blocks

Here are the technologies we'll use to get this done:

• Ruby on Rails to create a database-driven web application
• The Messages Resource from Twilio's REST API to send text messages
• Delayed::Job to help us schedule and execute background tasks on a recurring basis

How To Read This Tutorial

To implement appointment reminders, we will be working through a series of user stories that describe how to fully implement appointment reminders in a web application. We'll walk through the code required to satisfy each story, and explore what we needed to add at each step.

All this can be done with the help of Twilio in under half an hour.

Creating an Appointment

As a user, I want to create an appointment with a name, guest phone numbers, and a time in the future.

In order to build an automated appointment reminder app, we probably should start with an appointment. This story requires that we create a bit of UI and a model object to create and save a new Appointment in our system. At a high level, here's what we will need to add:

• A form to enter details about the appointment
• A route and controller function on the server to render the form
• A route and controller function on the server to handle the form POST request
• A persistent Appointment model object to store information about the user

Let's start by looking at the model, where we decide what information we want to store with the appointment.

The Rails Generator

Usually at this point in the tutorial we would build our model, view and controller from scratch (see account verification as an example). But since the appointment model is so straight-forward, and we really just want the basic CRUD scaffolding, we're going to use the Rails generator for once.

A Note about Tools

In this app we're using Rails 4, but it will be very similar for 3 and below. We will also be using the twilio-ruby helper library. Lastly we use bootstrap to simplify design, and in this case there is a gem that will generate bootstrap-themed views called twitter-bootstrap-rails. Please check out these tools when you have a chance, now let's move on to generating our scaffolding.

Generate a Model, View and Controller

Rails generate is a command-line tool that generates rails components like models, views, tests and more. For our purposes we are going to use the big kahuna generator, scaffold to generate everything at once.

Here's how we did it. From inside our rails app, we ran:

$ bin/rails generate scaffold Appointment name:string phone_number:string time:datetime

This tells our generator to create the 'scaffolding' for a resource called Appointment, which has the properties name, phone_number and time.

Now let's go to the model that was generated and add some stuff to it.

Appointment Model

The appointment model is pretty simple out of the box, but since humans will be interacting with it let's make sure we add some data validation.

Data Validation

Validations are important since we want to make sure only accurate data is being saved into our database. In this case, we only want to validate that all of our required fields are present. We can do this by creating a validates statement with presence: true.

It is likely that our Appointment Model would be created by an admin person at the site of the appointment. Well it would be great if we could give our admin user some feedback when they create the appointment. Luckily in Rails if we add validations to our models we get error reporting for free with the session's flash object.

One note: in order to run this demo you would need to run rake db:migrate which would run the migrations in our db/migrate folder. For this tutorial we're gonna focus on the core concepts but if you want to learn more about migrations you can read the Rails guide on the subject.

Now we're ready to move up to the controller level of the application, starting with the HTTP request routes we'll need.

Routes

In a Rails application, Resource Routing automatically maps a resource's CRUD capabilities to its controller. Since our Appointment is an ActiveRecord resource, we can simply tell Rails that we want to use these routes, which will save us some lines of code.

This means that in this one line of code we automatically have an appointment/new route which will automatically render our appointment/new.html.erb file.

Let's take a look at this form up close.

New Appointment Form

When we create a new appointment, we need a guest name, a phone number and a time. By using the rails form_for tag we can bind the form to the model object. This will generate the necessary html markup that will create a new Appointment on submit.

Let's point out one specific helper tag that Rails gives us for model-bound forms.

Date and Time

One potential time-suck is figuring out how to handle the date and time of the appointment. In reality this is two separate user inputs, one for the day and one for the time of the appointment. We need a way to combine these two separate inputs into one paramater on the server-side. Again Rails handles this by giving us the data_select and time_select tags which the server automatically gathers into one paramater that maps to the appointment.time property.

Let's jump back over to the controller to see what happens when we create this appointment.

Handle the Form POST

One of the other handy controllers created by our Appointment resource route was appointment/create which handles the POST from our form.

In our controller we take the input from our form and create a new Appointment model. If the appointment is saved to the database successfully, we redirect to the appointment details view which will show the creator the new appointment and allow them to edit or delete it.

Next we're going to take a look at the generated controllers for edit and delete.

Interacting with Appointments

As a user, I want to view a list of all future appointments, and be able to delete those appointments.

If you're an organization that handles a lot of appointments, you probably want to be able to view and manage them in a single interface. That's what we'll tackle in this user story. We'll create a UI to:

• Show all appointments
• Delete individual appoinments

Let's start by looking at the controller.

Show a List of Appointments

At the controller level, all we'll do is get a list of all the appointments in the database and rendering them with a view. We should also add a prompt if there aren't any appointments, since this demo relies on there being at least one appointment in the future.

Let's go back to the template to see our list of appointments.

Now let's take a look at what happens in the controller when we ask to delete an appointment.

Now let's take a look at what happens when an appointment is actually deleted.

Delete an Appointment

Now that we have the appointment, we simply need to call .destroy on it. In a production app you may want to evaluate whether to use .delete instead of destroy, since both are valid ways to delete a database row in Rails. For our purposes we will use the less-eficient destroy for two reasons:

1. It handles database clean-up
2. It keeps the Appointment in memory, so that we can flash a success message to the user

Now that we can interact with our appointments, let's dive into sending out reminders when one of these appointments is coming up.

Send the Reminder

As an appointment system, I want to notify a user via SMS an arbitrary interval before a future appointment.

There are a lot of ways to build this part of our application, but no matter how you implement it there should be two moving parts:

• A script that checks the database for any appointment that is upcoming, then sends an sms
• A worker that runs that script continuously

Let's take a look at how we decided to implement the latter with Delayed::Job.

Working with Delayed::Job

As we mentioned before, there are a lot of ways to implement a scheduler/worker, but in Rails Delayed::Job is the most established.

Delayed Job needs a backend of some kind to queue the upcoming jobs. Here we have added the ActiveRecord adapter for delayed_job, which uses our database to store the 'Jobs' database. There are plenty of backends supported, so use the correct gem for your application.

Once we included the gem, we need to run bundle install and run the rake task to create the database.

rails g delayed_job:active_record

You can see all of these steps in the github repo for this project.

Now we're ready to create the actual job.

Send a Reminder

The next step in sending a reminder to our user is creating the script that we'll fire at some interval before the appointment time. We will end up wanting to schedule this reminder when the appointment is created, so it makes sense to write it as a method on the Appointment model.

The first thing we do is create a Twilio client that will send our SMS via the Twilio REST API. We'll need three things to create the Twilio client:

• Our Twilio account SID
• Our Twilio auth token
• A Twilio number in our account that can send text messages

All of these can be found in your console.

Then all we need to do to send an sms is use the built in messages.create() to send an SMS to the user's phone.

Model Callback

Because we made our reminder script a method on the model we get one very handy tool; a callback. By using the before_create callback we ensure that the :reminder gets called whenever an Appointment is created.

The last step is making sure this callback always ends up being scheduled by Delayed Job.

Schedule a Reminder

Well we're almost done, now all we need to do is write an extremely complicated schedule controller that does the following:

• Look up each future appointment
• Add it to a Jobs table
• Check whether it is within the minutes_before_appointment interval
• Fire the reminder method

Oh wait, Delayed Job does this for free in one handy method called handle_asynchronously which tells Delayed Job to schedule this job whenever this method is fired. Since our job time is dependent on the individual Appointment instance we need to pass the handle_asynchronously method a function that will calculate the time. In this case minutes_before_appointment is set to 30 minutes, but you can use any Time interval here.

Now when we create an appointment we will see a new row in the Jobs table, with a time and a method that needs to be fired. Additionally, delayed_job saves errors, and attempts so we can debug any weirdness before it fails. Once it fires a job it removes it from the database, so on a good day we should see an empty database.

All Done

Wow, that was quite an undertaking, but in reality we had to write very little code to get automated appointment reminders firing with Twilio.

Where to Next?

And with a little code and a dash of configuration, we're ready to get automated appointment reminders firing in our application. Good work!

If you are a Ruby developer working with Twilio, you might want to check out other tutorials in Ruby:

Click to Call

Put a button on your web page that connects visitors to live support or sales people via telephone.

Two-Factor Authentication

Improve the security of your Ruby app's login functionality by adding two-factor authentication via text message.

Did this help?

Thanks for checking out this tutorial! If you have any feedback to share with us, please reach out on Twitter... we'd love to hear your thoughts, and know what you're building!