Who Joined My Talent Network? And how did they get there?

Our company is looking to enable Talent Network forms now and running into some of the same issues and limitations. Being about to add source codes and track source via TNF would be a great enhancement functionality. 

We are implementing JTN and Talent Communities at the same time and therefore we are leveraging the Talent Community and workflow automation to automatically add candidates who join via the TNF into a talent community. This is an easy way to identify prospects who are added to your Eightfold Talent pool via JTN and Recruiters and use that talent community to source and engaged with the prospects. 

Hi Blake and Gina, 

My company is new to EF and we are also looking for data to show the growth of our Talent Network. Have you been able to get this data out of EF?

Hi everyone, here’s the strongest approach I’d recommend based on what I found:
 

Recommended path

Use Talent Network Plus / multiple JTN forms rather than one generic “Join Talent Network” link with only source-code tracking.

Eightfold’s JTN form enhancements support multiple forms using a jtn_form_id URL parameter. Each form can have its own branding, questions, and a specific jtnFormTagValue; when a candidate submits the form, Eightfold applies both the standard Joined Talent Network tag and the form-specific tag. That gives you a more actionable tracking mechanism than source analytics alone, because the form tag can be used downstream for segmentation, reporting, and automations.

For your team-member-specific use case, I’d structure it like this:
 

Answers to the questions

If we have a “Join Talent Network” link with source code specific to each team member, how could we identify them in Eightfold?

If you rely only on source code, the current evidence suggests that source analytics may show aggregate source performance, but it is not necessarily available as a candidate-search filter. A better pattern is to use team-member-specific JTN forms or form-specific tags. The JTN form framework supports passing jtn_form_id in the URL and applying a specific jtnFormTagValue when that form is submitted.

Example:

• /careers/join?...&jtn_form_id=drew_sales_na
• Form tag: JTN_Source_Drew_Sales_NA
• Automation: when tag = JTN_Source_Drew_Sales_NA, add to relevant Talent Community or saved segment.

The source code is captured in the source analytics dashboard but is currently not something we can filter by. Should it be?

Yes — from a product standpoint, this sounds like a valid enhancement request. If source code is captured in analytics, it would be valuable to expose it as a candidate-level filter and/or exportable field so recruiting teams can operationalize it, not just report on it.

That said, for today, I’d avoid making source code the only tracking mechanism. Use JTN form IDs/tags as the operational source of truth, and source analytics as supplemental attribution. There is precedent that JTN usage lists can be produced from Data Hub by querying profiles with the Joined Talent Network tag, but click-level data for users who clicked and did not submit was not available in the support case I found.
 

How do you identify candidates who joined your Talent Network in Eightfold?

The standard identifier is the Joined Talent Network profile tag. One support case recommended querying the profile tags table where profile_tag = 'Joined Talent Network' to produce a list of joined candidates with fields like profile ID, joined timestamp, email, and location.

Also, candidate responses to JTN forms can be viewed on the Talent Network Responses tab on the candidate profile when the JTN response capability is enabled/configured. For broader reporting, a daily export of JTN form completions can include one row per submission, timestamp, profile ID, form tag/form ID, and response fields.
 

How do you capture location when importing via CSV?

Location is supported, even if the sample template does not make it obvious. The Import Resumes documentation lists Location/Phone Number and Address as optional candidate CSV fields. A prior support/Jira thread confirms that the CSV template is just a sample: you can rename/add a column and then map it to Location / Address during column mapping.

Important nuance: if you split location into separate City and Country columns, past evidence suggests that may not map cleanly as two separate location fields; the safer workaround is to provide a single consolidated location value, such as:
 

• London, United Kingdom
• Toronto, ON, Canada
• Berlin, Germany

Then map that column to the supported Location/Address field during import.