How to Set Up Call Logging in Bullhorn

TL;DR: Bullhorn does not log calls natively in any meaningful automated sense - every call logging setup requires either a telephony integration (CloudCall, Dialpad, RingCentral, 8x8) or a custom API approach. The integrations vary significantly in what they actually capture: some log outbound only, some match on email rather than phone number and silently drop records when there is no match, and inbound call logging is the exception rather than the default. Before you configure anything, decide what you actually need the log to contain and work backwards from that - because once you have 3,000 incomplete note records in Bullhorn, cleaning them up is a manual job.

Does Bullhorn have built-in call logging?

Bullhorn has a Notes entity with a 'Call' action type and an Activities section where calls can be recorded manually, but nothing in Bullhorn itself captures a call automatically. Every automated call log entry is written to Bullhorn by an external telephony system talking to the Bullhorn API; without that integration in place, someone has to create the note by hand after each call.

The 'Call' note type exists purely as a manual classification. From Admin > Notes > Note Actions you will see a 'Call' action type there by default - that is the extent of Bullhorn's built-in capability. The manual flow is: user clicks the candidate or contact record, goes to Notes/Activities, clicks 'Add Note', selects 'Call' from the action dropdown, fills out comment and duration, saves. Activities in Bullhorn aggregate whatever is written to Notes - they do not originate anything themselves.

Some articles claim Bullhorn has automatic call logging because legacy integrations like Bullhorn for Outlook included a phone dialler that prompted a note. That still required a click to log. It was never native call capture. If you have no telephony integration, you are doing manual note creation - not call logging.

What the main telephony integrations actually log

The four most common Bullhorn telephony integrations are CloudCall, Dialpad, RingCentral, and 8x8. Each one logs call records to Bullhorn Notes, but the default data they capture and the quality of the contact matching differ significantly. These differences directly affect what appears in your Bullhorn timeline - and what gets silently dropped.

CloudCall writes directly to Bullhorn Notes. Default fields: call direction, duration, timestamp, phone number, call recording link (optional), auto-summary (optional). Matching logic attempts phone number match against Bullhorn candidate/contact phone fields (phone, mobile, work phone). CloudCall's matching is aggressive - it will also match by email if available from context (e.g., CRM lookup during the call). Failure mode: unmatched calls go to an 'unmatched' queue in the CloudCall dashboard - easy to miss if you never check it.

Dialpad logs outbound calls by default. Inbound calls require explicit configuration in Dialpad Admin (enable 'Log Inbound Calls' toggle). Fields logged: direction, duration, caller ID, call recording link (if enabled), call notes (if added). Matching: phone number only, against Bullhorn phone fields. Dialpad's connector can run in multi-instance Bullhorn environments - you must map each Dialpad user to the correct Bullhorn instance and user ID, or the note is created under a generic user.

RingCentral uses AppConnect integration. Logs outbound calls reliably. Known issue: inbound calls do not post to Bullhorn for some configurations - see RingCentral community threads. RingCentral's matching uses phone number only. Failure mode: if the number in Bullhorn is formatted +1-800-... versus 1800..., the match fails silently. No unmatched queue visible to the user - the call is simply not logged.

8x8 behaves similarly to RingCentral. Logs both directions but requires careful setup of the default note template. Matching uses phone number. 8x8 does not automatically create a note if no match is found - the call record stays in 8x8 history only.

Matching logic summary: all four use phone number matching as primary. No integration uses company name, email, or custom fields for the initial match - that data is only available after the call if the user manually associates.

Why contact matching fails and what to do about it

Contact matching fails most often because of inconsistent phone number formatting across Bullhorn records. The telephony platform receives a number like +447700123456, searches Bullhorn for an exact match, and finds 07700123456 (or 07700 123456) - it does not find it, and the call record is dropped or sent to an unmatched queue that nobody monitors.

The specific Bullhorn fields being matched: Candidate records - phone, mobile, workPhone (order depends on integration). Contact records - phone, mobile. Integration configs typically allow you to set field priority; most default to matching against all phone fields in order.

Failure scenario #1 - country code inconsistency: UK mobile numbers stored as 07xxx versus +447xxx in Bullhorn. US numbers stored as 1-800-xxx versus +1800xxx. Integration expects E.164 format (+447700...), but Bullhorn data can have local format. This is the number one reason for unmatched calls.

Failure scenario #2 - spaces, dashes, brackets: Integration strips spaces and dashes from the incoming caller ID (the telephony system already normalises it), but the search against Bullhorn may be a direct string comparison. Some integrations like CloudCall normalise both sides - not all do.

Failure scenario #3 - multiple records with same number: Integration matches the first record found. Which one? Depends on search order. You may see the note attached to one candidate when you expected another.

Do not assume the integration will handle formatting mismatches. Run a report of all candidate and contact phone numbers before go-live. Script a check for non-E.164 formatting. Most integrations let you set a phone number format preference; set it to E.164 and then update Bullhorn records accordingly.

