Avo for HR & recruiting
Run candidates, employees, and pipelines from your Rails app
Candidate pipelines, employee records, documents, and offers, managed from a command center inside your Rails app, with compensation and personal data visible only to the roles that should see them.
250+ paying companies · 2.7M downloads of the avo gem
Position
title
team
status
Application
stage
source
offer_amount
Candidate
full_name
resume
Compensation sits on the application, gated to the roles cleared to read it, so a hiring manager can move a candidate forward without ever seeing the number.
01 · the stakes
What people data demands from an internal tool
HR and recruiting products run on the most personal data a company holds: salaries, addresses, CVs, and offer terms. The internal tool that touches all of it is usually the least carefully built screen in the stack.
-
01
Compensation data is radioactive
Salary bands, offer amounts, and equity grants should be visible to a handful of people. An admin where every login sees every field is one screenshot away from a very bad week.
-
02
A pipeline is a workflow, not a table
Recruiters think in stages: sourced, screening, interviewing, offer. A CRUD table forces them back into edit forms and status dropdowns, so the real pipeline ends up in a separate board that is always out of sync.
-
03
Documents pile up and access rarely keeps up
CVs, signed offers, IDs, and contracts attach to every candidate and employee. Storing them is easy; making sure a given file opens only for the roles allowed to see it is the part hand-built admins skip.
-
04
Every people process turns into engineering work
Advancing a candidate, generating an offer, onboarding a hire: when each step needs a developer, the people team's throughput is capped by the engineering backlog.
02 · the Avo version
Your models are already the hard part. Avo is the rest.
Avo mounts inside your Rails app and turns your candidate, application, and employee models into the tool the people team actually works in: pipelines as drag-and-drop boards, documents behind per-role authorization, compensation fields that render only for the roles allowed to see them, and the everyday verbs as one-click actions.
The pipeline as a board, on your models
The kanban add-on renders applications as columns per stage, so recruiters drag a candidate from screening to interview and the underlying record updates. One pipeline, in the same database as everything else.
Compensation visible on a need-to-know basis
Avo reads your Pundit policies down to the field, so salary and equity render only for comp admins while the rest of the record stays usable by everyone else. The access rules are Ruby in your repo.
Documents that open only for the right roles
CVs, offers, and contracts attach through Active Storage file fields, with download gated per role by attachment authorization, so a signed offer is only reachable by someone allowed to see it.
People verbs as one-click actions
Advance a candidate, send an offer, start onboarding: each is an action with a confirmation step and required inputs, calling the same code path your product uses, attributable to the person who ran it.
Queues and funnel numbers, live
Stale candidates, offers awaiting signature, and time-in-stage funnels as filtered views and dashboards from your own queries, so pipeline reviews run on live data instead of exports.
An Application resource with a stage pipeline and gated compensation:
class Avo::Resources::Application < Avo::BaseResource
self.includes = [:candidate, :position]
def fields
field :stage, as: :select, enum: ::Application.stages
field :candidate, as: :belongs_to, searchable: true
field :position, as: :belongs_to
field :offer_amount, as: :number, visible: -> { current_user.comp_admin? }
field :resume, as: :file
end
def actions
action Avo::Actions::AdvanceStage
action Avo::Actions::SendOffer
end
end
# app/policies/application_policy.rb (Avo reads your Pundit policies)
class ApplicationRecordPolicy < ApplicationPolicy
def download_resume? = user.recruiter?
end
03 · the timeline
From first resource to the team running on it
Generate resources for Candidate, Application, and Position and recruiters can search candidates, open applications, and see each position's pipeline on live data.
Put it behind your existing authentication, gate compensation fields and document downloads by role, and ship the advance-stage action so pipeline moves stop being status edits.
The pipeline is a kanban board recruiters drag candidates across, offers await signature in a saved view someone owns, and salary data renders only for the people cleared to see it.
case study · travel platform back office
“It's almost like having another developer on the team just focused on that side of things... it's paid for itself many times over.”
04 · start today
Give the people team its tool this week
Avo is per app with unlimited users, so the whole team works from it without the bill scaling with headcount. When you hit an edge Avo doesn't cover, you drop to plain Rails instead of filing a feature request.
Things HR & recruiting teams build with Avo
Avo by industry
Avo for your team
Frequently asked questions
- Can I build an HR or recruiting admin on Ruby on Rails?
- Yes. Candidates, applications, positions, and employees are ordinary Rails models, and Avo turns them into the tool the people team works in, pipelines, documents, and permissions included, on top of your existing tables. If you are building a full applicant tracking system, we wrote that up separately: build an ATS on Rails.
- Can recruiters manage the pipeline as a board?
- Yes. The kanban add-on renders applications as columns per stage, and dragging a candidate between columns updates the record, so the board and the database are the same thing. See the kanban add-on.
- How do we keep salaries visible to only a few people?
- Field-level authorization. Avo reads your Pundit policies, so compensation fields render only for roles you allow, while the rest of the record stays usable by recruiters and managers. The rules are Ruby in your repo, reviewable like any other code. See the authorization docs.
- What about CVs, offers, and signed documents?
- They attach through Active Storage file fields, and attachment authorization gates upload and download per role, so a contract opens only for someone allowed to see it. The files live in the storage you configured, not a third-party admin vendor's.
- Does candidate and employee data leave our servers?
- No. Avo is a Rails engine mounted in your application, so people data stays in your database and your storage, served by your app. Under GDPR and similar regimes that keeps your processor list unchanged, and deletion requests stay a matter of your own code.
- Can HR run their processes without engineering?
- The everyday ones, yes. Advancing candidates, sending offers, and starting onboarding become actions with confirmations and required inputs, and queues become saved views. Engineers build the action once; the people team runs it from then on.