Appointment Reminders

How It Works

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:

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.

Let's get started! Click the right arrow to move on to the next step of the tutorial.

About This Tutorial

In this tutorial, we will be working through a series of user stories that describe how to fully implement account verification in a web application. Our team implemented this example application in about 12 story points (roughly equivalent to 12 working hours).

Let's get started with our first user story around creating a new user account.

Creating an Appointment

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

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.


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 select_data and select_time 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.

Handling 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

<blockquote>As a user, I want to view a list of all future appointments, and be able to delete those appointments</blockquote>

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.

Showing 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.

View All Appointments

The index view lists all of the appointments which are automatically ordered by date_created. The only thing we need to add to fulfill our user story is a delete button. We'll add the edit button just for kicks.

URL Helpers

You may notice that instead of hard-coding the urls for Edit and Delete we are using a Rails URL helper. If you view the rendered markup you will see these paths:

  • /appointments/(some ID)/edit for edit
  • /appointments/(some ID) for delete, with an HTTP DELETE method appended to the query

These URL helpers can take either an appointment object, or an ID.

There are some other helpers in this code that Rails generates for us. The one I want to point out is the :confirm tag. The confirm tag is a data attribute that interrupts the actual DELETE request with a javascript alert. This is best-practices when calling DELETE on an object. If the user confirms we process the request normally, otherwise no action will be taken.

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

Looking up the Appointment

In this controller we need to pull up an appointment record and then delete it. Let's take a look at how we're grabbing the appointment first.

Since we're probably going to need an appointment record in most of our views, we should just create a private instance method that can be shared across multiple controllers.

In set_appointment we use the id paramater, passed through from the route, to look up the appointment. Then at the top of our controller we use the before_action filter like so:

before_action :set_appointment, only: [:show, :edit, :update, :destroy]

This tells our application which controllers to apply this filter to. In this case we only need an appointment when the controller deals with a single appointment.

Deleting 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.

Sending the Reminder

<blockquote>As an appointment system, I want to notify a user via SMS an arbitrary interval before a future appointment</blockquote>

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. If you have found a better way to schedule jobs in Rails please let us know.

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.

Sending 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 dashboard.

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.

Scheduling 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 @@REMINDER_TIME 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 @@REMINDER_TIME 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. Be sure to check out the project buttons above to download the source for this application, view it on GitHub, or deploy it to Heroku to see it in action for yourself.

We'd also love to hear your feedback on this tutorial - please reach out to us with any questions you might have. Thanks for checking out the tutorial!