Learn how Candidate Statuses control actions, visibility, notifications, and workflow progression
A Candidate Status identifies a candidate's current position within the hiring workflow. As candidates move through workflow steps, their status changes to reflect where they are in the evaluation, interview, offer, and approval process.
Candidate Status records define the actions users can perform, control candidate visibility, and influence workflow-driven behaviors such as interview notifications. Candidate Statuses work closely with hiring workflows and should be reviewed whenever candidate workflow behavior changes.
Why it matters
- Controls candidate workflow progression.
- Determines which actions are available to users.
- Influences candidate visibility throughout the hiring process.
- Supports interview, offer, and candidate-management workflows.
Who it's for
- Program Office users
- System Admins
How it helps
- Understand how Candidate Status records are managed.
- Control candidate actions and status transitions.
- Configure candidate visibility.
- Support hiring and approval workflows.
How it works
Candidate Statuses help manage candidate progression throughout the hiring lifecycle and support key hiring activities. A Candidate Status can control what users can do, who can view candidates, and how candidates move through workflow-driven processes.
Each Candidate Status includes a name, an active or inactive state, and a set of Allowed Actions that determine how candidates can be managed while they are in that status. Together, these settings control candidate progression, visibility, notifications, and workflow behavior.
Candidate Status capabilities
| Capability | Purpose |
|---|---|
| Allowed Actions | Controls which actions users can perform while a candidate is in a status. |
| Visibility Rules | Controls which users can view candidates in a status. |
| Interview Notifications | Controls whether interview reminders are generated. |
| Workflow Integration | Allows statuses to be assigned and updated during workflow processing. |
| Status Lifecycle Management | Controls how statuses are created, maintained, and retired. |
Where Candidate Statuses are used
| Related component | Relationship |
|---|---|
| Candidate Workflows | Candidate Statuses are assigned as candidates move through workflow steps. |
| Workflow Approvals | Candidate Statuses can be assigned when workflow steps are approved or rejected. |
| Interview Scheduling | Candidate Statuses can control interview reminder behavior. |
| Candidate Visibility | Candidate Statuses determine who can view candidate records. |
| Candidate Actions | Candidate Statuses determine which actions are available to users. |
Managing Candidate Statuses
Candidate Status records can be created, updated, and retired as hiring requirements evolve. Workflow associations are managed separately and require coordination with Beeline through the JIRA process.
| Activity | Process |
|---|---|
| Create a new status | Create the Candidate Status record and submit a JIRA ticket so Beeline can associate the status with applicable workflows. |
| Edit an active status | Update the Candidate Status and create a JIRA ticket to document the change. |
| Deactivate a status | Create a JIRA ticket so Beeline can verify that the status is not associated with an active workflow condition before it is deactivated. |
Workflow integration
Candidate Statuses are not automatically available in workflows. When a new Candidate Status is created, a Beeline administrator must associate it with the appropriate workflow steps. This requires a JIRA ticket and coordination with Beeline.
Candidate Statuses can be assigned in workflows using the following status assignments:
| Workflow status assignment | Purpose |
|---|---|
| Pre-step Status | Candidate status applied before a workflow step begins. |
| Approved Status | Candidate status applied when a workflow step is approved. |
| Rejected Status | Candidate status applied when a workflow step is rejected. |
Candidate actions
Each Candidate Status includes an Allowed Actions section that controls which actions are available while a candidate is in that status.
| Allowed Action | What it allows |
|---|---|
| Resubmit Candidate | Allows users to resubmit a candidate. |
| Withdraw Candidate | Allows users to withdraw a candidate. |
| Reject Candidate | Allows users to reject a candidate. |
| Schedule Interview | Allows users to schedule interviews. |
| Submit Offer | Allows users to submit offers. |
| View w/o All Visibility | Controls candidate visibility for users without All Visibility access. |
| Is Included in Open Bid | Controls candidate participation in Open Bid activities. |
| Modify Background Check | Allows background check modifications. |
| Send Interview Notification | Controls interview reminder notifications. |
| Withdraw Offer | Allows users to withdraw offers. |
Important behavior
Candidate visibility
| Setting | Behavior |
|---|---|
| View w/o All Visibility = Enabled | All roles can view candidates in the status from Manage/Search Candidates and the Candidates tab on a Request. |
| View w/o All Visibility = Disabled | Only users with All Visibility permissions can view candidates in that status. |
This setting is commonly used for Submitted statuses so Hiring Managers do not see candidates until screening activities are complete.
Interview notifications
| Setting | Behavior |
|---|---|
| Send Interview Notification = Enabled | Interview reminder notifications are generated according to the configured notification schedule. |
| Send Interview Notification = Disabled | Interview reminder notifications are not sent, even when interviews are scheduled. |
Final workflow statuses
Take care when configuring final workflow statuses.
Final statuses can be assigned:
- On the final approval task in the workflow.
- Within approval and rejection notifications.
Workflow conditions should be reviewed carefully when assigning final statuses. Incorrectly conditioned workflow steps can result in unexpected status behavior, particularly when assigned users are undefined or inactive.
Additional considerations
- Use clear, descriptive status names.
- Review existing Candidate Statuses before creating new ones.
- Evaluate workflow impacts before creating, modifying, or deactivating statuses.
- Document status changes through the JIRA process.
- Verify workflow conditions when assigning final statuses.
Availability and setup
- Access to Admin > Procurement > Candidate Statuses is required.
- Workflow integration requires assistance from a Beeline administrator.
- New workflow associations require a JIRA ticket.
Learn more
- Workforce procurement configuration reference
- Request types and burned-in settings
- Associate suppliers with an Industry
- Create a request template
- Workflow administration
| Persona Program office users | Modules Administration | Documentation release Beeline Enterprise | Q3 2026 | Feedback? Email us: |