Everything that has shipped, and what it cannot do

Every email a candidate received from you arrived in Recruit Buddy's own design: our header image, and at the foot our postal address, our support address, our telephone number and our privacy policy. A candidate who wrote to the footer reached us, not you. Email to people outside your workspace now goes out in your brand instead. Your logo heads the email, or your workspace's name when there is no logo. The button is in your brand colour, with black or white text, whichever reads better on it. The foot holds your name, a footer text of your own (your registered name, your postal address, any legal line), your website and a link to your privacy notice, and the text version of the email ends with the same lines. Nothing of ours is in it. This covers every email your templates send (acknowledgements, interview invitations, offers, rejections, bulk emails, automation emails and campaigns to a talent pool), job alert confirmations and digests, requests to referees and the adverse action notices of a background check. The logo, colour, website and privacy notice are the ones your careers site already uses, so nothing is set up twice. The footer text is new: an admin or owner writes it in Settings, Email templates, under Email branding, where a preview shows a sample email in your brand as it is saved. The brand is read when each email goes, so one held for later carries the logo and the address you have then.

One brand per workspace: an extra career site's own logo and colour do not change its emails. A logo uploaded as an SVG shows in email as your name in text, because mail programs do not draw SVG images; upload a PNG or JPEG to have the logo there too. The footer is plain text, up to 8 lines and 600 characters. Emails are still sent from Recruit Buddy's sending address, under your workspace's name. Email to your own team (notifications, interview panel invitations, internal job alerts) and account email keep the Recruit Buddy design.

A person could have one application per job, for good: someone turned down in January who applied again in June got no new application, and nothing new reached you. Now, when every application they made for a job has ended (rejected or withdrawn), they can send a new one. It is a new application, not the old one reopened: it starts in the job's first stage with its own answers, CV, screening and interviews, and the earlier one keeps its history. It works wherever people apply: the careers apply form, an Apply again link beside an ended application on the candidate's status page (in each of the five careers languages), the internal job board, an agency's portal, text to apply and the API. It starts switched on in every workspace, existing ones included, and an admin can turn it off in Settings, Careers site, under Applying again. Your team can always put a past applicant back on a job, with Add to job on their page, whatever the switch says. If the rejection email for their earlier application is still waiting to go when your team does that, it is cancelled, and the screen says so, so nobody is told no for a job they are back on. An application that follows an earlier one is marked Applied before on the pipeline and on the candidate's page, saying how and when the earlier one ended, with a link to it, and its timeline starts with Applied again. Each application keeps its own offers, numbered from version 1, so the Offers list shows the date of the application an offer belongs to once someone has applied for the job more than once. A referral is credited with the outcome of the application it was made for, never with a later application's hire. In the API, POST /api/v1/applications answers 201 with reapplied: true and previousApplicationId for such an application, where it used to answer 200 with the earlier one, and every application.created webhook now carries reapplied and previousApplicationId.

Someone with an open application for a job can never send a second one, and nobody applies again after being hired. A rejection the candidate has not been told of yet, because its email is still held, counts as an open application until the email goes, on every form and in the API. With the switch off nothing is created: the form answers as it always has and the attempt is written to the earlier application's timeline, so you can reopen it. An earlier application cannot be reopened while a newer one for the same job is open. The status page offers Apply again only while the job is open on your public careers site and taking applications. With AI autopilot on, the AI never moves forward someone who applies again after your team rejected them for that job: its recommendation waits in the Decision Inbox for a person, marked as someone who applied before. An earlier application the person withdrew does not hold the new one back. A referral from a recruiter or an admin counts as your team putting the person forward; a referral from anyone else follows the switch, and while it is off the job's recruiter is told that the referral was not added. A CSV import into a job never starts a second application: it updates the person's details and lists everyone in the file who had applied for the job before, each linked to their page.

When an interviewer is ill or declines the invitation, the room is wrong, the meeting link was mistyped or a phone call becomes a video call, a booked interview had to be cancelled and booked again, which sent the candidate a cancellation and a second invitation for the same hour. An interview that is booked, or offered to the candidate and not yet picked, now has Edit details beside Reschedule, for whoever may move it: change its name, the type, the location, the room, the meeting link and who is on the panel, with the time left as it is. On a booked interview, everyone on the new panel gets an updated calendar invitation that replaces the entry they hold, the people added get a feedback task, and the people taken off get a cancellation for their own calendar and owe no feedback. People you add are checked against their calendars at the interview's time, with Book anyway when the clash is intended, and they join the job's team if they were not on it. The candidate is emailed the new details with an updated calendar invitation when the name, type, place or link changed and Tell the candidate is ticked. One part of a back-to-back loop can be edited on its own, since its time does not move. A panellist whose connected calendar shows they declined the invitation is marked Declined on the interview lists and Declined invite on the interview's page, and for someone who may change the interview that mark opens Edit details.

The time and the length are changed with Reschedule, not here. Only before the interview starts, and only while its application is open. A room already booked at that time is refused, and nobody can override that. Someone who has already submitted a scorecard for the interview stays on its panel. Candidates are never told who is on the panel, so a change of panel alone sends them nothing.

When a job is filled and its runners-up would suit the one that opened this week, putting them on it meant opening each person and pressing Add to job. A job's pipeline now has Add to another job in the bar that appears when you select candidates, and on the Closed applications list, where you tick the people that job did not take. Candidate search has the same control, Add to a job, so it works for a talent pool or a saved search too. Choose the job, choose which of its locations the applications are for when it is open in several, and press Add. Each person gets a new application in that job's first stage, added by you with the source Sourced and screened like any other, and the application they were picked from is left exactly as it is. Nobody is put on a job twice: someone who already has an open application there is counted and left alone, and someone whose earlier application for that job ended gets a new one, marked Applied before. The result says how many were added and why anyone was not, with a link to the other job's pipeline.

Hiring managers and above, for candidates they can change, onto a job they can manage that is open, paused or still a draft and has a pipeline. Up to 200 people at a time. Anonymised candidates, and anyone who has asked for their data to be deleted, are left out with the reason. If the job reaches its limit on open applications the run stops there and says who was not added. Answers to the first job's questions are not copied, and the applications have no location unless you choose one.

