Skip to contentSkip to navigationSkip to topbar
On this page

Workflow Automation with Ruby and Rails


One of the more abstract concepts you'll handle when building your business is what the workflow will look like.

At its core, setting up a standardized workflow is about enabling your service providers (agents, hosts, customer service reps, administrators, and the rest of the gang) to better serve your customers.

To illustrate a very real-world example, today we'll build a Ruby on Rails webapp for finding and booking vacation properties — tentatively called Airtng.

Here's how it'll work:

  1. A host creates a vacation property listing
  2. A guest requests a reservation for a property
  3. The host receives an SMS notifying them of the reservation request. The host can either Accept or Reject the reservation
  4. The guest is notified whether a request was rejected or accepted

Learn how Airbnb used Twilio SMS to streamline the rental experience for 60M+ travelers around the world.(link takes you to an external page)


Workflow Building Blocks

workflow-building-blocks page anchor

We'll be using the Twilio REST API to send our users messages at important junctures. Here's a bit more on our API:

  • Sending Messages with Twilio API

Application routes

application-routes page anchor

config/routes.rb

1
Rails.application.routes.draw do
2
3
get "login/", to: "sessions#login", as: 'login'
4
get "logout/", to: "sessions#logout"
5
post "login_attempt/", to: "sessions#login_attempt"
6
7
resources :users, only: [:new, :create, :show]
8
9
resources :vacation_properties, path: "/properties"
10
resources :reservations, only: [:new, :create]
11
post "reservations/incoming", to: 'reservations#accept_or_reject', as: 'incoming'
12
13
# Home page
14
root 'main#index', as: 'home'
15
16
end

The Vacation Property Model

the-vacation-property-model page anchor

