Glossary

An applicant tracking system is the database of record for a recruitment business: the roles it is working, the people it has on its books, the submissions made against each role, and what happened next. Almost everything a consultant does happens inside it.

A website is not an ATS and should not try to be one. The job of an integration is to put what is already in the ATS in front of candidates, and to put applications back into it, without creating a second version of the truth that then has to be reconciled.

An application is only complete when it has reached the ATS, attached to the right role, with the CV and the consent record that came with it. A form that emails somebody is not an application process; it is a way of generating work.

The REST API is how any external system — a website, a reporting tool, a custom build — asks Bullhorn for data or sends data to it. Access is granted per Bullhorn account and authenticated with credentials your Bullhorn administrator issues, not with a consultant’s login.

Getting API access is usually the longest part of any integration project, because it is a request that has to go through whoever administers your Bullhorn rather than something a website developer can arrange.

A candidate record holds contact details, work history, documents such as a CV, and the consent and communication history attached to them. It is personal data in the legal sense, and it belongs in the ATS rather than duplicated into a website database.

Filtered and sorted views of a job board can produce many addresses showing overlapping sets of roles. A canonical tag tells a search engine which one to treat as the original, so the others do not compete with it or dilute it.

Quick to set up and nothing extra to maintain, because it is part of what you already pay for. The trade is that the roles live on a portal rather than on pages of your own, so the search traffic and the brand experience accrue somewhere else.

For an agency that treats a careers page as a box to tick, this is the right answer. For one that wants candidates to find roles through search, it is not.

Useful on a public job board mainly for what you choose not to show. A good proportion of agency roles are worked confidentially, where naming the employer on a public advert would breach the arrangement or tip off a competitor.

What happens to the address of a role that has closed is a real design decision, and vendors disagree about it. Deleting the page returns a 404, which breaks every link ever shared by email, on LinkedIn and in a newsletter. Redirecting to the listing reads to a search engine as a soft 404 and tells the visitor nothing.

The approach here is to keep the page at the same address, answer normally, say plainly that the role has closed, mark it expired for search engines, and take it out of the listing and the sitemap. Closure is reversible, and reopening reuses the same page.

Common, and often an afterthought in software built by people who have not worked a desk. The requirement is not to hide the role but to publish it with the client’s identity withheld — which means the field has to be suppressed on the public page while remaining visible to consultants in Bullhorn.

Recruitment holds a lot of personal data, and the lawful basis for holding it usually rests on what the person was told at the point of applying. That means the exact wording they saw, and the time they agreed to it, both matter — not just a ticked box.

The wording is yours: it has to match your own privacy notice and whatever your solicitor has approved. A vendor supplying the wording is a vendor writing your legal text.

Most established Bullhorn accounts carry a number of these, added to record something the standard fields did not cover. They are ordinary fields as far as an integration is concerned, but they have to be identified, because nothing outside your business knows what they mean.

Bullhorn can parse an uploaded CV into a candidate record. Whether an application should be parsed on the way in, or attached and left for a consultant, is a workflow decision rather than a technical one — parsing is fast but imperfect, and a mis-parsed record can be worse than an unparsed one.

Everything in Bullhorn is an entity of some type, and each type has its own fields. Integrations talk in these terms, so it is worth knowing the names even if you never touch the API: a conversation about “which fields map to the advert” is a conversation about fields on the JobOrder entity.

On a job board the question is whether a filtered view is a real page with its own address or a state of the page that disappears when shared. Real addresses can be linked, bookmarked, sent to a candidate and indexed; a filter held in the browser cannot.

The trade-off is that filters multiply quickly, so which combinations deserve to be indexed is a decision rather than a default.

Every agency has shaped its Bullhorn differently: salary might be in the standard pay fields or in a custom one, the advert copy might be in the public description or in a bespoke field, and the location might need assembling from several. Field mapping is the configuration step where those decisions are recorded.

It is the step most likely to be underestimated, and the one that most affects whether the finished board looks right.

For a recruitment business the practical obligations are the familiar ones: hold only what you need, tell people what you hold and why, keep it only as long as you can justify, and be able to produce or delete it on request.

A job board touches this because it is where candidate data is collected. The less of it the website keeps, the less of this is the website’s problem.

It is not a board you submit to. Google reads JobPosting markup from pages it has already crawled, so eligibility comes from each role having its own indexable page with correct markup — not from a feed or a listing agreement.

This is the single clearest reason a role needs an address of its own rather than living inside a widget.

It matters wherever something is retried. If a delivery is attempted again because the first response was lost, an idempotent design produces one application rather than two — which is the difference between a safe retry and a consultant with duplicate candidates in their pipeline.

The alternative — a full walk of every role on every run — is simple to build and expensive to operate. It burns the API allowance you share with everything else, and it scales badly exactly when it matters, which is when you have a lot of roles.

