As Vendors submit candidates against roles, its important to ensure that records that already exist on the database are flagged up or even prevented from being duplicated. Eploy can help you manage this with Duplicate Checks & Candidate Ownership policies.

Duplicate Checks

When a candidates registers via the candidate portal, we use the email address to help ensure that they don't create duplicate records. It isn't quite that simple for Vendors though, as they may not provide the candidates direct email address at this stage. With this in mind, there are a number of fields we can use for duplicate checks instead:

  • First /Surname - This should form the basis of your check, used along side atleast the postcode to help ensure that the candidate does not already exist on the database.
  • Postcode - This can be effective, when used in conjunction with the name fields, as it is information that is likely included in an CV submitted by the candidate - so asking for the vendor to provide this is a good way of comparing to the database and ensuring that they have the information on the candidate.

  • Date of Birth - This can also be an effective unique identifier, but only if the information is captured early enough in the process. Similar to NI number, if the data is not available for most records, it will not be an effective check.

  • National Insurance Number - This would be ideal as it's unique to each Candidate.  However, if you don't capture a candidate's National Insurance Number until they reach the Onboarding stage, then it's likely that you won't have the National Insurance Number for most of your database, rendering the check ineffective at this stage.

When deciding on your duplicate checks, keep in mind that it needs to be information that you store for every candidate.

Candidate Ownership

Once the duplicate checks have identified a potential match, you can then decide what happens next, using the Candidate Ownership policies.

There are lot of considerations to make, when deciding on your ownership policy for vendor candidates & Eploy helps to address those with the following scenarios:

  • Can Agency A submit Joe Bloggs to Vacancy 1 if Agency B has already submitted Joe Bloggs to Vacancy 2?

Hint - This is helps to identify if you consider candidates exclusive to the agency (Answering No they cant to the above) or exclusive to the vacancy only (answering Yes they can etc)

  • Can Agency A submit Joe Bloggs to Vacancy 1 if Joe Bloggs has applied to that job via your careers site?

Hint - This helps to apply the policy on candidate ownership, between your organisation & the agency for any candidates that have already applied directly.

  • Can Agency A submit Joe Bloggs to Vacancy 1 if Joe Bloggs has previously registered speculatively and is in your Talent Pool or has previously applied to other jobs?

Hint - This is the one that often requires the most thought, as the candidate is already in your data base & has potentially applied or been considered for other roles. If you chose to stop that agency from putting the candidate forward for this role, you are relying on finding the candidate within the talent pool or deciding to put themselves forward. It also means that you may miss out on their latest CV, with additional skills & experience etc.

If you need help with any of these scenarios or settings, please contact Eploy Success & we can help apply them to your policies. 


Powered by Zendesk