When someone is in your workspace twice, under a work address and a personal one, you merge the two records from the candidate's page. A merge used to keep one application per job: where both records had applied for the same job, the duplicate's application stayed behind on the hidden record, with its interviews and scorecards. A merge now brings every application across, each with its interviews, scorecards, answers and requests. Two applications for the same job sit side by side on the merged record as that person's history, and the newer one is marked Applied before. Only when both are still open does one have to give way: the one further along stays open (a hire beats an application still in the pipeline, and between two in the pipeline the later stage wins), and the other is closed as withdrawn with the note Merged duplicate and kept on the record. The merge dialog says this before you confirm, and afterwards how many applications moved over and how many were closed.

Recruiters and above, for two records they can both change. If both records were hired for the same job, the merge is refused with nothing changed until one of the two hires is undone from its hire record. If an application on either record is opened in the same moment, nothing is merged and you are asked to try again.

A recruiter adds a person to a job (Add to job, Add candidate, an import, a colleague's referral, an agency's submission), and the person then finds the job on your careers site and fills in its apply form. They already have an open application for that job, so no second one is created, and until now what they sent went nowhere. The first time the form arrives for such an application it now completes it: their answers to the job's questions and their cover letter are stored on the application, knockout answers are judged as they would be on a new application, the CV they attached is tied to it, the location they chose is kept, and the AI screens it again on what they actually said. The timeline says they sent the form themselves, the application's owner and the job's recruiter are notified, and the person gets the same acknowledgement email as any applicant, with their status link.

Only the first form, and only for an open application that your team or an agency started. Someone who applied themselves and sends the form again is a double submit, as before, and so is an internal application. If the application already holds answers or a cover letter it is kept exactly as it is: the CV they sent is still added to it, and the timeline says why nothing else was.

Nobody sees their own candidacy in Recruit Buddy, whatever their role: not the screening, the notes, the interviews or an offer. A record counts as yours when you applied from the internal job board, and also when the workspace holds it under your sign-in address, however it arrived: a colleague added you, you applied on the careers site, an import or an agency brought you in, you accepted an invitation under the address you once applied with, or you changed your sign-in address to it. The screens used to show nothing where such a record would be, which read as a record that had gone missing. They now say what happened. Adding a candidate under your own address answers Added, and hidden from you. The candidates list and a job's pipeline carry a line when a record or application of yours is left out. A CSV import that held a row with your address says so in its report. Opening the record's link shows a page that explains it is your own, with a link to Internal jobs, where your own internal applications and where they stand are listed.

You cannot lift this for yourself: a colleague with access works on your record. A record that someone else is already linked to, or that has been anonymised, is left as it is.

A rejection email is held for a day or longer before it is sent, and reopening the application cancels it. That cancel finds the email through the template it was written from. If an admin deleted that template, or moved it to another kind, while the email was still waiting, Reopen found nothing to cancel, and a candidate you had put back in the pipeline was told days later that they were not being taken further. Settings, Email templates now refuses to delete a template, or to change its kind, while any email written from it is scheduled or queued, and says how many are waiting.

Once those emails have gone or been cancelled, the template can be deleted or moved as before. Editing its words is never blocked: an email that is already waiting keeps the text it was written with.

When a candidate asks that no AI evaluates them, Recruit Buddy withdraws what the AI had left waiting, clears the AI score from their applications and shows your team only that they asked. GET /api/v1/applications/{id} still returned latestDecision for such a candidate when a screening had run before they asked, with its recommendation, score and summary. It is now null for them, so a dashboard or a tool built on the API shows a reviewer no more of the AI's read than the console does. humanReviewOnly, on every candidate the API returns, says who made that choice.

Only latestDecision changes, and only for candidates whose humanReviewOnly is true. For everyone else it is returned as before, and it is null for an application that has not been screened.

Some HTTP clients put a byte order mark in front of the JSON they send; a .NET writer created with its standard UTF-8 encoding is the common one. Every write endpoint of the API (creating jobs, candidates and applications, moving and rejecting an application) answered such a request with 400 invalid_json, although the JSON itself was valid. The mark is now ignored and the body is read as the JSON it is.

A candidate who accepts an offer conditional on checks is not hired yet, and until now the team could not take that offer back. To change its terms while the checks ran, someone had to reject the application, wait for the offer to be withdrawn, reopen the application and revise, which told every connected system that the candidate had been rejected. The offer's page now has Rescind offer for this case, for hiring managers and above who can change the offer. Rescinding withdraws the offer and leaves the application where it is, with its checks carrying on. The candidate's offer link says it was withdrawn at once, an agreement sent with the offer that they have not signed is withdrawn with it, and you choose whether to email them, with a message you can edit first. The recruiter's task to mark them hired is closed, the timeline records who withdrew the offer, and the offer's author and the job's hiring manager and recruiter are told. The closed version keeps the candidate's acceptance on record, and Revise on its page starts the next version from its terms. On Analytics it still counts as accepted on the day the candidate answered, and the offer figures now name this as one of the three ways an acceptance is withdrawn afterwards. For connected systems there is a new webhook event, offer.rescinded, sent whenever someone rescinds an offer from its page, this kind or one the candidate had not answered. It carries the offer, its version and afterAcceptance, which is true when the candidate had accepted, so a system that acted on a conditional offer.accepted knows that acceptance no longer stands.

Only an offer accepted conditional on checks, while its application is still open. An offer accepted outright is a hire, which is undone from the hire record. If a check did not clear, use the adverse action steps on the check instead: they close the application and withdraw the offer in the order the law expects. A rescinded offer cannot be reopened. An endpoint that lists its events needs offer.rescinded ticked to hear it: Settings, Webhooks marks the endpoints that hear offers accepted without it. The event is not sent when an offer closes with its application (rejected, withdrawn or a hire undone): the application's own event says so, as before.

Someone applying by text is now told what the careers form tells every applicant. When your workspace uses AI to help review applications, the first text of the conversation says so, says that a person makes every decision to decline, and ends with Reply HUMAN for a person-only review. Replying HUMAN works at any point: before they have given their name and email, between questions, and for a day after their application went in. Their application is then reviewed by people only. The AI does not screen it, and if it already had, its recommendation is withdrawn and its score is cleared, exactly as when a candidate ticks the same choice on their status page. They get a text confirming it, and the candidate's timeline says they asked by text. The notice and the keyword follow the language of the conversation, in each of the five careers languages, and the notice is given again when the person switches language.