What to configure in each integration for match failures:

• CloudCall: enable 'Unmatched Call Queue' email notifications. Review it weekly for the first month.

• Dialpad: no unmatched queue by default. Set up a Zap or n8n workflow to catch unmatched calls from Dialpad's API.

• RingCentral: no unmatched queue at all. If the match fails, the call is not logged. The only way to find out is to check RingCentral call logs manually.

• 8x8: same as RingCentral.

The real-world pattern: I have seen agencies with 300+ orphaned call records in a no-match queue after three months. Nobody was checking it. The integration was 'working' - they just had no idea it was only logging 40% of calls. This is the silent failure mode that vendor documentation never covers.

How long does a Bullhorn call logging integration take to set up?

A telephony integration for Bullhorn call logging takes between one day and one week to configure, depending on the integration chosen and the quality of existing phone number data in Bullhorn. The technical connection between the telephony platform and Bullhorn API is usually completed in hours; the time goes on cleaning phone number formatting, mapping users, testing match rates, and resolving edge cases.

For CloudCall, budget 1-2 days for a clean Bullhorn environment with tidy phone data and clear user mapping. Add 3-5 days if you need to cleanse phone number formatting first. CloudCall's premium support will help with initial config - but they will not clean your data.

Dialpad is similar time frames. Extra complexity for multi-instance Bullhorn environments: you must configure separate Dialpad integrations per Bullhorn instance, and user mapping needs to be precise across instances. Budget half a day extra for this.

RingCentral via AppConnect: the technical connection is quick - 30 minutes. But the inbound logging issue means you should budget 1-2 days for testing and debugging. Raising a RingCentral support case can take days to resolve. I recommend testing with at least 50 inbound calls before declaring success.

8x8 is similar to RingCentral but with less community support. Plan 2-3 days total including testing.

A custom API approach via n8n: 3-5 days minimum. The integration is a webhook receiver that transforms telephony platform call data and writes to Bullhorn Notes API. Time includes setting up the webhook, mapping fields, handling authentication, testing match logic, and building a fallback for unmatched calls. You also need to maintain it.

The bottleneck is always data quality. I have never had a call logging setup where the integration itself was the slow part. The slow part is always cleaning phone numbers in Bullhorn - and that is something the integration vendor cannot do for you. Run your phone number audit before you contact a telephony vendor.

Should you use a marketplace integration or build a custom one?

Use a marketplace integration if one exists for your telephony system and your primary requirement is getting calls logged into Bullhorn Notes automatically - they are faster to deploy and the vendor handles Bullhorn API version changes. Build a custom integration if your telephony platform has no Bullhorn connector, if you need the call log to trigger further automation downstream, or if you need precise control over the note format and which Bullhorn record type the note associates with.

When marketplace is the better choice:

• Your telephony system is CloudCall, Dialpad, RingCentral, or 8x8.

• You only need call logging - not compliance automation or conditional workflows.

• Your Bullhorn data is reasonably clean (you can fix the formatting before go-live).

• You do not need custom note templates with dynamic fields (e.g., including deal stage).

• You accept the default matching logic and unmatched call handling.

When custom makes sense:

• You use a telephony system with a good API but no Bullhorn connector: for example, Microsoft Teams calling via Azure Communication Services, or a PBX like Gamma or 3CX.

• You need the call log to trigger downstream workflows: automatically move a candidate to a status like 'called - left voicemail', create a compliance log entry, or alert a compliance manager if a call recording is missing.

• Your note format requirements are specific: you need the call note to include custom fields from Bullhorn (e.g., candidate current stage) or follow a strict compliance format that the marketplace integration cannot write.

• You need the call log to be stored in a secondary system (e.g., a compliance database) as well as Bullhorn. A custom middleware can do dual-write; marketplace integrations generally cannot.

What a custom integration looks like in practice: telephony platform sends a webhook to an endpoint (I use n8n for this). n8n receives the payload (call direction, caller ID, duration, timestamp, possibly call recording URL). It queries the Bullhorn REST API to find a matching candidate/contact by phone number (using /search/Candidate?query=mobile:...+447700...). If no match, either drop or write to an unmatched log with an alert. If match found, construct a Note object with action_type='Call', note text with your template, and associate it to the matched entity. Optionally trigger further workflows via additional Bullhorn API calls.

The trade-off: you own the maintenance. Bullhorn API changes (e.g., authentication version updates) require you to update your n8n workflow. Marketplace integrations handle this transparently. Custom integrations also require you to handle rate limits, retry logic, and error logging yourself.

My honest opinion: start with a marketplace integration if it meets 80% of your needs. The remaining 20% of customisation is rarely worth the extra development and maintenance burden. Only go custom if you have a clear, non-negotiable requirement that the marketplace cannot do.

Compliance and audit trail requirements for call logs

