Bullhorn CRM Customisation in the UK: A Practitioner’s Guide

TL;DR: Customisation in Bullhorn happens in three layers: UI changes, data architecture decisions, and API builds. Most agencies only ever touch the first layer, add 40 fields nobody fills in, and then find the reporting is unusable. The decisions that actually matter are field type (dates and dropdowns, never free text, for anything you will report on or trigger from), custom objects rather than numbered fields for anything that repeats such as right-to-work checks, and a separate record layout for each desk type. Budget £800 to £1,200 a day for an independent UK consultant, and 2 to 5 days for a layout and field restructure.

This guide covers the three layers of Bullhorn CRM customisation UK recruiters and ops teams actually work with, the specific decisions that affect long-term data quality, and the failure modes I see most often in agencies that have been configuring the system without a clear architectural view.

What does Bullhorn customisation actually mean?

Bullhorn customisation covers three distinct layers: admin-level UI changes such as field visibility, column order and saved list views; configuration decisions that shape the data architecture, such as field types, record layouts and custom objects; and API or integration builds that populate, sync and trigger from data automatically. The layers differ in who can safely do them and how easily they can be undone. Toggling a column is free and instant, whereas rearchitecting a candidate record after three years of bad field decisions takes days and a data audit first.

There are three distinct layers, and conflating them is where most problems start.

The first layer is admin-level UI changes - field visibility, column order, saved list views, dashboard widgets. These are low-risk, largely reversible, and can be handled by a technically confident internal admin. The second layer is configuration decisions that affect data architecture: field types, record layouts, custom objects, and the relationships between them. These decisions are harder to reverse and have downstream consequences for reporting and automation. The third layer is API and integration builds - automated field population from third-party sources, bi-directional sync with another CRM, custom webhook triggers. These require a developer or a consultant who knows the Bullhorn REST API.

Most agencies hand the system to a resourcer during onboarding, get them to add some fields, and call it configured. The result looks busy but performs poorly as a reporting layer and collapses as an automation trigger. Toggling a column is free and instant. Rearchitecting a candidate record after three years of bad field decisions takes days and a data audit first.

Which custom fields are worth building in Bullhorn?

Build a custom field only when you can name the specific report or workflow that will depend on it, and give it a type that matches how you will query it: date fields for expiries, dropdowns for anything you want to group or filter on, and text rather than numeric for reference numbers that carry leading zeros. Repurposing an existing field, usually a notes field, is the most common mistake and leaves you with unstructured data you cannot report on or automate against. A field can always be added later, but removing one that already holds partial data is a much messier job.

The most common mistake here is repurposing existing fields rather than creating new ones. A field called "Notes" repurposed to track GDPR consent source is a data governance problem - it is free text, it is unstructured, and you cannot report on it. When an ICO audit asks you to demonstrate lawful basis for processing, "it's in the notes field somewhere" is not an answer.

Field type selection has more downstream impact than most people realise at setup time. A free-text field for right-to-work expiry date cannot trigger an automated alert or be filtered in a date range report. A date field can. A dropdown field produces consistent, groupable values. A text field produces seventeen variations of "Healthcare" across your candidate base and a reporting nightmare.

Some specific field examples by desk type, with names and types:

• Healthcare desk: rtw_expiry_date (date), dbs_check_level (dropdown: Basic / Standard / Enhanced), pin_number (text, not numeric - a numeric field will drop leading zeros from NMC and HCPC PIN numbers)

• Contract desk: ir35_determination (dropdown: Inside / Outside / Not Yet Assessed), ir35_determination_date (date), umbrella_company (text or lookup)

• Compliance fields: gdpr_lawful_basis (dropdown: Consent / Legitimate Interest / Contract), gdpr_consent_date (date), consent_source (dropdown: Web Form / Email / Phone / In-Person)

The 40-field problem is real. Agencies build fields during onboarding enthusiasm, recruiters ignore 70% of them within six months, and adoption collapses. My working rule is this: if you cannot name the specific report or workflow that depends on a field before you create it, do not create it. The field can always be added later. Removing it once it has partial data in it is a much messier job.

Worth flagging specifically: poorly named or duplicate fields are among the hardest things to unpick. If you have Candidate_Sector, candidate_sector, and Primary Sector all on the same record type, you have both a reporting problem and a migration problem. Any future data work requires three separate mapping decisions and manual reconciliation.

Record layouts: perm versus contract desks

Bullhorn allows different view layouts per entity type, and most agencies use one candidate layout for everything. For a multi-desk agency, that is a mistake that costs recruiters real time every day.

The principle I work to is above-the-fold relevance: the fields visible without scrolling should be the five to eight pieces of information a recruiter needs to make a decision in that specific workflow. For a perm desk, those are probably current role, notice period, salary expectation, availability, and location. For a contract desk, they are compliance status, right-to-work expiry, IR35 determination, current rate, and umbrella or PAYE preference.

