Best Practices to Avoid Duplicate Fields in BHRC

When creating custom fields in a Salesforce org that uses the BHRC package (namespace: TR1), it’s important to avoid using the same API API, or Application Programming Interface, is used by customers to create custom career portals or to take advantage of Data Mirror/DataMart. Bullhorn prefers to use REST API. name as existing managed package fields. Doing so prevents your custom fields from being recognized by the system and can disrupt automation, reports, or queries.

Why Avoiding Duplicate Fields Matters

Salesforce automatically adds a namespace prefix (TR1__) to fields that come from managed packages. If your custom field shares the same API name as one of these namespaced fields, the system cannot distinguish between the two , causing lookups and queries to fail. Understanding this behavior helps administrators maintain stable configurations and avoid naming conflicts that can impact data integrity.

Common Scenarios and Reasons You Might See Conflicts

Here are some real-world situations where you might encounter duplicate field issues:

You created a new custom field with an API name that matches an existing BHRC (TR1) managed field.
A flow, report, or Apex query stopped recognizing your field after installing or updating the BHRC package.
You cloned a field or recreated it with the same name as a BHRC field.
Your custom field is not appearing in automation or query results.
You receive an “Invalid field” or similar error when referencing the field in formula fields, flows, or SOQL queries.
You’re unsure whether a conflicting field name exists and want to confirm before creating new fields.

How to Prevent Duplicate Field Names

Creating fields with unique API names ensures your automations and integrations work as expected.

Before adding or modifying custom fields in a BHRC-enabled org:

Check existing BHRC fields first.
- In Salesforce Setup, go to Object Manager and select your object (EX: Candidate A person looking for a job. A candidate can also be referred to as a Job Seeker, Applicant, or Provider.).
- Search for fields beginning with the TR1__ prefix.
- Note any API names that resemble your planned field name.
Choose unique and descriptive API names.
- Include an organizational prefix or category identifier (EX: BHCustom_StartDate__c).
- Avoid reusing names from BHRC managed fields, even if the label is different.
Document field naming conventions.
- Create a shared reference list or enforce naming guidelines through your governance process.
Validate in a sandbox Non Production Environments are used by customers to test new features prior to them going live. environment.
- Always test new field creation in a sandbox or test org with BHRC installed to identify naming conflicts early.

What To Do If You Already Created a Duplicate Field

If you discover that a custom field you created has the same name as a BHRC-managed field:

Do not delete or rename the existing field. This change may break automation, validation rules, or dependencies.
Create a new formula field that references your custom field.
- Name it something unique(EX: CustomField_Ref__c).
- Use this formula field’s API name in your automations, reports, or code instead of the custom field name.
Update all references (i.e. flows, formulas, and queries) to use the formula field.
Document the change for future reference and consistency.

Outcome: Using this approach allows the BHRC package to function normally while ensuring your custom logic continues to work correctly.

Troubleshooting

If you’re unsure what’s causing a conflict, start here:

If your custom field isn’t showing in queries or automation: Check for a BHRC (TR1) field with the same API name.
If your automation suddenly stopped working after a package update: Review managed field changes introduced by the update.
If you receive an “Invalid field” error: The field name may be conflicting with a namespaced BHRC field.
If renaming didn’t resolve the issue: Confirm that the formula field or new reference field is used everywhere in place of the duplicate.
If you can’t locate BHRC-managed fields: Search for the namespace prefix TR1__ within the object’s fields list.
If cloning a field caused issues: The cloned field likely kept the same API name, rename it before saving.
If you’re unsure whether this affects standard fields: This behavior only applies to managed package fields, not standard Salesforce ones.

FAQ

Q: What should I do if I already have a duplicated field name?

A: Create a formula field with a different name that references your custom field, and update all automation and references to use the formula field instead.

Q: How can I check if a field name already exists in the BHRC (TR1) package?

A: In Object Manager, look for fields with the prefix TR1__. These indicate managed package fields.

Q: Can I delete or rename the conflicting field instead?

A: It’s not recommended. Renaming or deleting a field may break dependencies or disrupt automation. Use a formula field instead.

Q: Does this apply to standard Salesforce fields too?

A: No, this behavior is specific to managed package fields that include a namespace prefix.

Q: Is there a list of all BHRC (TR1) fields I can review?

A: Administrators can generate a Field Metadata Report in Salesforce Setup or export the Schema Builder for reference.

Summary

Avoiding duplicate field names ensures the BHRC (TR1) package functions smoothly and your custom fields remain fully accessible. By checking existing fields before creating new ones, following clear naming conventions, and using formula fields when conflicts arise, administrators can prevent data access errors and maintain healthy system performance.