Nothing is added to the first text when AI is switched off for the workspace. A text can turn person-only review on, never off: the candidate changes it back on their status page. A reply that is one of the current question's own answers is read as the answer.

A kiosk or a job board form that sends applications through the API can show your AI notice with the choice of a person-only review, and until now had nowhere to send the answer, so the AI screened every application an integration created. POST /api/v1/candidates now takes humanReviewOnly: send true for someone who asked that no AI evaluates them, before you create their application, and it is reviewed by people only. The candidate's timeline says the choice came through the API, and by which key. Every candidate the API returns carries humanReviewOnly, so your system can see that the choice was kept.

The API turns the choice on and never off: false, null or leaving it out changes nothing, so a choice the person made on the careers site or their status page is never undone. Send it before POST /api/v1/applications, which queues the AI screen as soon as the application exists. Sent afterwards, it withdraws the AI recommendations still waiting for review and clears the AI score from their applications.

Automation rules run a moment after the event that starts them, and now and then a few minutes after. If a hire was marked by mistake and undone in that gap, the A candidate is hired rules still ran when they caught up: the team was notified, first-day tasks were created and the welcome email went to the candidate. A hire rule now checks that the hire still stands when it runs. If it was undone, the rule does nothing and its run history says why: Not run: the hire was undone before the rule ran. If the candidate was hired again in the meantime, the rules run once, for the hire that stands. Rules that start when an offer is accepted do the same for an acceptance that was withdrawn before they ran.

This covers rules that had not run yet. A task a rule had already created stays until someone closes it, and an email it had already sent has gone.

On a job open in several locations, the work location is one of the terms an approver reads on an offer. It could still be changed from the candidate's page after the offer was submitted or approved, and the offer was then sent for a place no approver had seen. While an offer on the application is waiting for approval or approved, changing or clearing that location is now refused with the reason, as it already was for an offer the candidate holds. Revise the offer to change it, and the revision goes back for approval like any other term.

A draft offer does not hold the location. A location that is missing, or no longer one of the job's places, can still be chosen on the offer's page. After the offer is accepted the location can be corrected, which never changes what the signed offer says.

Settings, Departments and locations offers Delete only for a location nothing refers to, and that test did not count applications. Deleting a location a job was no longer open in cleared it from every application and hire that was for it, and their hire records and hand-offs to HR then showed the job's main location instead. A location is now also kept while any application or hire is for it: Delete is not offered, and Archive takes it out of the pickers without changing anything that uses it.

An application that lost its location to an earlier deletion is not restored: set it again on the candidate's page or the hire record.

