Bullhorn Automation for Bullhorn Recruitment Cloud
Bullhorn Automation (BHA) supports customers using Bullhorn Recruitment Cloud (RC), which is built on Salesforce. This article covers how RC Automation works, which entities are supported, and where RC Automation differs from Bullhorn ATS-based Automation.
How Data Syncing Works
Bullhorn Automation connects to Bullhorn Recruitment Cloud through Salesforce. When a record changes in Salesforce, that change is captured and passed to Bullhorn Automation, which then triggers the appropriate automations.
The system checks for record changes periodically. If a sync fails, Bullhorn Automation automatically recovers by pulling all records updated since the last successful sync on the next run.
Bullhorn Automation stores customer data for the life of the customer relationship unless a deletion is specifically requested.
API Admin User Requirements
The following requirements apply to the API Admin User used to connect Bullhorn Automation to Recruitment Cloud:
-
The API Admin User must be licensed.
-
MFA must be disabled for the API Admin User.
-
The user must have full Read/Write access to all necessary data objects for Bullhorn Automation data ingestion.
Bullhorn Automation enforces character limits on standard fields. Contact Support for details on current limits.
Supported Entities
Bullhorn Automation supports the following entities for data mapping with Salesforce. Entity names use Bullhorn naming conventions. Any Salesforce object or record layout can be mapped to one of these Bullhorn Automation entities. For example, both Candidates and Contacts in Bullhorn Automation are often mapped to the Salesforce Contact object, but filtered by layout: Candidates are filtered to a specific candidate layout, while Contacts are filtered to records using the Contact layout.
-
Candidates
-
Contacts
-
Placements
-
Submissions
-
Users
-
Jobs
-
Notes
-
Tasks
Implementation and Configuration
The following considerations apply to RC Automation due to how Salesforce handles data and record types. These are known differences from Bullhorn ATS-based Automation.
Contact Records That Are Both Candidates and Sales Contacts
Bullhorn Automation creates separate records for candidate and contact record types. As a result, Bullhorn Automation creates two records tied to a single contact record in Salesforce. This can affect how records are pulled into lists and automations designed for candidate versus sales outreach.
Custom Objects
Bullhorn Automation does not support custom objects. Data associated with a standard object is not referenceable when the field relationship is not one-to-one.
Example: A custom Skill object with a one-to-many relationship (one skill mapped to many contacts) is not supported.
Multiple Objects to One Bullhorn Automation Entity
Bullhorn Automation supports one-to-one object mapping only. Mapping multiple Salesforce objects to a single Bullhorn Automation entity is not supported.
Custom Fields for Notes and Users
Bullhorn Automation does not support mapping of custom fields for the Note and User entities.
Formula Fields
Formula field values in Salesforce are recalculated only when a user opens the record. Until then, the value remains frozen. Because of this, Bullhorn Automation may not retrieve the most current value for a formula field if the field has not been recalculated since the last sync.
Feature Differences
The following Bullhorn Automation features are not supported or behave differently for Recruitment Cloud customers.
User Picker Fields as Email Sender
Salesforce user picker fields cannot be used as the From address in email settings.
Workaround: Use smart tokens to populate sender information.
View in ATS for Jobs, Placements, and Submissions
The View in Salesforce option on daily and weekly notifications is supported for contact records only. It is not available for Job, Placement, or Submission records.
Update Mass Mail Opt Out
The Update Mass Mail Opt Out setting is not supported for Recruitment Cloud customers.
Workaround: Build an automation to sync the unsubscribed subscription status back to Salesforce.
User Hierarchy and Reports To
List criteria and notification support for managers using the record owner's Reports To relationship is not supported.
Credential Requirements
Credential
A record of qualification and/or clinical practices history. Example for Light Inustrial: Fork Lift Certification
Example for Healthcare: Nursing License requirements and the Update Credential automation step are not supported for Recruitment Cloud customers.
Call Lists
Call lists, also known as tearsheets, cannot be created from Bullhorn Automation for Recruitment Cloud customers.
Owner Assignment Rules
Owner Assignment Rules
Rules which can be created to assign the most suitable owner to each contact. This ensures that every contact is managed by the right person. cannot be used to update a record owner in Salesforce. In Recruitment Cloud Automation, Owner Assignment Rules are only used to determine the record owner for outreach purposes when the assigned owner is inactive or no longer assigned in Salesforce.
Data Syncing Behavior
The following data conditions cause records to error during syncing. Errored records are skipped, and all other records in the sync continue to process normally.
| Condition | What happens |
|---|---|
| Records with line breaks in field values (for example, multi-line address fields) | Record errors and is skipped during the sync |
| Field data format mismatches (for example, a field configured as text that receives a number value) | Record errors and is skipped during the sync |