Reference Collection - What is it?

Hopefully this one is relatively obvious - this is the suite of tools we have within Eploy which you can use to manage how References are collected.

The Reference Collection module has three main elements:

• Reference Collection Settings
• Reference Collection Forms
• Reference Collection Email Templates

Unless you tell us otherwise during Phase 1 of your Implementation, your new Eploy system will come pre-loaded with our default Reference Collection configuration.

What do I need to think about when planning?

The default reference collection settings in your live system will be relatively simple when compared to the settings you'll find within your demo system. During this phase of your Implementation it's really important that you spend some time looking at how your demo system has been configured as this will help showcase the kind of things that can be done, which can then help inform how you'd like to configure the reference collection settings in your Live system, during Phase 3 of Implementation.

When reviewing the reference collection settings in your system, here are some key things to look at and bear in mind:

Collection Settings

This is the part of the module which controls how references are requested and allows you to specify:

• Which forms your referees are asked to complete.  You can have a different form for each reference type

• Whether the completed form is saved as a PDF and whether the referee is able to upload their own reference file

• The initial request and reminder emails (along with the reminder interval), which are sent to the referee, along with any additional emails you'd like to be sent when the reference is completed or has expired

• Emails sent to the Candidate when the reference is received, expired or refused

• Emails sent to system Users, or non-system email addresses, when a reference is completed, expired or is refused

Although your system will come with a single instance of these settings, you're more than welcome to create additional settings.  That being said, as with things like Flows, Recruitment and Authorisation Workflows, just because you can have multiple sets of settings, doesn't mean you necessarily need them.

One of the first things you'll want to consider when reviewing these settings is whether one set of settings is sufficient, or if you'll need several.  If you'll only ever need to use a single set of email templates and the forms that need to be completed every time are the same, you'll only need one set of settings.

If, however, your organisation has multiple brands and you want the reference collection emails issued to match the branding of the role being applied for, then you'll need multiple settings.  You'll also need multiple settings if the forms the referee needs to complete vary from one role type, or brand, to another.