The VacationProperty model belongs to the User who created it (we'll call this user the host moving forward) and contains only two properties, a description and an image_url.

It has two associations(link takes you to an external page) in that it has many reservations and therefore many users through those reservations.

The best way to generate the model and all of the basic CRUD scaffolding(link takes you to an external page) we'll need is to use the Rails command line(link takes you to an external page) tool:

1
bin/rails generate scaffold VacationProperty
2

One of the benefits of using the Rails generator is that it creates all of our routes, controllers and views so that we have a fully functional CRUD interface out of the box. Nifty!

app/models/vacation_property.rb

1
class VacationProperty < ActiveRecord::Base
2
belongs_to :user # host
3
has_many :reservations
4
has_many :users, through: :reservations #guests
5
end

Let's jump into the stew and look next at the Reservation mode.


The Reservation model is at the center of the workflow for this application. It is responsible for keeping track of:

  • the VacationProperty it is associated with
  • the User who owns that vacation property (the host )
  • the guest name and phone number

app/models/reservation.rb

1
class Reservation < ActiveRecord::Base
2
validates :name, presence: true
3
validates :phone_number, presence: true
4
5
enum status: [ :pending, :confirmed, :rejected ]
6
7
belongs_to :vacation_property
8
belongs_to :user
9
10
def notify_host(force = true)
11
@host = User.find(self.vacation_property[:user_id])
12
13
# Don't send the message if we have more than one or we aren't being forced
14
if @host.pending_reservations.length > 1 or !force
15
return
16
else
17
message = "You have a new reservation request from #{self.name} for #{self.vacation_property.description}:
18
19
'#{self.message}'
20
21
Reply [accept] or [reject]."
22
23
@host.send_message_via_sms(message)
24
end
25
end
26
27
def confirm!
28
self.status = "confirmed"
29
self.save!
30
end
31
32
def reject!
33
self.status = "rejected"
34
self.save!
35
end
36
37
def notify_guest
38
@guest = User.find_by(phone_number: self.phone_number)
39
40
if self.status_changed? && (self.status == "confirmed" || self.status == "rejected")
41
message = "Your recent request to stay at #{self.vacation_property.description} was #{self.status}."
42
@guest.send_message_via_sms(message)
43
end
44
end
45
end

Since the reservation can only have one guest for our example we simplified the model by assigning a name and phone_number directly.

We'll cover how we did this later. Next, however, we'll zoom in on the reservation status.


First we validate some key properties and define the associations so that we can later lookup those relationships through the model. (If you'd like more context, the Rails guide(link takes you to an external page) explains models and associations quite well.)

The main property we need to enable a reservation workflow is some sort of status that we can monitor. This is a perfect candidate for an enumerated status attribute.

Enumerated Attributes

enumerated-attributes page anchor

Enumerated attributes(link takes you to an external page) allow us to store an integer in the table, while giving each status a searchable name. Here is an example:

1
# reservation.pending! status: 0
2
reservation.status = "confirmed"
3
reservation.confirmed? # => true
4

Validators and Foreign Key for the Reservation model

validators-and-foreign-key-for-the-reservation-model page anchor

app/models/reservation.rb

1
class Reservation < ActiveRecord::Base
2
validates :name, presence: true
3
validates :phone_number, presence: true
4
5
enum status: [ :pending, :confirmed, :rejected ]
6
7
belongs_to :vacation_property
8
belongs_to :user
9
10
def notify_host(force = true)
11
@host = User.find(self.vacation_property[:user_id])
12
13
# Don't send the message if we have more than one or we aren't being forced
14
if @host.pending_reservations.length > 1 or !force
15
return
16
else
17
message = "You have a new reservation request from #{self.name} for #{self.vacation_property.description}:
18
19
'#{self.message}'
20
21
Reply [accept] or [reject]."
22
23
@host.send_message_via_sms(message)
24
end
25
end
26
27
def confirm!
28
self.status = "confirmed"
29
self.save!
30
end
31
32
def reject!
33
self.status = "rejected"
34
self.save!
35
end
36
37
def notify_guest
38
@guest = User.find_by(phone_number: self.phone_number)
39
40
if self.status_changed? && (self.status == "confirmed" || self.status == "rejected")
41
message = "Your recent request to stay at #{self.vacation_property.description} was #{self.status}."
42
@guest.send_message_via_sms(message)
43
end
44
end
45
end

Once we have an attribute that can trigger our workflow events, it's time to write some callbacks. Let's look there next.


The Reservations Controller

the-reservations-controller page anchor

We'll be posting our reservation details to the create route from the vacation property page.

After we create the reservation we want to notify the host that she has a request pending. After she accepts or rejects it we want to notify the guest of the news.

While the Reservation model handles the notification, we want to keep all these actions in the controller to show our intentions.

The Reservation Controller

the-reservation-controller page anchor

Create a new reservation

1
class ReservationsController < ApplicationController
2
3
# GET /vacation_properties/new
4
def new
5
@reservation = Reservation.new
6
end
7
8
def create
9
@vacation_property = VacationProperty.find(params[:reservation][:property_id])
10
@reservation = @vacation_property.reservations.create(reservation_params)
11
12
if @reservation.save
13
flash[:notice] = "Sending your reservation request now."
14
@reservation.notify_host
15
redirect_to @vacation_property
16
else
17
flast[:danger] = @reservation.errors
18
end
19
end
20
21
# webhook for twilio incoming message from host
22
def accept_or_reject
23
incoming = Sanitize.clean(params[:From]).gsub(/^\+\d/, '')
24
sms_input = params[:Body].downcase
25
begin
26
@host = User.find_by(phone_number: incoming)
27
@reservation = @host.pending_reservation
28
29
if sms_input == "accept" || sms_input == "yes"
30
@reservation.confirm!
31
else
32
@reservation.reject!
33
end
34
35
@host.check_for_reservations_pending
36
37
sms_reponse = "You have successfully #{@reservation.status} the reservation."
38
respond(sms_reponse)
39
rescue
40
sms_reponse = "Sorry, it looks like you don't have any reservations to respond to."
41
respond(sms_reponse)
42
end
43
end
44
45
private
46
# Send an SMS back to the Subscriber
47
def respond(message)
48
response = Twilio::TwiML::Response.new do |r|
49
r.Message message
50
end
51
render text: response.text
52
end
53
54
# Never trust parameters from the scary internet, only allow the white list through.
55
def reservation_params
56
params.require(:reservation).permit(:name, :phone_number, :message)
57
end
58
59
end

Next up, let's take a look at how exactly we'll notify the lucky host.


To notify the host, we can look them up and send them an SMS message. However, how do we ensure our hosts are: a) responding to the correct reservation inquiry and b) not getting spammed?

Our solution to both problems:

  • We only notify the host of the oldest pending reservation.
  • We don't send another SMS until the host has dealt with the last reservation.

To do this, we'll create a helper method on the User model to surface the pending_reservations method on a user. We'll go over that in the next step.

If in fact the host only has one pending reservation, we're going to fire an SMS off to the host immediately.

Send an SMS to notify the host of a new reservation

send-an-sms-to-notify-the-host-of-a-new-reservation page anchor

app/models/reservation.rb