A contract recruiter opening a candidate record and scrolling past "Career Objective," "Preferred Job Type," and "Salary Expectation" to find whether the DBS check has expired - that friction compounds across 30 candidate records per day. Multiply that across a desk of eight people and it becomes a meaningful drag on throughput, and more importantly it becomes the reason people stop using the CRM and go back to their own spreadsheets.

Tabs work well as a secondary organisation layer. Compliance fields can live in a dedicated tab on contract records without cluttering the primary view for recruiters who do not need them. The key is that the primary view contains only what is operationally relevant to the person using it most.

Should you use a custom tab or a custom object?

Use a custom object when you need to store multiple instances of something against a candidate, contact or job, such as a right-to-work check that gets renewed every couple of years. Use a custom tab when you only need to group existing fields visually, because a tab creates no new data relationship and keeps no history. Tracking a repeating event across numbered fields instead gives you a flat structure with no concept of which record is the most recent, which means you cannot build the expiry report you wanted the fields for in the first place.

This is the area where I see the most expensive mistakes in Bullhorn CRM customisation for UK agencies, and it is almost never explained clearly at the point of setup.

Custom tabs are display containers. They organise fields visually on a record but do not create new data relationships. A tab called "Compliance" containing right-to-work fields is still just flat fields on a candidate record - single instance, no history.

Custom objects create relational records linked to a parent entity. A custom object for "Right to Work Check" linked to a candidate record can store multiple instances over time - the 2021 check, the 2023 renewal, the 2025 extension - each with its own document reference, expiry date, and verification status. That is structured, queryable, auditable data.

The decision rule is straightforward: if you need to store multiple instances of something per candidate, contact, or job, you need a custom object. If you just need to group fields visually, a tab is sufficient.

The failure mode I see most often is agencies tracking compliance history using a series of custom fields: rtw_check_1_date, rtw_check_2_date, rtw_check_3_date. This creates a flat, unqueryable mess. You cannot report on "all candidates whose most recent right-to-work check expires in the next 30 days" because the system has no concept of which check is the most recent one. You can build that report against a custom object with a proper date field and a defined relationship. You cannot build it against three parallel date fields with no hierarchy.

Custom objects also enable automation in a way that flat fields do not. You can trigger a workflow when a new custom object record is created, or when a date field on that object crosses a threshold. One thing worth confirming before scoping any build around custom objects: their availability depends on your Bullhorn subscription tier. Check this before committing to a data architecture that requires them.

What can the Bullhorn API do that the interface cannot?

The Bullhorn REST API opens up a different category of customisation - things the UI simply cannot do. Automated field population from third-party sources, bi-directional sync with HubSpot or another CRM, custom triggers on record creation or status changes, bulk data transformation and backfill operations.

A UK-specific use case I have built for BD-focused agencies: pulling Companies House data into Bullhorn client company records automatically when a new company is created. Registered address, SIC code, incorporation date, and director information write back to the record via API. It reduces manual data entry and means the client record is actually useful on day one, rather than sitting there with just a company name.

Another practical example is triggering compliance workflows from external verification tools. When a right-to-work verification completes in a third-party platform, the result writes back to the candidate record in Bullhorn via API and updates the relevant custom object. The recruiter does not have to touch it - the data is there, the date field is populated, and the alert workflow fires correctly.

On HubSpot and Bullhorn bi-directional sync: the failure mode I see regularly is agencies running both systems with no sync in place. Client contact data exists in both, gets updated in one, and within three months you have conflicting job titles, stale email addresses, and duplicate records that nobody is confident enough to merge. A properly built sync with defined conflict resolution rules prevents this, but it requires upfront decisions about which system is the system of record for each data type.

One thing to be honest about: the Bullhorn API rate-limits at 60 requests per minute on the standard tier. Any bulk operation - a data backfill, a mass field update, a large initial sync - needs to be built with rate limit handling and retry logic, or it will fail partway through and leave your data in a partial state. A webhook that fires correctly when it is first deployed and then silently stops working six months later because error handling was not built in is worse than no webhook at all. API work requires proper scoping, logging, and ongoing maintenance. It is not a one-off job.

Which UK compliance fields does a Bullhorn contract desk need?

A UK contract desk needs structured fields for four things: GDPR lawful basis and consent, right-to-work expiry, IR35 determination, and AWR eligibility. Each needs a real field type rather than a note, so dropdowns for lawful basis, consent source, IR35 status and payment method, and date fields for consent date, right-to-work expiry, IR35 assessment date and AWR start. Free text in any of those positions means you cannot report on the data and cannot fire an alert from it, which is the whole reason for capturing it.