Bullhorn Notes is not a compliant call log store - it lacks tamper-evident audit trails, automated retention, and separate secure storage for recordings. Call log data in Bullhorn is written as plain Notes records; call recordings sit in the telephony vendor's own storage, linked via a URL in the note text. This split creates complications for UK GDPR right-to-erasure requests and for FCA-regulated firms that need to retain call recordings for five years.

Where is the data stored? Call metadata (direction, duration, timestamp, notes) is in Bullhorn Notes - no encryption at rest beyond Bullhorn's standard, no special compliance marking. Call recordings are stored by the telephony vendor. The Bullhorn note only contains a URL link. If you delete the note, the recording still exists on the vendor's side - and vice versa. Implication for GDPR right-to-erasure: you need to delete the recording from the telephony system AND delete/update the note in Bullhorn. Most integrations do not automate this.

Data retention: Bullhorn has none. Bullhorn does not automatically delete Notes at any age. If you log every call indefinitely, your Notes table grows without bound. There is no built-in retention policy. You must build a workflow (e.g., via n8n or a Bullhorn job) to delete notes older than X years.

For FCA compliance (financial services recruitment), SYSC 10A requires firms to retain telephone conversations used in transactions for at least five years. The recording must be stored in a tamper-proof medium. Bullhorn Notes are not tamper-proof - any user with edit permissions can modify the note text or delete it. Best practice: keep recordings in the telephony vendor's secure storage and only store a link plus a hash of the recording in Bullhorn. Use a custom integration to write the hash so you can prove the note was not altered.

Healthcare recruitment (CQC) is less strict on recording retention, but you must show proof that compliance information was communicated. Call log notes are acceptable if they are accurate and audit-trailed - Bullhorn's standard note history tracks edits but not who viewed the recording.

What to get right before you go live

Automated call logging will expose every phone number formatting inconsistency, every missing user mapping, and every ambiguous contact record in your Bullhorn instance. The integration does not fix these - it reveals them. Preparing your data and workflows before flip-on saves weeks of frustration.

Standardise phone number format first. Run a report of all candidate and contact phone numbers. Use a script (I use n8n or a simple Python script) to normalise to E.164 format (+447700123456). Remove spaces, dashes, and brackets. Test on a subset before bulk updating Bullhorn. Why this must be done before integrating: the integration will start matching on day one. If your numbers are mixed format, the first batch of call logs will be sparse and your users will lose trust in the tool. You cannot fix the data after go-live without reprocessing call records.

Agree the note format and test it. Every integration lets you customise what goes into the Bullhorn note body. Decide as a team what fields matter: call direction, duration, recording link (include or not?), auto-summary (if available). Configure this before the first call is logged. Changing it after go-live means a mess of inconsistent notes that are hard to report on. Example note template: "[Direction] call with [Contact/Candidate name] on [Date/Time]. Duration: [Duration]. Recording available: [Link]."

Test inbound call logging explicitly. Do not assume inbound calls log just because outbound does. In Dialpad and RingCentral, inbound is a separate toggle. Test at least 10 inbound calls to your direct line, your main number, and any DDI or number that rings a group. Check: does the note show the correct direction? Does it record the caller ID correctly (especially for withheld numbers - they often log as 'Private Number' and fail matching)?

Map every telephony user to a Bullhorn user before go-live. Each integration requires a mapping between the telephony user account and the Bullhorn user ID. If a consultant leaves or changes extension, update the mapping. If you skip this, call notes will be created under a generic 'Integration User' and you lose ownership data. In multi-instance Bullhorn environments (e.g., separate instances for perm and contract), ensure each user is mapped to the correct instance. Dialpad supports this natively; others may require separate connectors.

Set up a monitoring process for the unmatched queue. Whether your integration has an unmatched queue (CloudCall) or not (RingCentral), you need a process. For CloudCall: turn on email notifications for unmatched calls. Have someone review the queue weekly for the first month, then monthly. For RingCentral/8x8: build a small n8n workflow that polls the telephony API daily for calls that did not result in a Bullhorn note. Alternatively, manually spot-check the call logs in the telephony system against Bullhorn. This is tedious but essential until you trust the match rate. Accept that some calls will always be unmatched: withheld numbers, internal calls, calls to non-contacts. Decide whether you want to log those manually or let them go.

The process-before-automation principle: If your consultants are not reliably logging calls manually now, adding automation will not change their behaviour. It will make the gaps more visible. You will see that Candidate X was called three times with no note - and the consultant will say 'I always log my calls'. The integration becomes a management tool, not a fix. My advice: run the integration as a parallel process for two weeks. Compare automated notes with the manual notes consultants are creating. If the manual notes disappear entirely, you have a coaching issue, not a technology issue.

Before you go live with a Bullhorn call logging integration, run the phone number audit and fix the formatting. If you need help with that - or with setting up the integration in the first place - I can help. Book a Bullhorn audit at Bullhorn audit and integration service and we will go through the data, the matching logic, and the monitoring workflow together.