1
class Reservation < ActiveRecord::Base
2
validates :name, presence: true
3
validates :phone_number, presence: true
4
5
enum status: [ :pending, :confirmed, :rejected ]
6
7
belongs_to :vacation_property
8
belongs_to :user
9
10
def notify_host(force = true)
11
@host = User.find(self.vacation_property[:user_id])
12
13
# Don't send the message if we have more than one or we aren't being forced
14
if @host.pending_reservations.length > 1 or !force
15
return
16
else
17
message = "You have a new reservation request from #{self.name} for #{self.vacation_property.description}:
18
19
'#{self.message}'
20
21
Reply [accept] or [reject]."
22
23
@host.send_message_via_sms(message)
24
end
25
end
26
27
def confirm!
28
self.status = "confirmed"
29
self.save!
30
end
31
32
def reject!
33
self.status = "rejected"
34
self.save!
35
end
36
37
def notify_guest
38
@guest = User.find_by(phone_number: self.phone_number)
39
40
if self.status_changed? && (self.status == "confirmed" || self.status == "rejected")
41
message = "Your recent request to stay at #{self.vacation_property.description} was #{self.status}."
42
@guest.send_message_via_sms(message)
43
end
44
end
45
end

Let's now take a look at the User model.


We have one model for both the guests and the hosts who are using Airtng.

When Airtng takes off it will merit creating two more classes that inherit from the base User class. Since we're still on the ground this should suit us fine (to boldly stay...).

First, we validate the 'uniqueness' of our user - they should be unique, just like everyone else. Specifically, it is important we ensure that the phone_number attribute is unique since we will use this to look up User records on incoming SMSes.

After that, we set up our associations for when we need to query for reservations.

Validators and relationships of the User Model

validators-and-relationships-of-the-user-model page anchor

app/models/user.rb

1
class User < ActiveRecord::Base
2
has_secure_password
3
4
validates :email, presence: true, format: { with: /\A.+@.+$\Z/ }, uniqueness: true
5
validates :name, presence: true
6
validates :country_code, presence: true
7
validates :phone_number, presence: true, uniqueness: true
8
validates_length_of :password, in: 6..20, on: :create
9
10
has_many :vacation_properties
11
has_many :reservations, through: :vacation_properties
12
13
def send_message_via_sms(message)
14
@app_number = ENV['TWILIO_NUMBER']
15
@client = Twilio::REST::Client.new ENV['TWILIO_ACCOUNT_SID'], ENV['TWILIO_AUTH_TOKEN']
16
phone_number = "+#{country_code}#{self.phone_number}"
17
sms_message = @client.account.messages.create(
18
from: @app_number,
19
to: phone_number,
20
body: message,
21
)
22
end
23
24
def check_for_reservations_pending
25
if pending_reservation
26
pending_reservation.notify_host(true)
27
end
28
end
29
30
def pending_reservation
31
self.reservations.where(status: "pending").first
32
end
33
34
def pending_reservations
35
self.reservations.where(status: "pending")
36
end
37
38
end

Arguably the most important task delegated to our User model is to send an SMS to the user when our app requests it, let's take a look.


Send Messages Into the Void

send-messages-into-the-void page anchor

Since we only send text messages in our application when we're communicating with specific users, it makes sense to create this function on the User class. And yes: these 7 lines are all you need to send SMSes with Ruby and Twilio! It's really just two steps:

  1. We look up our app's phone number.
  2. We initiate our Twilio client and build the message.

Now whenever we need to communicate with a user, whether host or guest, we can pass a message to this user method and... Voilà! We've sent them a text.