Bullhorn CRM customisation for UK recruitment agencies has a specific compliance dimension that agencies in other markets do not face to the same degree. The combination of GDPR, IR35, AWR, and right-to-work requirements means the field architecture on a UK contract desk is materially more complex than on a perm desk or an equivalent US agency setup.

GDPR lawful basis and consent tracking needs structured fields. The common mistake is storing this in a notes field because it is faster at the time. gdpr_lawful_basis as a dropdown, gdpr_consent_date as a date field, and consent_source as a dropdown gives you reportable, auditable data. A note that says "candidate consented by phone March 2024" gives you nothing you can report on or automate against.

Right-to-work expiry alerts only work if the expiry is stored as a date field. The workflow is simple: the date field on the candidate record or custom object triggers an automated task or email a set number of days before expiry. You cannot build this against a field that says "expires March 2026" in free text.

For IR35, the minimum field set I would recommend is: ir35_status (dropdown: Inside / Outside / Not Yet Assessed), ir35_assessment_date (date), ir35_assessed_by (text or user lookup), and ir35_client_confirmed (checkbox). A surprising number of agencies track this in the notes field and then cannot pull a report on their outside-IR35 contractor base when they need to.

AWR eligibility is an area that often gets missed entirely. awr_start_date as a date field, and either a calculated or manually set awr_12_week_date, gives account managers enough to work with. AWR rights kick in at 12 weeks in the same role with the same hirer. If nobody is tracking this, the alert never fires and the agency is exposed.

Payment method fields are worth building properly too: payment_method as a dropdown (PAYE / Umbrella / Ltd Company / CIS), umbrella_provider as text or a lookup, ltd_company_name, and vat_registered as a checkbox. These matter for payroll reconciliation and for compliance if HMRC comes asking.

What breaks when you over-customise

Bullhorn version updates can conflict with custom layout configurations, particularly when Bullhorn changes underlying field names or entity structures in a major release. Anyone who has been through a Bullhorn version migration without having their customisations documented in advance will know what this looks like - layout sections in the wrong order, fields that have disappeared from view, custom tabs that no longer behave as expected. Documentation is not optional on a project like this.

Team-specific customisations that become everyone's interface is a reliable way to kill adoption. A layout built for a contract compliance workflow with 20 compliance fields as the default view is actively unhelpful for a perm consultant who never needs most of them. If you have multiple desk types, the layout should reflect that.

Migration complexity is another consequence of poor naming discipline. When you move between Bullhorn instances, or bring data from a legacy ATS into Bullhorn, inconsistent field naming makes the mapping exercise significantly harder. Candidate_Sector, CandSector, and Primary Sector are all the same thing but require three separate mapping decisions and manual reconciliation. I have spent more time on this than I would like in migration projects, and it is entirely avoidable with basic naming conventions applied from the start.

The principle that cuts through most of these problems: customise to the workflow, not to the feature. Every field, tab, and layout decision should trace back to a specific recruiter action or a specific report someone has asked for. If you cannot name the use case, the field probably should not exist.

What does a Bullhorn customisation project cost and how long does it take?

Independent Bullhorn consultants in the UK sit in the range of £800 to £1,200 per day. A layout and field restructure with no API work is 2 to 5 days, a custom object build with automated alerts is 3 to 5 days, a full bi-directional HubSpot integration is 10 to 20 days depending on data volume, and a full implementation with compliance workflows is 15 to 30 days. Scoping should start with a current-state audit of existing fields and layouts, plus interviews with at least one recruiter per desk type rather than the manager alone.

A proper scoping exercise should include a current-state audit of existing fields and layouts, a field mapping document, workflow documentation covering what triggers what and what data is needed at each stage, and user interviews with at least one recruiter per desk type. Not just the manager who thinks they know how the team uses the system - the people who are actually opening candidate records 40 times a day.

Realistic timelines by scope:

• Layout and field restructure, no API work: 2 to 5 days

• Custom object build with automated alerts: 3 to 5 days

• Full API integration with HubSpot, bi-directional sync: 10 to 20 days depending on data volume and complexity

• Full Bullhorn implementation from scratch with compliance workflows: 15 to 30 days

Good independent Bullhorn consultants in the UK are in the range of £800 to £1,200 per day. Be cautious of options significantly below that range. Bullhorn customisation work done badly is considerably more expensive to unpick than to do correctly the first time - particularly once there is three years of inconsistent data sitting on top of the wrong architecture.

Questions worth asking any partner before you commit: Have you worked with agencies on this specific desk type? Can you show me a custom object build you have done for compliance tracking? How do you handle documentation and handover? What does your process look like if something breaks six months after the project closes?

If you are still shortlisting, I have written a fuller guide on how to choose a Bullhorn implementation partner in the UK.

The natural starting point for any of this is understanding the current state before making any decisions. That is what the Stack Logic audit covers - existing field architecture, workflow gaps, adoption issues, and a clear basis for scoping whatever comes next.