A sourcing assistant finds a promising person and sends them into the interview pipeline. The recruiter then has to explain why someone who has never discussed the role appears beside applicants. The error started before the message was written. The workflow treated a research match as a decision to consider someone for a job. In Greenhouse, prospects and candidates represent different recruiting states. An AI integration needs to preserve that distinction.
This guide explains the native Greenhouse concepts and a proposed engineering workflow around them. The review records, AI briefs and retry controls below are custom design recommendations. They are not a claim that Greenhouse provides this exact AI workflow.
Start with the recruiting state
Greenhouse defines a candidate as someone who has entered the interview process by applying or interviewing for a specific role. A prospect has not applied to a specific role and is not currently interviewing. Prospects can include people found through sourcing and past candidates being considered for another opportunity. Their prospect profiles can track email communications, but they do not appear in the interview pipeline.
The practical question is whether the team is maintaining a relationship or considering the person for a particular job. A strong resume does not settle that question. Neither does a model-generated match score. Write the transition rule in language that a recruiter can use without inspecting an integration log.
| Situation | State to review | Decision still needed |
|---|---|---|
| Person found through research | Prospect | Whether and how to start a relationship |
| Past candidate worth reconnecting with | Prospect workflow for the new opportunity | Which role is relevant now |
| Team decides to consider a prospect for a job | Conversion to candidate | Target job and interview stage |
| Prospect marked interested in a pool | Pool stage | Whether a specific interview process should begin |
Keep prospect pools separate from interview plans
A prospect pool is a larger group of prospects. A stage is a smaller group within that pool. Greenhouse gives examples such as first contact, interested groups and prospects on hold. Those stages describe the sourcing relationship. They should not be silently translated into interview stages just because their labels look similar.
For an integration, keep separate fields for the pool, pool stage, target job and proposed interview stage. Treat labels as display text rather than assuming identical names represent identical objects. If your team renames a pool stage, review the mapping before allowing another action. A text classifier should not decide which job process a person enters from a stage label alone.
Pool visibility also needs attention. Greenhouse lets teams assign jobs, departments or offices to pools to control who can see the pool and its prospects. Pools without restrictions are visible to all CRM users. These settings matter when choosing who can review an AI brief. Do not send a summary to a broader audience merely because the integration can retrieve the profile.
Confirm the conversion permissions
Greenhouse documents conversion for Job Admin users who can view and edit candidates and prospects and above. For a prospect attached to a job, the user needs Job Admin access or above on that job. An unattached prospect needs the user-specific permission called Can manage unattached prospects.
Check the actual acting user's access before presenting an executable action. A reviewer being able to read a brief does not establish that the integration should convert on their behalf. If the required access is missing, retain the recommendation as a review item and route it to an authorized operator. Do not broaden account permissions just to make a queued action succeed.
Use the native conversion path deliberately
The documented manual path starts on the prospect's profile. Open the Jobs tab and choose Convert to Candidate. Select a job name and stage in the prompt, then confirm. Greenhouse adds the person as a candidate on that job. This makes the job and stage explicit instead of letting a downstream system infer them.
Before confirming, have the recruiter check the current profile and the reason for the transition. Record whether the decision came from a conversation, an application or an internal decision to consider the person. Do not describe an internal sourcing decision as something the person requested. Preserve their actual words separately from a model's interpretation.
Build an AI brief that supports the decision
A useful brief answers a small set of operational questions. Which person is this? Which job is being proposed? What evidence supports the match? What information is missing? Which state change will happen if the recruiter proceeds? Keep the answers short enough to review beside the source profile.
- Resolve the existing person before proposing any new record.
- Show the current prospect context and the proposed job separately.
- Attach the relevant source evidence and its observation date.
- Separate observed facts from inferred suitability.
- Let the reviewer accept, change or reject the proposal.
- Recheck the current job and profile before applying the accepted action.
Do not pad the brief with unsupported claims about interest, availability or consent. If an email says the person wants to learn more, preserve that wording rather than turning it into a claim that they applied. This is the same evidence discipline needed in broader AI recruiting agent deployments.
Test state changes and uncertain outcomes
Test an attached prospect, an unattached prospect and a profile already being considered for the target job. Include a reviewer with insufficient permissions and a job that changed after the brief was prepared. The workflow should explain why it stopped rather than inventing a successful conversion.
For any custom integration, record the intended action before execution and reconcile the resulting state afterward. If a request times out, keep its result unknown until an authorized read or manual check resolves it. Do not create another person or repeat a transition simply because the first response was missing. This action journal is an application responsibility, not a native guarantee described by the conversion help page.
Common mistakes to remove before rollout
- Counting researched prospects as interview candidates in an internal dashboard.
- Mapping every interested pool stage into an interview stage without checking the job.
- Giving reviewers a summary of profiles they should not be able to access.
- Calling a model's recommendation an application from the person.
- Retrying an uncertain write without checking what happened.
Review these cases with the recruiting operator who owns the process. A clean technical test is incomplete if the operator cannot explain the state shown in the ATS. For database cleanup before rollout, use the same identity checks described in our ATS database reactivation guide.
How Remqa can help
Remqa builds custom recruiting AI workflows around the tools your team uses. A scoped implementation can cover prospect review briefs, job mappings, permission checks and action reconciliation. Start with one pool and one transition rule. Bring a recruiting operator and a few representative profiles to a recruiting workflow conversation so the first design reflects the decisions your team actually makes.