(If you peek below this method you'll see the helper methods for finding pending_reservations that we mentioned previously.)

Use Twilio client to send an SMS

use-twilio-client-to-send-an-sms page anchor

app/models/user.rb

1
class User < ActiveRecord::Base
2
has_secure_password
3
4
validates :email, presence: true, format: { with: /\A.+@.+$\Z/ }, uniqueness: true
5
validates :name, presence: true
6
validates :country_code, presence: true
7
validates :phone_number, presence: true, uniqueness: true
8
validates_length_of :password, in: 6..20, on: :create
9
10
has_many :vacation_properties
11
has_many :reservations, through: :vacation_properties
12
13
def send_message_via_sms(message)
14
@app_number = ENV['TWILIO_NUMBER']
15
@client = Twilio::REST::Client.new ENV['TWILIO_ACCOUNT_SID'], ENV['TWILIO_AUTH_TOKEN']
16
phone_number = "+#{country_code}#{self.phone_number}"
17
sms_message = @client.account.messages.create(
18
from: @app_number,
19
to: phone_number,
20
body: message,
21
)
22
end
23
24
def check_for_reservations_pending
25
if pending_reservation
26
pending_reservation.notify_host(true)
27
end
28
end
29
30
def pending_reservation
31
self.reservations.where(status: "pending").first
32
end
33
34
def pending_reservations
35
self.reservations.where(status: "pending")
36
end
37
38
end

Now we need a way to handle incoming texts so our lucky host can accept or reject a request. Let's look there next.


Handle Incoming Messages

handle-incoming-messages page anchor

The accept_or_reject controller handles our incoming Twilio request and does three things:

  1. Check for a pending reservation the user owns
  2. Update the status of the reservation
  3. Respond to the host (and guest)

An incoming request from Twilio comes with some helpful parameters including the From phone number and the message Body.

We'll use the From parameter to lookup the host and check if she has any pending reservations. If she does, we'll use the message body to check if she accepted or rejected the reservation.

Then we'll redirect the request to a TwiML response to send a message back to the user.


Usually a Rails controller has a template associated with it that renders a webpage. In our case, the only request being made will be by Twilio's API so we don't need a public page. Instead we're using Twilio's Ruby API to render a custom TwiML response as raw XML on the page.

Webhook for handling Host's decision

webhook-for-handling-hosts-decision page anchor

app/controllers/reservations_controller.rb

1
class ReservationsController < ApplicationController
2
3
# GET /vacation_properties/new
4
def new
5
@reservation = Reservation.new
6
end
7
8
def create
9
@vacation_property = VacationProperty.find(params[:reservation][:property_id])
10
@reservation = @vacation_property.reservations.create(reservation_params)
11
12
if @reservation.save
13
flash[:notice] = "Sending your reservation request now."
14
@reservation.notify_host
15
redirect_to @vacation_property
16
else
17
flast[:danger] = @reservation.errors
18
end
19
end
20
21
# webhook for twilio incoming message from host
22
def accept_or_reject
23
incoming = Sanitize.clean(params[:From]).gsub(/^\+\d/, '')
24
sms_input = params[:Body].downcase
25
begin
26
@host = User.find_by(phone_number: incoming)
27
@reservation = @host.pending_reservation
28
29
if sms_input == "accept" || sms_input == "yes"
30
@reservation.confirm!
31
else
32
@reservation.reject!
33
end
34
35
@host.check_for_reservations_pending
36
37
sms_reponse = "You have successfully #{@reservation.status} the reservation."
38
respond(sms_reponse)
39
rescue
40
sms_reponse = "Sorry, it looks like you don't have any reservations to respond to."
41
respond(sms_reponse)
42
end
43
end
44
45
private
46
# Send an SMS back to the Subscriber
47
def respond(message)
48
response = Twilio::TwiML::Response.new do |r|
49
r.Message message
50
end
51
render text: response.text
52
end
53
54
# Never trust parameters from the scary internet, only allow the white list through.
55
def reservation_params
56
params.require(:reservation).permit(:name, :phone_number, :message)
57
end
58
59
end

Next up, let's see how to notify the guest.


The final step in our workflow is to notify the guest that their reservation has been booked (or, ahem, rejected).

We called this method earlier from the reservations_controller when we updated the reservation status. Here's what it does:

  • We lookup the guest with the reservation.phone_number
  • If the status was changed to an expected result we notify the guest of the change.

And of course all we need to do to send the SMS message to the guest is call the send_message_via_sms method that is present on all users.

Let the guest have the host's decision

let-the-guest-have-the-hosts-decision page anchor

app/models/reservation.rb

1
class Reservation < ActiveRecord::Base
2
validates :name, presence: true
3
validates :phone_number, presence: true
4
5
enum status: [ :pending, :confirmed, :rejected ]
6
7
belongs_to :vacation_property
8
belongs_to :user
9
10
def notify_host(force = true)
11
@host = User.find(self.vacation_property[:user_id])
12
13
# Don't send the message if we have more than one or we aren't being forced
14
if @host.pending_reservations.length > 1 or !force
15
return
16
else
17
message = "You have a new reservation request from #{self.name} for #{self.vacation_property.description}:
18
19
'#{self.message}'
20
21
Reply [accept] or [reject]."
22
23
@host.send_message_via_sms(message)
24
end
25
end
26
27
def confirm!
28
self.status = "confirmed"
29
self.save!
30
end
31
32
def reject!
33
self.status = "rejected"
34
self.save!
35
end
36
37
def notify_guest
38
@guest = User.find_by(phone_number: self.phone_number)
39
40
if self.status_changed? && (self.status == "confirmed" || self.status == "rejected")
41
message = "Your recent request to stay at #{self.vacation_property.description} was #{self.status}."
42
@guest.send_message_via_sms(message)
43
end
44
end
45
end

Thank you so much for your help! Airtng now has a nice SMS based workflow in place and you're ready to add a workflow to your own application.

Let's look at some other features you might enjoy adding for your use cases.


Ruby and Rails and Twilio: what an excellent combo. Here are a couple other ideas you might pursue:

Masked Phone Numbers

Protect your users' privacy by anonymously connecting them with Twilio Voice and SMS.

Automated Survey

Collect instant feedback from your customers with SMS or Voice.

Need some help?

Terms of service

Copyright © 2024 Twilio Inc.