The Rehire Check stage looks an applicant up in your HRIS the moment they reach it, reads the eligibility field on their record, and lets your workflow rules route them from the answer. No spreadsheet, no manual lookup, no waiting on HR to reply.

Onboard has a separate feature that links a returning worker to their existing profile and decides whether to restart their I-9. This article is about the Hire workflow stage that asks your HRIS "may we rehire this person?" before you make an offer.

Two things, and the second one is where people get stuck.

Whether your connector exposes an eligibility field is set on the integration itself, not in your account settings. If the panel says no field is mapped for your connector, contact Fountain support with your HRIS name. Adding the mapping is a short change on our side, not a project.

One thing that is on your side, and it catches people out: the field is only useful if your HR team has actually filled it in on your existing terminated population. A field that exists but is empty reads as "not eligible" for everyone. The panel warns you about this directly — see Values that mean eligible below.

The check finds people by email address. If the stage sits before applicants have given you one, every applicant comes back as "no match" and the stage does nothing at all. Put it after your application form, not on the landing stage.

Click your new stage. Everything lives in one card, Rehire Check Stage Settings, and it reads in the order you need it: which system we ask, how we find the person, what we read, what we copy back.

Most of it is set for you. In the majority of accounts the only setting you have to think about is Values that mean eligible.

If you have one HRIS connected, Fountain picks it for you and greys the field out. If you have several, choose the one that holds employment history. If it says you have none, connect one first.

Applicants are matched on their email address. That needs no setup and is what most accounts use on its own.

You can also tick Also confirm with the SSN, when the applicant has given one. When it is ticked, an applicant who has provided a social security number is confirmed on both their email and their SSN, which removes the case where two former employees share an address. Applicants who have not given one still match on email alone, exactly as before — ticking the box never rejects anybody for a missing number.

Under the tick box, Read it from chooses which applicant field holds the number. It defaults to the standard ssn field, which is the right answer for almost everyone. Change it only if your account collects the number under a different data key.

Two things have to be true before it appears: secure data has to be enabled on your account, and your own role has to be allowed to read it. That is deliberate — a social security number is not something every recruiter should be able to point a lookup at.

The account-level half is the usual reason it is missing, and neither you nor your own Fountain administrator can switch it on. It is set by Fountain. Contact support and ask for secure data to be enabled on your account, and say that you want it for rehire SSN confirmation. If it turns out the account is already enabled and you still cannot see the section, then it is the role-level half, and that one is with whoever administers your Fountain users.

A dropdown of the fields your connector actually returns. If your connector exposes exactly one eligibility field, Fountain selects it and tells you it did. If it exposes several, pick the one your HR team maintains.

Two messages worth recognising here. "This saved field is not mapped on this connector" means the stage was configured against a field that has since disappeared from the mapping — pick a mapped one before you test. "No rehire eligibility field is mapped for this connector" means there is nothing to pick, and that is the support request described above.

This is the one that needs your judgement, because the field name is standardised but the values inside it are not. List every value that should count as "yes, we would take this person back". Anything you do not list — including a blank field — counts as not eligible.

Fountain shows you what it actually found. The panel samples your terminated population and reports the values present on those records, so you can add the real ones instead of guessing. If it reports that the field is empty on every record it checked, stop and populate it in your HRIS first — no configuration on this screen can rescue an empty field.

You still type the values yourself, so use what the panel reports rather than what you expect. As a rough orientation, worth confirming against your own data: Workday and UKG Ready usually return Yes or No, UKG Pro returns Y or N, Dayforce returns YES or NO, and ADP returns a true/false — in which case list true.

Capitalisation and stray spaces do not matter, so yes also matches YES.

When the check finds someone, four things are written onto the applicant automatically, whatever the verdict. You do not configure these and you cannot turn them off.

On top of those, you can copy up to five more fields from the matched record onto the applicant. Fountain suggests the three that people ask for most — Supervisor, Previous location and Employment type — and you choose which applicant data key each one lands in.

Two names are refused: hris_id, which is reserved, and anything starting with rehire_check_, which would collide with the stage's own fields. Each mapping also needs its own distinct target.

