Hiring permissions and states

Hiring combines organization-wide capabilities with assignments on an individual job. The narrowest role that supports the work should be used.

Personal profile access

The signed-in platform user’s /personal-profile routes are user-scoped and do not require an organization selection. They still require Hiring to be enabled for that user. This My profile is separate from a Talent portal applicant account and its job applications.

Organization access

Role	Jobs	Organization-wide applications	Hiring settings
Organization member	View and create jobs; edit, publish, or close only jobs they created or where they are a hiring manager or job admin	View; cannot change statuses or Kanban	No
Organization admin	Manage every job	Manage	Manage
Guest	No Hiring access	No	No

Hiring must also be enabled for the signed-in user account. If it is not enabled, Hiring routes are unavailable even when the person belongs to the organization.

Organization settings use separate capabilities. Team, Email templates, Scorecard templates, Notifications, and Connector settings are shown independently, and only to a user who can manage that setting. Organization admins receive those organization capabilities.

Job-team access

Assignment	Edit job	Manage job team	Review applicants
Reviewer	No	No	Yes
Hiring manager	Yes	No	Yes
Job admin	Yes	Yes	Yes
Job creator	Yes	Yes	Yes
Organization admin	Yes	Yes	Yes

A plain organization member who did not create and was not assigned to an existing job cannot edit, publish, or close that job or review its applicants. Organization-wide applicant status changes and Kanban moves require permission to manage applications.

Organization members can open rapid review and see its candidate cards. Recording Advance, Maybe, or Reject, setting a rating, and saving a note are checked separately against review access for each card’s job. On an organization-wide stack, a card from a job you cannot review remains visible but its mutation controls are disabled.

Hiring team pool

An organization admin uses Team to maintain a pool of organization members who can be assigned to jobs. A job admin, the job creator, or an organization admin can assign pool members as reviewer, hiring manager, or job admin; a hiring manager sees the job team without managing it. The page presents these access labels:

Access	Current behavior
Standard	Can be assigned to jobs; the role on each job controls what the member can do there.
Limited	The UI describes this as view-only, but the current assignment flow does not enforce that distinction. A Limited pool member can still be assigned to a job, where the per-job role grants its capabilities.

This pool does not replace organization membership or the per-job assignment. Removing a person from Team also removes that pool row’s job assignments, and the job editor prevents removal of the last assigned job admin. Creator and organization-admin capabilities do not depend on an assignment row. Removing a creator from Team is therefore not a durable restriction: if that organization member creates another job, Hiring re-adds them as Standard, assigns Job admin, and makes them the contact person. There is currently no enforced Team-level view-only boundary, so use the organization’s membership controls when Hiring access must be prevented.

Job lifecycle

State	Public discovery	Open or refresh application wizard	Typical next action
Draft	Hidden	No	Complete the job, then Publish.
Published	Listed	Yes	Review applicants or Close the job.
Paused	Hidden from listings; direct detail remains readable	No	Change the state in the connected ATS.
Closed	Hidden from listings; direct detail remains readable	No	Keep the recruiting record for reference.

Direct jobs have only the local transition Draft → Published → Closed. There is no local pause or reopen action. Paused is used for an upstream ATS state and must be changed there. Close is locally one-way, and the organization’s Jobs list initially hides closed records with a removable Status ≠ Closed filter.

A direct public link to a paused or closed job remains readable and displays This job is not currently accepting applications. A draft public detail is unavailable.

Job state is checked when Talent opens or refreshes the application wizard. The current final-submit action does not repeat that check for a wizard already open in the browser. Close prevents new entry; it is not an atomic cutoff for every in-flight wizard.

Shared applicant pipeline

Hiring uses these shared statuses:

Hiring status	Talent application detail shows
New	Submitted
Screening	In review
Interview	In process
Offer sent	Offer sent
Accepted	Hired
Rejected	Rejected
Withdrawn	Withdrawn
Talent pool	Kept on file

Other in-progress states are presented as In process on the application detail. Cards on Talent portal Home and Applications show Submitted for New, but otherwise retain the Hiring pipeline label. The detail page is the applicant-facing progress summary.

For an imported application, Stage is the current value from the ATS. The shared Hiring Status initially follows that stage. The first local status selection or Kanban move stamps local ownership permanently: later syncs continue to update Stage but do not overwrite Status, and the local status is not pushed back to the ATS.

Rapid-review decisions

Advance, Maybe, and Reject are reviewer assessments, not shared pipeline statuses. A review can also contain a one-to-five rating and a private note of up to 2,000 characters. Skip leaves the application undecided. During one visit, Undo reopens only the latest decision recorded in that visit; refreshing starts a new visit and clears that in-memory undo history.

Saved applicant layouts

Hiring remembers the table or Kanban layout selected for an applicant browser. An explicit layout in the page URL takes priority; otherwise a valid saved preference is restored when the browser opens without layout state.

Older non-empty saved applicant layouts receive Applied on once:

• table layouts place it after Email when that field is present;
• Kanban layouts place it after Candidate country when that field is present;
• if the expected neighbor is absent, the field is added at the end;
• existing fields and saved widths are preserved;
• the default newest-first ordering does not change;
• you can hide Applied on again.

An empty saved preference is not converted into a customized layout.

Synchronized job boundary

A job synchronized from a connected applicant tracking system is owned by that system. Hiring identifies it with This job is synced from the connected ATS and is managed there. Edit still renders and opens the local form, but saving cannot update the synchronized job. Publish and close controls are disabled or their server actions reject the change. Edit, publish, and close the job in the connected system.