A hire used to be final. When a new starter backs out, does not turn up, was marked hired on the wrong application, or needs different terms after signing, the hire record now ends with an Undo this hire panel, for hiring managers and above who can change the application. It lists everything that will happen before anything changes, and asks why: Candidate backed out, Did not start, Hired by mistake, Renegotiating the offer, or Other with a note. The candidate goes back to the stage they were hired from (the job's last open stage, if that one has gone) as an active application, and no longer counts as a hire in Analytics. The offer they signed is closed as Withdrawn after acceptance and stays on record with its signature; Revise on its page starts the next version from its terms. The hire record is removed, and its start date, manager, employee ID and export date are written to the candidate's timeline. A referral credited with the hire goes back to in process. Emails and texts held for later on that application, such as a welcome an automation rule scheduled for the new starter, are cancelled, so they never reach someone who is not joining. On a filled job, someone who may publish it can tick Reopen the job in the same step. The job's recruiter and hiring manager, the manager named on the hire and the offer's author are told. For your HR system there is a new webhook event, application.hire_undone, with the reason and the stage the application is back in, so a system that created an employee from application.hired can cancel it.

The notes for HR and the onboarding checklist are not kept. Other applications of theirs that the hire withdrew stay withdrawn, and pre-boarding requests still open stay open: reopen or cancel them from the candidate's page. An agreement sent with the offer that they had not signed is withdrawn. The return runs no stage rules and sends the candidate nothing. A referral bonus already marked paid keeps its date, to take up with payroll. Recruit Buddy tells an HR system only through the webhook, and an endpoint that lists its events needs application.hire_undone ticked: Settings, Webhooks marks the endpoints that hear about hires without it. The hire of an anonymised candidate cannot be undone, and there is no API call to undo a hire.

The decisions waiting line in the sidebar, the Decisions waiting card on Today and the decision rows under Needs you counted every AI recommendation on a candidate you could open. That included a candidate a colleague had shared with you for a second opinion: you can read a shared candidate, not change them, so the number led to a card where Accept answered that the application is not on one of your jobs, and it stayed on every page until someone else dealt with it. The three counters, and the Decision Inbox they open, now show only the recommendations you can accept or override: the ones on your own jobs, from the stage your role sees.

Pipeline health on Today still shows how long a decision has waited on each job, whoever can act on it. A recommendation on a candidate shared with you can still be read on the candidate's page, without the Accept and Override buttons.

A job can show its hiring managers and interviewers only the candidates who have reached a stage, such as Interview. When a recruiter booked one of them on an interview with an applicant who was still before that stage, the rule hid the very candidate they were invited to meet, so they could not read the application and could not give the feedback they owed. Someone booked on an interview now reads that application for as long as the interview is offered, booked or held. Handing over work follows the same rule: when you remove a teammate with a successor, or use Reassign work, their seat on such an interview moves to a hiring manager or interviewer who is on the job, together with the tasks about that candidate.

Reading only: the seat does not let them move, reject or message the candidate, and that candidate's AI recommendation is not theirs to accept. A cancelled interview, or one the candidate did not attend, opens nothing, and the job's other applicants before the stage stay hidden.

When a job is open in more than one place, its apply form on your careers site starts with Which location are you applying for? The applicant picks one of the job's locations, or Any of these where every location asks the same of an applicant. A link that already names a place, such as your job board filtered to York, a careers site of yours for York or a job board's York listing, opens the form with York chosen. Text to apply asks the same question last, with a numbered list to reply to, or by name when the list is too long for one text. The internal jobs board asks it too, as an optional choice. Where a job spans countries, the application terms and the voluntary self-identification questions shown are those of the place chosen.

A job with one location asks nothing and its form is unchanged. Any of these is offered only when every location has the same application terms and self-identification questions; otherwise the applicant picks a place. It is stored as no location chosen, with a line on the candidate's timeline saying they would take any. People who arrive without the question (an agency submission, a referral, someone added by hand) have no location until you choose one on their page.

On a job open in several locations, each application says which one it is for, and the pipeline now shows it. A card on the board carries a pin naming its location, the table has a Job location column beside the stage, and both views have a Job location filter listing every place the job is open in, plus Not chosen. A store manager filters to York and sees York's applicants, and the bulk actions then act on exactly those. On the candidate's page the application shows its location with a Change link for hiring managers and above on the job, and every change is written to the candidate's timeline.

Only on jobs open in more than one location. Not chosen means the applicant was not asked or said any location would do: offers and the hire record then read the job's main location. The location cannot be changed while an offer is with the candidate: revise the offer instead. A location the job has stopped being open in stays on the applications that chose it, marked, until you change it. Blind review does not hide the location, since it names nobody.

On a job open in several locations, an offer now says which one it is for. The offer builder has a Work location field, and an offer cannot be submitted for approval or sent until one of the job's locations is chosen, so someone who applied for York is never offered the job's main location by default. The location shows on the offer's page, on the candidate's own offer page, among the terms of the printable letter and wherever a letter uses the {{offer.location}} field. Offers for many candidates at once take a work location for each candidate. After the hire, the hire record has the same Work location under Details, and it goes to HR as job_location in the export and in the application.hired webhook.

A job with one location has nothing to choose and reads as before. An offer that has been sent keeps the location it was sent with: revise the offer to change it. Changing the location on the hire record afterwards changes the record and the hand-off to HR, never what the signed offer says.

The XML job feed of your careers site, the one job boards read, now carries a job open in several locations as one listing per location, the way a board lists a role in several cities. Each listing has that place's city, region, postcode and country, and the link of a further location opens the job with that location already chosen on the apply form. The feed of a careers site of yours that is set to certain locations lists the job only under the places inside them: a York site's feed shows a Leeds, York and Hull job under York alone. The JSON list of jobs keeps one entry per job and adds every place it is open in.

The main location's listing is the one the feed always carried, with the same reference and link, so a board keeps the listing it already has. A job with one location is listed once, as before. The feed can be cached for fifteen minutes, so a location you add appears within that time.

On a job open in several locations, an application can say which one it is for. Every application the API returns now carries location, with the id and name of that place, or null when none was chosen. POST /api/v1/applications takes locationId, so a kiosk in one store, or a connector posting a twelve-store job, sends the store the candidate picked: use the id of the job's location or of one of its additionalLocations.

An id the job is not open in answers 422 and nothing is created. Leave locationId out, or send null, when nobody chose: the application then counts for the job's main location. Posting an application for someone who already has an open one for the job returns it unchanged, its location included, and the API does not change an application's location afterwards: that is done in the console.

A job has its main location and a new Also open in list for every other place it hires in, on the job's Details tab, in the Role Builder and on the requisition form. A retailer hiring store assistants for twelve stores keeps one job, one pipeline and one set of reports instead of twelve copies. The job is found under each of its locations: in the jobs list, on your careers site's board and its search, on a careers site of yours that is set to certain locations, in job alerts, in similar jobs, on the internal jobs board and in the API. The job's page and its printable poster name every place. A job opened from a requisition starts with the requisition's locations, and a question set you attach to new jobs in a location is added when the job is open there, as its main location or as one it is also open in.

Choose the main location first: Also open in adds to it. Up to 200 further locations on one job. It stays one job with one pipeline, so open separate jobs when each place needs its own stages or its own hiring team. A location you delete later drops out of the list.

The email composer has an Attach files button: a job description, a benefits guide, a form to bring. It is there wherever you write to candidates: on a candidate's page, in a bulk email from a job's pipeline, to the people registered for an event, and on Invite to apply. An email to many people gives every recipient the same files, and an email scheduled for later keeps them. The candidate's message history lists what went with each email, where whoever may read the email can download the files, and the timeline entry for the email names them.

Up to 3 files, 7 MB together: PDF, Word (.docx or .doc), RTF, plain text, PNG or JPG, checked by what the file really is, not by its name. Email only: a text cannot carry a file. Interviewers see the file names but cannot download them, and an anonymised candidate's emails list none.

Every open, public job has a QR code that opens its page on your careers site. On the job's Posting tab, Printable poster opens a sheet for a shop window, a staff room or a stand, with your name, the job title, where it is, the pay when the ad shows it, the code, the job's address written out for anyone without a camera, and the text-to-apply line when texting is on; Download SVG gives the code alone for your own artwork. The job's overview carries a small copy of the code. Settings, Careers has a Scan to see our jobs code for your careers home and one for each of your other career sites. Every code's link ends in ?source=qr, so people who scan and apply are credited to the QR code poster in the source and conversion reports.

A job has a poster only while a scan would find its page: the careers site is on and the job is open, public and before its closing date. Otherwise the Posting tab says why, and the careers site codes are offered only while the careers site is on. A code keeps working while the job keeps its careers address; if the job closes, a scan opens a page saying it may have closed, with a link to your open jobs.

A job's Questions tab starts with a new Standard fields panel. Set the CV and the phone number to Required, Optional or Not asked, and the LinkedIn profile, the website or portfolio and the cover letter to Optional or Not asked. A shop floor or seasonal role can drop the CV and hire on the answers; a role you arrange by phone can require the number. The careers apply form shows exactly those fields and enforces them: a required CV or number must be there, and anything sent for a field the job does not ask is not stored. Copying a job copies its setting.

Name and email are always asked. A job nobody has changed keeps the standard form: CV required, the rest optional. LinkedIn, website and cover letter can never be required. With no CV the AI screen has less to read, so let the job's questions cover the scorecard. Applications already made keep what they gave.

An event's settings have a new Phone number on the registration form choice, beside the one for the CV. Off leaves the phone box out, and with it the box asking for texts about the event, since there is no number to text. Optional is how the form worked before. Required refuses a registration without a number.

A new registrant's number goes on their record. A number typed by someone already on file is kept on their timeline, not added to their record, until you confirm it is theirs. Walk-ins checked in at the door are not asked.

An automation rule that moves candidates to a kind of stage, or to the next stage, used to pick a stage you had removed from a job when no stage still on the board fitted. The move was then refused, and the rule's run history showed a failed run naming a stage that was no longer there. Removed stages are now left out, so the run is recorded as skipped with the real reason: this job has no such stage, or the candidate is already in the last stage.

Runs already recorded as failed stay as they were. Nobody was moved by them.

When you remove a teammate with a successor, or use Reassign work, the successor becomes the owner of the leaver's candidates and hears their replies. A candidate who had only been shared with the successor used to be handed over too, although a share lets someone read a candidate, not move, reject, message or schedule them, and ends when it expires. Those candidates now stay where they were and are counted in the message, so you can hand them to someone who can act on them. A successor below recruiter who could not take everything is told why, as before.

Tasks about a shared candidate and seats on their interviews still move to the successor, since those only need the candidate to be readable. A candidate on a job the successor takes over in the same step is theirs to own.

A calendar you connect in Settings, My availability is only read while you can be seated on an interview in that workspace. When you leave the workspace or are removed from it, when your role there becomes viewer, or when your account is disabled, the connection is now deleted in the same step, with its stored access and the busy times read from it. Before, that happened within the hour. The privacy policy says so too.

It is not restored if you come back: connect the calendar again from My availability. A calendar you connected in another workspace is untouched unless your account is disabled.

In GET /api/v1/jobs and GET /api/v1/jobs/{id}, a job now carries additionalLocations, the locations it is also open in beside its main one (the Also open in list in the console), each with id and name, and additionalLocationIds, the same list as ids. POST /api/v1/jobs takes them too: by name in additionalLocations, matched ignoring case and created when your workspace does not have the location yet, as location is, or by id in additionalLocationIds. An integration can open one job for twelve stores instead of twelve jobs.

Up to 50 names and 50 ids in one request, and the job needs a main location (location) when either list is sent. An id that is not one of your workspace's locations answers 422 and nothing is created. A location given twice, or the main one, is stored once, and a location deleted later drops out of the list. The API creates jobs; it does not edit one afterwards.

Moving an application into a job's Hired stage with POST /api/v1/applications/{id}/move hires the candidate and, as in the console, withdraws their other open applications in your workspace. The request now takes withdrawOthers: send false to hire and leave the other applications open, as unticking the box in the console does. The API reference now spells out what a hire withdraws, and that the application.withdrawn webhook is also sent for an application withdrawn because the candidate was hired for another job.

The default is unchanged: leave withdrawOthers out, or send true, and the other applications are withdrawn, their open offers rescinded and their emails waiting to send cancelled. It is only read on a move that hires.

Signing up, setting a new password from a reset link and changing your password in Settings, Profile now all ask for at least 10 characters. Before, Settings asked for 10 while sign-up and the reset link accepted 8, so the rule Settings stated was one the other two did not keep.

A password set before this keeps working: its length is checked when it is set, never when you sign in.

In Settings, Email templates, changing an email's kind to one automation rules may not send (Rejection, Scheduling request, Interview confirmation, Offer, Reference request or Invite to apply) is now refused while a rule still sends that email or one of its language versions, and the message names the rule. Before, the change saved without a word and every later run of the rule failed, so candidates stopped getting the email and nobody was told.

Moving an email between Application received, Nurture and General is unaffected, since rules can send all three. A rule already broken by an earlier change still needs another email chosen in it: its run history shows the failed runs.

Someone in a talent pool who asks for their data to be deleted (from their status page or a campaign email's footer), or who says no when asked whether you may keep their details, no longer receives your campaign emails or texts while you act on the request, even if they had agreed to hear about future roles. The campaign composer counts them under Asked for their data to be deleted, a sent campaign counts them as opted out, and Add everyone who clicked to a pool leaves them out. It is checked when the campaign is sent and again as each email or text goes out, so a message already waiting, such as a text held for the morning, is cancelled when the person asks in the meantime.

Campaign messages only: a recruiter's own reply, an interview invitation or an offer still reaches someone who is waiting to be anonymised.

On a job's overview, Past candidates and employees who fit now lets a recruiter settle each match, one at a time or by ticking several. Invite to apply emails each person the job's public link, starting from your workspace's own Invite to apply template (a new kind in Settings, Email templates, which new workspaces start with) or a standard invitation when there is none; you can edit the words and preview them as the first person before sending. Invited people are listed under Invited to apply for 30 days and are not suggested again meanwhile. If they apply for the job in that time, the application is credited to the invitation: the list marks them Applied and their timeline says the application came from the invitation. Not a fit, with an optional reason, stops suggesting someone for that job and the next-best match takes the place; Show dismissed lists them, and Restore puts them back among the suggestions.

Recruiters and above. Invitations go out only while the job is open on your public careers site, so for an internal, confidential or closed job, or one whose closing date has passed, use Add to this job instead. Every invitation must carry the job's link. Nobody who asked for their data to be deleted is invited. Someone a teammate adds to the job after inviting them is listed as Added, not credited, because they did not apply. A Not a fit reason is included if the candidate asks for a copy of their data.

A talent pool that keeps itself up to date from a search removes the people its search added once they stop matching, and never removes someone added on purpose. An automation rule's Add to a talent pool, and Add everyone who clicked to a pool on a campaign, now count as adding on purpose even when the pool's search had already found the person, so a later refresh no longer takes them out. The rule's run history says Kept in the pool when that happens.

Someone a refresh already removed is not put back on its own: the next run of the rule, or adding them again, does that.

In Settings, Email templates, the preview of the Interview confirmed email ended with Need to change it? and nothing after it, which read as a field that does not work. The preview now fills the Link to move or cancel a booked interview field with a sample link, as real confirmations always have.

Get started on the home page and on What's new now opens the sign-up form once. Before, the form appeared and then reloaded a moment later, clearing anything already typed into it. The terms, acceptable use and privacy links under the form now open in a new tab, so stopping to read them leaves the form exactly as you left it.

Going back to a sign-in or sign-up screen with the browser's Back button from the home page, What's new or a legal page loads that screen afresh, so anything typed there before you left it is cleared.

An offer can be marked Conditional on checks while it is a draft, in the offer builder or on Offers for many, and Settings, Approvals can make every new offer start ticked. When the candidate accepts one, through their link or as recorded by the team, they are not hired yet: the application moves to the job's next background or reference stage after the offer stage, the timeline says they accepted a conditional offer, and the job's recruiter gets a task to mark them hired when the checks clear. The offer and candidate pages read Accepted, conditional on checks until then. If the checks do not clear, final adverse action rejects the application, the offer is withdrawn and the team is told. On Analytics such an acceptance still counts as accepted on the day it was given, and Rescinded says how many were withdrawn after a conditional acceptance. Automation rules that start when an offer is accepted skip a conditional acceptance unless the rule ticks Also when the offer is conditional on checks, and the rule's run history says why, so anything that assumes a hire, like a welcome email or planning the first day, belongs on a rule that starts when a candidate is hired. In the API, every offer says whether it is conditional, and the offer.accepted webhook carries conditional: true, so an HR system does not start onboarding early.

The choice can only be changed while the offer is a draft. A job with no background or reference stage after its offer stage keeps the application where it is. The hire waits for a person: nothing marks it when a check comes back. An application closed any other way has its conditional offer withdrawn at the next hourly check. Time to fill measured to an accepted offer leaves a conditional acceptance out once it is withdrawn. The withdrawal sends no offer webhook of its own; the application's rejection or withdrawal does.

Jobs and requisitions have a Team notes panel: shared, dated and signed notes about the role rather than any one candidate, such as intake, what the hiring manager will flex on, sourcing calls and calibration after the first interviews. Everyone who can see the job or the requisition reads and adds them, and a job opened from a requisition lists that requisition's notes too, read-only and labelled. Authors edit and delete their own notes, and the author or a recruiter can pin one to the top for everyone. Type @ to mention a teammate, who is notified.

You can only mention someone who can open that job or requisition, so a note never pulls a person into a search kept from them. Interviewers do not see requisition notes. A note holds up to 10,000 characters. Deleting a note removes its words, and the workspace's Activity log never shows a note's words.

A referee who cannot give a reference can now say so on the reference form, with an optional note, and can ask for their contact details to be removed as well. The check becomes Declined, the reminders stop, and the person who asked for it, the application's owner and the job's recruiter are told to ask the candidate for another referee. Checks has a Declined filter, the CSV shows Declined with the referee's note as the result, and the Checks panel on Analytics shows declines in their own Declined column and counts them as not completed rather than as a request the team withdrew.

Removal clears the referee's email address and the relationship the candidate gave, from the check, the candidate's referee request and the timeline. Their name stays, so the team knows whose reference to replace, and the same address is not asked again for that application. The link works once: after a decline it cannot be used to send a reference. The Declined filter covers the last 90 days.

Settings, Careers has a new choice: Ask new people to confirm job news by email. With it on, someone new who asks to hear about jobs (on the talent community and landing pages, at event registration or check-in, or with the talent community box on the apply form) is emailed a link in the language they signed up in, and gets no campaigns until they confirm on the page it opens. Their candidate page shows the request as waiting until then, and the timeline records when it was asked for and when it was confirmed. It is the confirmed (double) opt-in many EU legal teams ask for.

The link lasts 30 days, and confirming takes a button press on the page it opens, because mail scanners open every link. Sign-ups from the talent community and landing pages still join their talent pool while they wait. People already on file keep their own choice either way. Turning job news on from the candidate's own status page counts as confirmed.

When your workspace requires applicants to accept its application terms for a job's country, someone who texts APPLY with that job's code is sent the job's web apply form instead of being asked the questions by text, since a text cannot show the terms or take a considered acceptance. A text conversation already under way when terms are added ends with the same link, rather than creating an application nobody accepted the terms for.

Jobs whose country has no application terms are applied for by text as before. Internal jobs are applied for inside Recruit Buddy, whose form asks for no terms, so their text conversations are unchanged.

An admin or compliance member who has applied for a job in the workspace no longer finds their own application in the applicant flow log they download from Fairness: those rows are left out, the file ends with a note saying how many and why, and the download's Activity entry records it. Nobody sees their own candidacy anywhere in Recruit Buddy, however senior.

The complete log, with those rows in it, comes from another admin or member with compliance access. Only applications made from the downloader's own account are left out.

Time to fill on Analytics no longer counts the days a job spent paused. When your workspace measures it from the requisition's approval, the days the requisition was on hold come out too, and a day that was both comes out once. Open jobs by age counts days open the same way and notes under each job how many days were taken out. The line under the headline figures and both CSV exports say so.

Pauses are read from each job's history of pausing, resuming, publishing, closing and reopening, and holds from its requisition's history, so jobs paused before this change are measured the same way. A job that a hire filled while it was paused, before this change, counts as paused until it was reopened. A span never comes out below zero days. The median is per job, offer or hire, not divided by the number of openings.

Rules have a new condition, Answers score is at least or at most a number of points: the points a candidate's answers earned on the job's scored questions. A rule can now say "when someone applies with 15 or more, move them to the first screening stage and send them an email", or tell the recruiter when someone reaches the highest possible score. It works with every trigger, including a candidate waiting in one stage. The score is your own points on the answers, not the AI's view, so a rule that reads it may move, email and text the candidate.

An application on a job whose answers carry no points, or that answered no scored question (added by hand, or applied before the questions were written), never matches, whichever way the condition points. No rule can decline anyone, on this or anything else. A rule that also reads the AI's recommendation or score keeps the AI's limits: it may notify, assign, tag or pool, but not email, text or move.

On a job's Questions tab, Score the answers gives each answer to a yes or no or choice question points, from -100 to 100, and the question a weight from 1 to 5, with the highest possible score shown as you type. Each applicant's answers score adds up what their answers earned, and the job's overview ranks its active applicants by it, out of that highest score, whether or not the AI screens the job. Changing the points re-scores everyone who has applied, since the score is worked out from their answers each time.

Only yes or no and choice questions can carry points, and never a question about a protected characteristic, pay or criminal history. A follow-up that was not asked scores nothing, and an applicant who answered no scored question has no score rather than zero. The overview ranks up to 200 applicants. A score ranks; it never declines anyone. Question sets do not carry points: each job gives the questions it copies its own.

Admins can set, on Analytics, when time to fill starts (the job is published, or its requisition is approved) and when it ends (the job is closed as filled, a candidate accepts an offer, or each hire). The headline card names the definition in use, the line under the headline figures spells it out with how many jobs, offers or hires the median covers and who chose it, the CSV says the same, and Open jobs by age counts days open from the same start.

A job with no approved requisition counts from the day it was published. A span that would end before it starts, such as a requisition approved after the hire it is linked to, is left out. Every workspace starts on the standard definition, published to filled.

A rule can start when a check comes back: a referee answers, a background check is marked Clear or Consider, an assessment is marked Completed, or right to work is recorded, for one kind of check or any. Its conditions can read the check's result and an assessment's score. A one-click starter, Reference in: tell the hiring manager, tells the hiring manager when a reference arrives and gives them a task to read it.

A rule that can run on a background check marked Consider may only notify people or create tasks: the adverse action steps stay with a person. A rule acts only on checks that come back after it is turned on. It reads the check as it is when the rule runs: a check cancelled or removed by then starts nothing, one whose result changed by then (a background check marked Clear and then Consider, say) runs nothing for the earlier result, since the new result starts its own rules, and an assessment score corrected in between is the score the rule tests.

A draft job created with POST /api/v1/jobs now gets the question sets your workspace attaches to new jobs (Settings, Questionnaires: every new job, or new jobs in a department or location), knockouts included, exactly as a job created in the console does. Before, those jobs had no application questions, so candidates could apply without your standard right to work or notice questions and a knockout never flagged anyone.

Jobs already created through the API are not changed: add the sets from each job's Questions tab. As in the console, a set that would take a job past 30 questions is left off it.

Analytics has a Checks panel: for references, background checks, assessments and right to work, how many were asked for in the period, how many came back, the completion rate, the median days from request to result, and how many are waiting or overdue right now, with a total across every kind. It follows the page's date, job and department filters, exports as CSV like every other panel, and links to the list of open checks for anyone who can open it.

Totals only: no candidate, referee or result appears, and a background check's outcome is never reported. Cancelled requests are left out of the completion rate. Right to work is recorded when it is done, so it has no wait to measure. Outstanding and overdue count every open check, whenever it was asked for, and a check is overdue once it passes its own due date, which can be changed on the check.

A campaign now records the language its own text was written in. If your careers site's default language changes between scheduling a campaign and its send time, each member still gets the version in their language whenever one was written, everyone else gets the campaign as written with the closing line in that language, and the campaign's page labels each version with the language it is really in. Before, the send read the new default: readers of the new default language could be sent the original text instead of the version written for them, under a closing line in the wrong language. A campaign whose send could not be queued is no longer left on the list as Scheduled when it would never go out: it is taken back out and you are told to try again. The language recorded is the one New campaign had you write in: if an admin changes the careers default while you are writing, Send (and drafting another language from your text) tells you the default changed and asks you to open New campaign again, instead of labelling your text with the new language.

For a campaign scheduled before this change, the language it was written in is read from the record made when it was created; if that record is missing too, your careers default now is assumed, and the page labels the text "As written" where that default cannot be its language. What you wrote is not kept when the default changes under you: copy it before opening New campaign again.

When your careers site is offered in more than one language, New campaign has a tab per language. Write the campaign in your default language, then add a Spanish, French, German or Portuguese version, typing it yourself or using Draft with AI to draft it from the default version and correcting it. Each member of the pool gets the version in the language they applied or signed up in, and the closing line saying why they are hearing from you and how to opt out is in that language too, for emails and texts. Before you send, the count shows how many people read each language, and the campaign's page shows every version that went.

A language with no version sends its readers the campaign as written, in the language it was written in; anyone who never chose a language reads your default language. Versions are written with the campaign and cannot be changed once it is created. Draft with AI is offered only where the workspace's AI policy is not Off, and reads only your default version. The word that stops texts is STOP in every language.

In GET /api/v1/jobs and /api/v1/candidates, customFields now holds only the fields defined in Settings, Custom fields, each as its type (a number as a number, yes or no as true or false), and no longer a deleted field's values or internal job settings. Jobs now carry payPeriod (YEAR, MONTH or HOUR), the period the salary band is quoted per, and translations: the ad in each of the careers site's other languages, flagged needsReview when the default ad changed after it was written. The API reference also now says plainly that a webhook delivery is tried up to five times in all.

A value saved before its field's type or choices changed is returned as it was saved. Language versions are listed for the languages your careers site offers now.

A job set to go live, or to open to the public, on a date that could not be opened at that minute because of a passing fault is now tried again within the hour, instead of staying a draft. Saving custom fields on a job or a candidate now changes only the fields you changed, so a translation of the ad or a go-live time a colleague saved at the same moment is kept, and a candidate whose data was removed meanwhile stays removed. Removing a member whose work goes to a successor no longer holds up new applications and pipeline moves while the hand-over runs.

A go-live refused for a reason (the setup is incomplete, the requisition is not approved, the person who scheduled it can no longer publish) is not tried again: they are told why, as before.

When a candidate accepts or declines by phone, by email, in person or on paper, Record their answer on the offer's page records it with the day they answered and how they told you. It does what their own answer through the offer link does: they are marked hired and sent the agreements you send on acceptance, or the team hears they declined, and you can keep the signed copy with the offer. Note a verbal yes marks an offer they have said yes to before the written offer is out or signed, so the whole team can see where it stands. Offers for many, on the Offers page or a job's page, drafts one set of terms for several candidates on the same job, submits them for approval together and sends the approved ones with one expiry. And in Settings, Approvals, admins can now write the text shown above and below every posting on the internal job board, in place of the careers site's.

Hiring managers and above who can change the offer record answers and verbal yeses. A recorded answer cannot be dated in the future, before the offer was sent or after it expired. A verbal yes changes nothing: the offer still needs their answer, and a revised offer starts without it. Offers for many take up to 50 candidates on one job at a time, and each goes through your approval policy as its own offer. Webhooks say when the team recorded the answer (recorded and channel in the offer.accepted and offer.declined data).

When an applicant says on the careers form that someone who works here referred them, the employee they name is asked to confirm. Until that employee does, Analytics no longer counts it as a referral, puts the employee in Top referrers or lowers the referral hire rate, and the referrals CSV leaves it out too. The Referrals figure says how many are still waiting for the referrer to confirm.

A claim the named employee declines is removed, and one nobody answers stays in the waiting figure, never in the totals.

An email template now has a language. Open a template in Settings, Email templates and use Add a language version to write the same email in Spanish, French, German or Portuguese, whichever your careers site offers. A candidate who applied in one of those languages gets that version of the acknowledgement, rejection, interview, scheduling and offer emails, and of the emails your rules send; everyone else gets the default-language one. The templates list shows each email once, with a link to every language it is written in, and each language has its own default per kind.

Admins and owners write templates. Versions are found by their shared name and kind, so renaming an email or changing its kind changes every version with it. A version starts as a copy of the original: nothing is translated for you. The last default-language template of a kind Recruit Buddy sends on its own cannot be deleted while other languages remain.

A campaign can now go out as a text message instead of an email: choose Text message on New campaign, and the count shows who in the pool can receive it and why the rest cannot. Rules have a new action, Text the candidate, with merge fields and an optional hold, so "when a candidate reaches Phone screen, text them to look out for our email" runs on its own. Each text says who it is from and how to opt out.

Texts go only to candidates who agreed to texts and have not texted STOP since; campaign texts also need their agreement to hear about future roles. Nothing a rule or a campaign texts goes out between 21:00 and 08:00 in the workspace's time zone: it waits until 08:00. A rule that checks the AI's recommendation or score cannot text. Text campaigns count applications and hires, not clicks. A text never carries the private status link or a group calendar's booking link, since each is signed for the candidate: send those by email.

Draft with AI on New campaign writes a first draft from a short brief: who the pool is, the roles to mention and a tone. You edit it before anything is sent. On a campaign's page, Add everyone who clicked to a pool gathers the people who clicked a link into an existing pool or a new one in one step, ready for the next campaign or a call list.

The AI reads your brief and the workspace's name, never anyone's details, and is offered only where the workspace's AI policy is not Off. A draft never invents salaries, dates or links you did not give it, but read it through. Clicks are counted for email campaigns only.

The careers site conversion panel in Analytics now also breaks views, started applications and finished applications down by the source tag on the link people followed (?source=indeed, a share button, a newsletter), so you can see which links bring people who finish applying, not only who visits. The CSV carries the same rows. Over the whole workspace, cost per hire in Analytics is now the same figure the Hires page shows.

Views are counted per day and tag from the day the careers site started counting them; a visitor with no tag counts under no tag. Totals only, as in the rest of Analytics.

On the Team page, admins can tick Compliance exports for a member below admin. That person can then download the applicant flow log and the VETS-4212 counts on the Fairness page, without any other admin rights. They get a notification when it is given, and Fairness appears in their menu (and as Compliance exports in Analytics), even when their role would not otherwise show it.

Admins and owners always have it. The exports carry individuals' voluntary self-identification, so every download is recorded in the activity log.

The Settings rail now lists Questionnaires, Request templates and Rooms under Hiring. Before, those pages could only be reached from a job's setup, a candidate's Requests panel or My availability.

Recruiters and above, as on the pages themselves.

Add task on My tasks or on a candidate's page turns "call her back Friday" into a dated to-do, for you or for someone on the hiring team. The person it is for is notified, gets a reminder when it falls due, and ticks it off when it is done. Set by me lists what you have handed to other people until they finish it.

Hiring managers and above set tasks. A task about a candidate can only go to someone who can open that candidate. Only the person who set a task can change or delete it.

Analytics now shows how each interviewer keeps up with scorecards and how fast feedback comes in, interviews per hire, why applications closed by reason, stage and job, how long requisitions take to approve and how much approved headcount is still open, why offers are declined, and what referrals and agencies deliver over time. Every panel has a CSV with the same filters.

Totals only, as in the rest of Analytics. Offer decline reasons are sorted into themes by their words; the reasons themselves are shown only to roles that can see offers.

A campaign's page now counts who clicked a link in it, who applied within 30 days of their email and who was hired from those applications, and who has opted out since. Each recipient's row shows their clicks and links straight to the application the campaign produced. When a campaign does not go out, the page says why.

Opens are recorded when a recipient's mail app loads the email's images. Many apps block images or load them before anyone reads the email, so the Opened figure is a floor, not a count of readers: clicks remain the signal to trust. Only links you write in the campaign are tracked, never the candidate's private status link.

Removing someone from the team now asks who takes over their open jobs, requisitions, candidates, approval steps, tasks, upcoming interviews and new starters, and moves it in one step. Reassign work on the Team page does the same for someone going on leave, or picks up work left behind by people who have already gone.

Admins and owners only. Candidates, tasks and interview seats the successor cannot open (a restricted search they are not on, a stage their team does not see yet, or their own application) stay with the person leaving and are listed under Reassign work, for another hand-over. Removing someone without a successor sends their waiting approvals to an admin and takes them off upcoming interviews (the bookers are told); the rest keeps their name until it is reassigned. Someone who deletes their own account is released the same way.

A hiring platform for the whole team. Requisitions with approval chains, a careers site, a kanban pipeline per job, interviews with self-scheduling and scorecards, offers with approvals and typed e-signature, and a hand-off to onboarding. Every application is read against the job's scorecard and lands in the Decision Inbox with a recommendation, the evidence quoted from the CV, and what to probe at interview, so a recruiter can clear a full inbox in minutes and no candidate is left waiting without an answer.

The AI recommends; it never declines anyone by itself. A recommended decline always waits for one person to accept or override it, autopilot can only move candidates forward, and candidates can ask for human review only. Hiring managers and interviewers see only the jobs whose hiring team they are on.