The Human Resources Department had put in a request for a system to track job applicants. They had looked at other solutions, including highly-recommended packages from PeopleSoft, but found them not to be sufficient for their needs. They needed to be able to enter new jobs which would be open at any of a variety of different sites scattered across North America, each job inheriting a job code specific to the site. Once created, each job would have several applicants matched to it, and history would exist for each applicant with regards to that job: a history of interviews, letters, decisions made by HR, offers made, offers accepted, jobs closed by being filled by someone else, applicants being discarded from further consideration, etc. Meanwhile, all applicants would be entered in the system in order to be matched with various possible jobs, would have applications (usually in Microsoft Word) which needed to be retained in their original format while being content-searchable, and would have a status as applicant as well as a status and history with regards to each job for which they had been considered. Reports such as affirmative action and regional statistics would need to be run on applicants and the outcome of their consideration for all jobs for which they had been considered, etc.

The filling of a job would necessarily mean modifying the status of every applicant for that job with regards to that job, and, similarly, the hiring of an applicant would mean modifying the status of that applicant with regards to any other jobs for which she or he was under consideration.

Because of how the HR staff tended to work, the users needed to be able to leave the task half-finished in order to attend to other things, but without half-entered jobs (or applicants) being available to the rest of the system, and certain parameters had to be checked for completeness, validity, or accuracy before the entire entry could be accepted.

This solution was created in its final architectural form (although without more than the most basic feature set) within 5 days of the initial discussion, making it one of the most satisfying turnarounds for a fairly sophisticated system. All subsequent changes involved expanding and extending the feature set or improving the workflow or interface in specific areas.

The solution is architecturally similar in many ways to the FmPro security system, but whereas the security system is a conventional "many to many relationship" design with a 3rd file serving as a "join file", the HR Job Apps is actually a "many to many to many" architecture: many jobs each of which has several applicants / many applicants each of which may be under consideraton for several different jobs / multiple records of the history of any specific applicant to a specific job, e.g., "Added to job consideraton queue", "interview scheduled" , "first interview", "chosen for further consideration", etc. Despite this additional layer of complexity, the fundamental data for jobs, applicants, and history was set up in only three files, and the overview of all relevant data, as with the security system, was still maintained from a single screen.

Unusually, the HR director chose an interface that used unlabeled buttons, figuring it looked less cluttered and that people would soon learn what the buttons did. To counterbalance this, a built-in help was set up for each screen identifying what the buttons do as well as explaining other aspects of any given screen. Here is the Enter Outcome screen with Help turned on:

Here is the QuickFind screen, which simplified locating talent after entering a new job in the system.

Here is a typical pop-up dialog, which was the primary implementation of the director's requirement that certain tasks be checked for errors and completeness before being "saved" in the system and therefore accessible to other functions and/or other users of the system. Pop-ups also accentuated the sense of working all day from a single all-purpose screen. Users felt like they were on their "home screen" even when restricted to the activities confined to a pop-up dialog, and therefore were less often confused about how to "get back to other types of tasks".

Once hired, the applicant's descriptive info would be auto-entered into the FileMaker-based database of actual employees and email automatically dispatched to the appropriate Office Services personnel to set up the new employee with phone and nameplate and office keys and security codes and so forth.