Recruitment and a CiviCase Pipeline Visualization

(This post is a follow-up to previous discussions about developing recruitment functionality for CiviHR. More information can be found in the first, second, and third blog posts well as the requirements wiki.)

We've recently had some great discussions about translating CiviHR's businss requirements for recruitment into a design with specific visuals and data models. Three concepts have been central to the discusion:

  • Job Vacancies are openings for new employees (or interns, contractors, or other selective positions).
  • Job Applications are submitted by individuals who wish to fill a particular vacancy.
  • Recruitment Activities are interactions with these individuals (such as emails, phone calls, meetings, and offers)

For CiviHR, we aim to build support for these recruitment concepts using a mix of existing, improved, and new CiviCRM features. The remainder of this blog post will briefly explore the model for recruitment and present some new CiviCase visualizations (which will help CiviHR recruitment and other CiviCase implementations).

Job Vacancies

Vacancies will be an entirely new entity defined by a new extension (org.civicrm.hrvacancy). For each vacancy, one can configure:

  • General Information: Define general information about the vacancy, such as the name of the job position, the job description, benefits, and salary range.
  • Application Form: Design the application form (to be filled out by new applicants) with the drag/drop profile designer. (Or re-use an existing form.)
  • Evaluation Form: Design the application form (to be filled out be interviewers) with the drag/drop profile designer. (Or re-use an existing form.)
  • Status: The status of a vacancy changes over time depending on the organization.In a small organization with a single manager, the manager may create and publish a vacancy immediately. He simply sets the status to "Open". Eventually, the vacancy is "Closed". In a mid-sized organiztion with more specialized roles ("hiring manager", "recruiter", "HR manager", etc), a hiring manager may enter the job description and save the vacancy as a draft. The HR manager then reviews the draft and either (a) changes the status to "Rejected" or (b) refines it and changes the status to "Open". Eventually, the vacancy is "Closed". "Open" vacancies can displayed on the public web site.

Recruitment Activities

Recruitment activities should generally behave like other activities in CiviCRM, e.g.

  • Scheduled phone calls and meetings should appear on the staff dashboard
  • Reminders should be configurable and schedulable
  • Emails should support templates and mail-merge
  • Custom activity types should be supported

A few additional activity types may be added, but generally they're the same.

Job Applications

A job application is very similar to a case (in CiviCase) with a few caveats. Like any other case, an application:

  • Contains a series of activities (such as phone calls, emails, and interviews)
  • Involves a soft touch (with phone calls, emails, meetings, etc -- not just automated messages)
  • Requires some uniformity in how applicants are treated (eg with standard communications based on how far each applicant advances in the process; and with consistent use of selection criteria)
  • Has a loose structure (progressing through stages -- "Apply", "Phone Interview", "Meet with Manager", "Offer", "Hired")
  • Is somewhat flexible (eg they may involve scheduling a meeting with 3 people, and that often requires a flurry of email/phone/sms interactions as people negotiate, reschedule, etc)

But applications are different in a few key ways:

  • One organization or recruiter may manage a high volume of applications -- eg anywhere from 10 to 200 applications for the same vacancy.
  • Applications should be organized by vacancy -- ie if 20 individuals apply for the same vacancy, then their information must be collected together, and it may be useful to compare applications.

The hrvacancy extension will define a new case-type for "Applications". However, we're also quite keen to improve the user-experience when managing a high-volume of applications, so we plan to introduce a new pipeline management console for CiviCase. In this console, all applications for a vacancy are sorted by how far the applicant has progressed. For example, some have merely submitted an application; others have advanced to the phone interview, manager interview, or offer stages. Clicking on the stage breaks out a list of all the applicants in that stage.

Vacancy Dashboard

For a mid-sized organization, there may be several vacancies under discussion - some vacancies which are being drafted/discussed internally, some vacancies which are actively soliciting applications, and some vacancies which have been recently filled. The Vacancy Dashboard lists the outstanding vacancies and summarizes the applications in the pipeline.

Public Vacancy List

Finally, when soliciting applications for a vacancy, a recruiter may use many strategies (such as emailing their associates, posting to online job boards, sharing via social networks). CiviHR aims to eventually provide tools to support these strategies, but our first requirement is to simply publish open vacancies on the organization's website.

This poses a small technical challenge: many mid-sized organizations will want to keep their HR systems separate from their public web systems. So how to publish content from the HR system through the public web system? On the public web site, embed a Javascript widget which references the HR system, e.g

    <script type="text/javascript" src=""></script>

The included Javascript code will output the Public Vacancy List.


For some big orgs, having extra info about the candidates as activists/supporters is very useful (eg. do they receive the newsletter? make donation? attend to event? participate to actions...) as they logically like to hire people that are already supporting their cause and engaged.

As opposed to the other HR modules, this one would make sense to be able to work within the main civi. Is this expected to be the case or still only on a separate civi?

2) it would be great to be able to trace the source automatically. ie. did the candidate come from a specific job board? our newsletter? word of mouth? some might be automated (eg. referer)

This allows to know if/where to put adds for instance, or where you always get a high number of crappy applications

3) Something that would be awesome would be to see when the applicants reply. this would allow to benchmark if a specific position is likely to get enough applicants before the deadline or if it's needed to promote it better. Civisualize loves you.


1) We'd like to allow customization of the details shown for the candidates, so we're thinking to specify the details as a profile. There are a few ways one might extend profiles to show details like newsletter subscriptions:

  • Add a custom HTML blob to the profile which includes some JS to fetch/display the interesting details
  • Add an extension which uses to inject content
  • Modify core to add some new, specialized "field types" (like an "Email subscriptions" block)

2) Tracking sources would be great. We also want to do a follow-up project around online marketing (eg sharing the job application link via different social media / boards). I think that tracking sources would make the most sense when done in tandem with the online marketing aspect (because a key part of tracking sources is generating suitable inbound links which indicate the source).

3) CiviVisualize sounds awesome. ;)


All looking really good.  Just one thing is the dashboard, would it be better to have activity/open vacancies at the top and draft underneath?  As the activity ones will be accessed more frequently.

Many thanks

Katherine :-)