In addition to the individual collection settings, there are also some global settings to consider (global in that they apply to the system as a whole irrespective of the collection settings being used:

• You can specify how long a reference request should remain active, after which the request expires and cannot be completed (this would trigger the expired email mentioned above).

• Do you want to display a Right to Contact file to the referee?  This is an optional document you can ask your Candidates to electronically sign which demonstrates to the referee that they have given their informed consent to contact the referee.  If you do want to use a Right to Contact file, you'll need to think about the design of this document - your live system will come with a basic example which you'll be able to amend during Phase 3 of your Implementation.

• Do you want your Hiring Managers to be able to see completed references?  If so, do you want them to be able to update the Reference Status (e.g. indicating if it's suitable or not) and download completed reference files?

• Finally, if Hiring Managers can see references, do you want them to be able to submit references?

Reference Types

Your system will come with two reference types as a default: Employment and Character.  These reference types can have their own individual form to complete, as specified within the Collection Settings mentioned above.

This is just the default though - you can have as many reference types as you wish.  At this stage of your Implementation you'll need to decide if the default reference types are sufficient and, if you need more, what these reference types should be called.  During Phase 3 of your Implementation you'll be able to add these additional reference types in to your system, and once that's done, you'll be able to specify the forms they should complete as part of your collection settings.

Reference Statuses

As with Vacancies, Applications and Placements, we use Statuses to track what's happening with your reference requests.

The system comes pre-loaded with 6 reference statuses.  Four of these are system statuses, which cannot be changed, and are used to trigger events related to the reference request.  The others can be changed as required, and you can add to the list if you wish:

• Requested - this is a system status and cannot be changed.  This is the status used when the request is made and triggers the initial email to the referee

• Received - this is a system status and cannot be changed.  Eploy will automatically put all completed reference requests to this status, indicating that they need to be reviewed.  It is also used to trigger the relevant completion emails, if they have been configured.

• Expired - this is a system status and cannot be changed.  When the reference request has been open longer than the expiry window entered in to the global collection settings (discussed above), Eploy will change the status of the request to Expired.  At this point the request cannot be completed and the relevant expiry email will be sent.  It is also used to trigger the relevant expiry emails, if they have been configured.

• Refused - this is a system status and cannot be changed.  If the referee refuses to complete the reference Eploy will change its status to Refused.  This will trigger the relevant refusal email.  

• Checked - Suitable is a status we've added in to the system to indicate that the reference has been reviewed and is deemed to be acceptable.  You're free to rename or archive this status

• Checked - Not Suitable is a status we've added in to the system to indicate that the reference has been reviewed and is no acceptable.  Again, you're free to rename or archive this status.

At this stage in your implementation there's two things you'll need to do: decide on whether the Checked - Suitable and Checked - Not Suitable wording is sufficient or needs to be changed; and, whether you need any extra statuses. 

Collection Forms

When a referee receives a reference request email and follows the link, they'll (typically) be given three options: Complete the reference, upload their own or refuse the reference request.

If they choose to complete the reference, the form you've selected within the collection settings will be displayed - this is the form you use to capture the reference information you need.

As a default, your system will come with a single Reference form, used for both the Employment and Character reference requests.

Where this default form is concerned you'll need to make two main decisions:

• Are the questions contained on the default form sufficient, or do you want to ask additional questions?  
• Is it ok to use the same form for both Reference Types, or do you want to ask different questions depending on the reference type?

If you're going to stick with a single form, but you'd like to ask extra questions, you'll need to identify what these questions are.  You'll also want to give some thought as to whether you'll ever want to be able to report on, or otherwise export, the answers provided - if you do, have a chat with your Implementation Manager with a view to them being added in to the system as Standard Fields (if the questions are not standard fields, they won't be reportable).

If you're going to have a different form for each reference type, you'll need to have a think about what the form will need to look like, thinking in terms of question layout and paging.  Again, if you want to report on any of the answers, let your Implementation Manager know so they can look at building the questions in to your system as Standard Fields.

Collection Email Templates

The last thing to think about where Reference Collection is concerned is the design of the email templates you'd like to use.

We've already explored, in detail, the kind of things to consider where the design of email templates are concerned in this article.

Thinking in terms of Reference Collection email templates specifically, there are three categories of emails to consider:

Referee Emails - with each Reference Request, there's the potential for 4 different email templates to be used: the initial request email, the reminder email, the email once the request has been completed, and the email sent when the request expires.  You'll need to consider the design and content of these email templates.  Tip when looking at the Initial and Reminder email templates, don't forget to let the referee know that they'll be able to upload their own reference, or refuse the request, by following the link within the email.

Candidate Emails - there are three email events, and therefore templates, to consider: when the reference is received, expired and refused.  

User Emails - as with Candidates, an email can be sent to system users when a reference is completed, expired or refused.

You'll also want to give some thought to the number of Collection Settings you have - you have the facility to specify a different email template within each of the collection settings.  So give that some thought - do you want to have the same set of templates for each set of collection settings, or do you want to have different ones?

As a final thought on templates, I just want to bring you back to a recurring theme throughout Eploy - just because you can have multiple iterations of something doesn't mean that you need multiple iterations.  This applies to these email templates as well.  For example, just because you can send an email to candidates or system users when a reference is refused, doesn't mean you have to.  It's entirely up to you how many of these email touch-points are used - you're more than welcome to configure your collection settings to only send an initial email to the referee and leave it at that, and have each collection setting use the same template, if that's how you'd like it to work - that would mean only needing to configure a single reference collection email template.  To put your mind at ease further, from a system user perspective, we have a whole section within the default Onboarding Management dashboard which provides information on reference requests, returns, refusals and expiry.

I'm still not sure what I need to do - are there any examples I can see?

To answer this, let me refer you to your Demo System (see what I did there...refer...reference collection??  I'll get my coat...)

Reference collection is one of those areas where you're likely to see much more configuration work within your Demo system compared to your Live system - within the demo system we're simply showing you what can be done, if you choose to go beyond our default settings.

To view the reference collection settings log in to the Core System and navigate to Admin > Reference Collection.

Once on the page you'll be to click in to the settings, at the bottom of the page, to see how that's configured.  You'll also be able to see the forms in use within the Forms tab, and the email templates within the Emails tab, both of which are towards the top of the page, on the left-hand side of the screen.

Tip we'll be looking at Reference Collection settings towards the end of the second Customer Configuration webinar.