Systems and records
Leaving Bullhorn: exporting placements, notes and submittals
By SourceX Editorial · Updated
Short answer
A complete Bullhorn data export follows the placement lifecycle: clients and contacts, job orders, candidates, submittals, interviews, placements, and the notes and files attached to each. Ask Bullhorn in writing what full export it provides and test API pulls before giving notice, keep internal IDs so records stay linked, and treat candidate personal data as the most sensitive part.
Key takeaways
- Notes are the most valuable and most easily broken part of a Bullhorn export, because one note can link to several records.
- Internal IDs on every record are what let submittals, placements and notes be joined again after migration.
- Ask your Bullhorn account team in writing what a full database export contains, its format and any fee, before giving notice.
- Resumes, contact details and pay fields need the strictest handling in any staffing export.
- A migration export and a licensing package are different things; the second removes personal details first.
What records make up the placement lifecycle in Bullhorn?#
The placement lifecycle in Bullhorn runs from a client company and a job order, through candidates submitted to that job and the interviews that follow, to a placement and its later changes. Each stage is a separate record type, joined to the others by internal IDs.
The table uses record names from Bullhorn's REST API, which can change between releases, so confirm them against the current API reference. Your instance may show different labels on screen, and most firms add custom fields, so map the labels your recruiters use to the underlying records before scoping the export.
| Lifecycle stage | Bullhorn record | What it holds | Links to |
|---|---|---|---|
| Client | ClientCorporation, ClientContact | Companies, hiring managers, billing contacts | Job orders, notes, placements |
| Requirement | JobOrder | Role, status, owner, rate fields | Client, submittals, placements |
| Talent | Candidate, CandidateWorkHistory, CandidateEducation | Profile, work history, education, skills | Submittals, notes, placements |
| Submittal | JobSubmission, JobSubmissionHistory | A candidate submitted to a job, and each later status change | Candidate, job order |
| Client send-out | Sendout | A candidate's profile sent to a client contact | Candidate, contact, job order |
| Interview | Appointment | Interviews and meetings on the calendar | Candidate, contact, job order |
| Placement | Placement, PlacementChangeRequest | Start date, rates, fee, status and later changes | Candidate, job order, client |
| Activity | Note, Task | Calls, emails, comments and follow-ups | Any of the records above |
| Files | File attachments on each record type | Resumes, cover letters, contracts, certificates | Their parent record |
Why are notes the hardest part to export?#
Bullhorn notes are the hardest part because a single note can be attached to a candidate, a contact, a job order and a placement at once. In the API, those extra links sit in separate association records rather than on the note itself, so a flat export of notes against one record type loses the other links, and that is where most of the context sits.
Recruiters also write their reasoning into notes: why a candidate was turned down, what the client said after an interview, why a placement fell through. That makes notes the heart of the history and also the place where personal and sensitive details most often appear in free text.
Export each note with its own ID, author, action type, date and every linked record ID. Then open a sample of exported notes beside the Bullhorn screen to confirm the links survived.
Which export routes are available?#
Bullhorn data comes out through four practical routes, and most firms leaving the platform use more than one. Each suits a different job.
- List exports from the interface: quick CSV files of whatever a list view shows. Fine for spot checks, weak for history, because they flatten links and often leave out notes and files.
- REST API: entity, search and query calls that return records with their IDs and associations. Suits a scripted full pull within the API's limits and needs a developer or migration partner. API access typically depends on credentials Bullhorn issues on request, so ask for them early.
- Vendor-provided database export: a full extract arranged through your account team. Ask what it contains, the file format, whether resumes and attachments are included and whether a fee applies.
- Migration partner tools: services that move data into a new ATS. Confirm they carry historical notes, submittal status changes and attachments, not just current records.
Bullhorn export checklist before you give notice#
Run the checklist before notice, because your agreement sets what Bullhorn provides at exit and for how long, and those terms vary by contract. Once notice is sent, you lose leverage and possibly time.
- Confirm the renewal date, the notice deadline and the data return terms in your agreement.
- Request a written description of the full database export, its format and any fee.
- Inventory custom fields and their labels, since most Bullhorn instances are heavily customized.
- Pull clients, contacts, job orders, candidates, submittals, interviews and placements with internal IDs and created and modified dates.
- Pull notes with every linked record ID, plus tasks and appointments.
- Pull resumes and file attachments with a map from each file to its record.
- Export users and ownership fields so recruiter and account manager history stays readable.
- Reconcile counts per record type and trace a sample of placements end to end, from client to job order to submittal to placement.
Which fields carry candidate personal data?#
Candidate records carry the most sensitive information in a staffing database: names, contact details, addresses, work history and resumes, and in some firms pay expectations, work authorization or identification details. Notes and logged emails repeat much of that in free text.
Candidate notices, client contracts and privacy laws may limit how this data can be reused, and those questions are assessed deal by deal with counsel. The table separates how a field is handled in a migration from how it would be handled in a licensing package.
| Area | Examples | In a migration | In a licensing package |
|---|---|---|---|
| Identity and contact | Names, emails, phones, addresses, profile links | Moved under access controls | Removed or replaced with tokens |
| Resumes and files | Resumes, cover letters, certificates | Moved with record mapping | Usually excluded or heavily redacted |
| Pay | Current and desired pay, pay and bill rates | Moved with restricted access | Excluded or generalized after rights review |
| Sensitive details | Work authorization, EEO self-identification fields, ID numbers, any health or background notes | Moved only if required, tightly restricted | Excluded |
| Free text | Notes, logged emails, interview feedback | Moved with links intact | De-identified, then checked by sample |
| Client details | Client names, contacts, bill rates | Moved as is | Removed or generalized under confidentiality terms |
Illustrative: an IT staffing firm changes ATS after a merger#
Illustrative: a fictional IT staffing firm with many years on Bullhorn merges with a firm that uses a different applicant tracking system, and the combined business standardizes on the other platform. The migration partner's standard package moves current candidates, contacts and open jobs, with historical notes attached only to the candidate.
The COO asks for more before notice goes out. The firm requests Bullhorn's full database export in writing, pulls notes through the API with every linked ID, and maps resumes to candidate IDs. Placement chains are traced end to end on a sample of past placements.
The full archive is kept under restricted access with a retention rule. Separately, leadership asks whether a de-identified package of job orders, submittal outcomes and recruiter notes about role requirements could be licensed, without candidate profiles.
How SourceX approaches staffing records#
Staffing records sit close to people, so SourceX approaches them conservatively. The first conversation needs only the ATS name, years of history, record types and known restrictions; no candidate files or exports are requested.
When a package proceeds, the Rights and Preparation steps of the SourceX five-step transaction check candidate notices and client contracts and remove personal and confidential details, and the SourceX Evidence Packet records the privacy record, permitted use and release authorization. Packages built on workflow outcomes, such as how job orders moved to placements, are usually more practical than packages centered on candidate profiles.
Frequently asked questions
Does Bullhorn charge for a full data export?
It depends on your agreement and what you ask for. Some exports may be covered, others may be quoted as a service. Ask your account team in writing what the full database export contains, its format and any fee, and keep the reply with your contract records before you send notice.
Can we keep using our Bullhorn data after we leave?
SaaS agreements commonly treat the records your firm entered as your data, but check the ownership and post-termination terms in your own contract. Your obligations to candidates and clients continue after migration, so store the archive with restricted access and a retention rule.
How do we keep email history that was logged in Bullhorn?
Emails logged to Bullhorn are typically stored as notes or message records linked to candidates and contacts. Include them in the API pull with their links. Emails that were never logged stay in your mail system and need their own export and retention decision.
Should we purge old candidate records before exporting?
Not as part of the export. Export first, then apply your retention policy to both the new ATS and the archive. Purging first removes history you may need for disputes or reporting, and deletion rules can differ by jurisdiction, so set them with counsel.
Is staffing data of interest to AI developers?
Some AI developers building recruiting and workflow tools look for records that show how roles, submittals and outcomes connect. Interest depends on the buyer and the package, and value is known only once a buyer engages. Candidate personal data is the hardest part to license, so packages usually center on de-identified workflow records.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.