What to do when Fountain cannot get a trustworthy answer — your HRIS is unreachable, the field is missing, or two different people match.

Held applicants do not chase themselves. An applicant kept on the stage stays there until someone moves them. If you choose this option, decide now who checks the stage and how often. A held applicant is a candidate waiting on you, not a candidate rejected.

Records the answer and does nothing with it. No holding, no routing, nothing written on the applicant record — including the four automatic fields above. It is off when you create the stage, so turn it on before you save and leave it on for your first week (see step 5).

At the bottom of the settings card, Test this configuration. Type an email address and run it. Nothing is created, no applicant is touched, and it uses the settings currently on screen even if you have not saved.

If you have turned on SSN confirmation, the tester also offers an optional SSN field so you can prove that path works before real applicants reach it. Give it a complete number, not the last four.

Run these four, in this order. If any surprises you, fix the settings before going further.

Getting "not eligible" for someone you know is eligible almost always means your Values that mean eligible list does not match what your HRIS returns. The test result shows the raw value it read — compare it with your list, and add the real one.

The stage only produces an answer. Your rules decide what to do with it. Below the settings card, add a rule and pick the condition Rehire status is…

Someone can be both Eligible and Currently employed at the same time. If your "eligible" rule sits above your "currently employed" rule, a current employee sails through as a normal rehire. Put the narrower rule first.

Write a rule for every status you care about. A status with no rule leaves the applicant sitting on the stage.

This is the step people skip, and it is the one that makes the difference.

Applicants already past the stage are not re-checked when you switch modes. Only new arrivals are.

The stage writes its answer onto the applicant as applicant data fields, so you read them the same way you read any other applicant data — no report to request, no export from us.

Once shadow mode is off, the verdict lands in rehire_check_status, holding one clean value: eligible, not_eligible, no_match, ambiguous, field_not_mapped or unavailable. You can filter your applicant list on it and add it as a column, exactly like any other applicant data field. A companion field, rehire_check_detail, holds the supporting evidence: the raw value read from the HRIS, the employment status, and when the data was last synced.

Whenever the check matches somebody, four more fields are filled in automatically, whatever the verdict: rehire_check_employment_status, rehire_check_termination_date, rehire_check_original_hire_date and rehire_check_matched_id. Anything you set up under Data from the matched record lands in the data keys you chose.

While shadow mode is on, none of those fields are written on purpose — that is what makes shadow mode safe. Everything goes into a single field called rehire_check_shadow, which holds the whole result as one block of text rather than a tidy value. So filtering on it does not work the way the others do.

To review a shadow run, export your applicants with the rehire_check_shadow column included and read the verdict value inside each cell. For a one-week comparison against an existing process that is perfectly workable, and it is the reason we recommend a week rather than a month. If you are running a long parity comparison and this becomes painful, tell us — we would rather hear it than have you build a workaround.

No. Fountain reads a synchronised copy of your employee data, so your HRIS sees no extra load. The answer is as fresh as the last sync, which is why a brand-new connection can return "needs review" for a few minutes until the first sync finishes.

Nothing, unless you switch on SSN confirmation, which requires secure data to be enabled on your account by Fountain. When you do, the number is used to confirm a match and nothing else. It is never stored by this stage, never written to a log, and never returned in any response. Matching on email alone remains the default.

Check the connection in Settings → Connectors first. If it is healthy, look at the Eligibility field dropdown: if it says nothing is mapped for your connector, that is your answer, and it needs a support request.

Three usual causes. The stage sits before you collect email addresses; or your HRIS stores work addresses while applicants type personal ones; or you have switched on SSN confirmation against a field that holds only the last four digits. Test one known former employee with the exact address on their HRIS record to tell the first two apart.

Yes. Their original hire date is copied automatically on every match, along with their employment status and termination date. Their supervisor, previous location and employment type are available under Data from the matched record, where you can also map up to five fields of your own choosing.

Email is always the base key. You can add SSN confirmation on top of it, which is described under How we find the person. There is no way to match on SSN alone.

Still stuck? Contact Fountain support with your opening name, the stage name, and one example email address you tested, and we can see exactly what the check returned.