Three things have to be true: the content has an address of its own, that address returns the content to a crawler, and nothing on the page or in the response tells the crawler to stay away. Content loaded into a widget without its own URL fails the first test, however good it looks.

Used loosely for two quite different things: a public marketplace such as Indeed or Reed, and the section of your own website where your own roles live. This site means the second.

The distinction that matters commercially is whose domain the candidate ends up on, because that decides who accumulates the search traffic and who owns the audience.

Crawlers find pages by following links, which is slow and uneven for content that changes daily. A sitemap says plainly: here are the current roles, here is when each last changed. For a board where roles open and close constantly, it is the difference between being found this week and next month.

A closed role leaves the sitemap, which is part of how it is retired cleanly.

A JobOrder carries the title, the description, the location, the pay information, the employment type and the dates, along with whatever custom fields your business has added over the years. It also carries the flags that decide whether the role should be advertised publicly at all.

When this site talks about a role or a job, it means a JobOrder.

Licensing here is per live website, per year. It does not change with the number of roles published or applications taken, and staging sites do not need one.

The question worth asking any vendor is what a lapsed licence does. If the answer is that the job board stops working, the licence is not a support arrangement — it is a switch on a public page.

The page still works and still answers; it simply does not appear in results. Useful for pages that need to exist but should not compete for attention — a closed role, a thank-you page, a filtered view that duplicates another.

Applied site-wide, it makes an entire website invisible to search while leaving it perfectly usable to anyone with the address, which is the normal state of a site that has not launched yet.

Rather than storing someone’s username and password, an integration exchanges credentials for a token that grants limited access and expires. The integration refreshes that token as it works.

The practical consequence is that access can be withdrawn centrally, and that a leaked token has a shorter life than a leaked password. It also means a connection can stop working when credentials are rotated, which is one of the more common causes of a sync that was fine yesterday.

Integrations fail: tokens expire, APIs have outages, networks drop. The question is what happens to an application submitted during one. The pattern that does not lose anybody’s CV is to store the submission first, tell the candidate it worked, and then deliver it to Bullhorn — retrying until it lands.

Without something of this shape, a failed API call at the wrong moment means a candidate who believes they applied and a role that never heard from them.

“Permanent” is the operative word. An address that changes when a role is edited, or that is regenerated on a resync, throws away every link to it and every bit of search position it had earned. Assigning once and never regenerating is what makes the rest of the SEO work worth doing.

Not every open role should appear on a website. Some are confidential, some are internal, some are still being qualified, and some are being worked by a single consultant who does not want applications from the open market.

Which flag or field your business uses to mean “this one can go public” varies: there is a standard field, but many agencies use a custom one, or a status value, or a combination. Establishing that rule is one of the first things any integration has to pin down.

This is the reason a job board should not re-read your entire catalogue every few minutes. The allowance belongs to your Bullhorn account, not to any one integration, so a badly behaved plugin degrades the reporting tool and the middleware connected alongside it.

It is a fair question to put to any vendor: how many calls does a sync cost, and what happens when there is nothing to do?

Where an integration should be built and demonstrated. It lets a connection be proved end to end — including applications writing back — without putting test candidates into the system your consultants work in every day.

Anything that touches live job data or a live application form should be tried on one first. A staging site is also where an integration is configured and checked against real roles before anybody outside the business sees the result.

Human-readable text tells a person what the role is. Structured data tells a search engine the same thing in a form it can rely on: the title, the employer, the location, the salary, the employment type and the closing date, as named values rather than prose.

Without it a job page is just a page. With it, it is eligible to appear as a job.

When an application arrives, the useful outcome is not just a candidate record appearing somewhere in Bullhorn: it is that candidate attached to the right role, so the consultant working it sees them in their pipeline rather than in a general inbox.

A sync finds what has changed since last time, publishes new roles, updates edited ones and closes those that have been closed. It runs on a schedule rather than on demand, because a public website should not depend on an API call completing while a visitor waits.

The thing worth asking about a sync is not how fast it is but what it does when it fails: whether it tells anybody, whether it retries, and whether you can see what it did.

It is how a search engine knows an advert has expired without having to guess from a missing page. Setting it to a date in the past is the correct way to retire a role: the page remains, the markup says the role has closed, and the listing is removed from circulation in an orderly way.

What makes it worth knowing for a job board is that it allows a sync to be run on demand and its output read directly — which is how you find out what a failing integration is actually doing, rather than inferring it from an empty listing.

That last part is the catch: on a quiet site, scheduled work can run late or not at all, because nothing has triggered it. A job sync that depends on it will drift. Pointing a real server cron at WordPress instead makes the schedule actually a schedule.

It is one of the first things to check when roles have stopped updating.