Within Eploy there are 4 main User Types:

  • Standard Users
  • Hiring Managers
  • Vendor Users
  • Candidates

Each user type will access the system via a different Portal and their visibility of data and ability to manipulate that data will vary depending on the user type and the permissions each user has.

To jump to a specific user type description in this article, please use the links below:

Standard Users

Standard Users, also known as Core System Users, access Eploy through the main Core System.

This is the all singing, all dancing version of Eploy, giving anyone who accesses it the ability to see all information related to your Recruitment activity including Vacancies, Candidates, Applications, Interviews and Job Offers (we refer to these as Placements).

The Core System is also where you carry out all Admin activity (such as managing Email Templates and Recruitment Workflows) and Reporting.

Given the wealth, and sensitivity, of the data available within the Core System, Standard Users should be restricted to your Recruitment, Onboarding, and HR Teams only.

To tell us who your Core System users are going to be, please complete the Core System Users specification document, available within your Teamwork project.  If the user needs to have full admin access, please put Y in to the Super User column.


Roles allow you to define which parts of the core system your users can access, what types of Data they can view and what actions they can carry out.

Here are a few examples, each of which can be achieved by having different Roles :

  • Hiding Senior Leadership Team Vacancies
  • Hiding Candidates who have applied for senior roles
  • Restricting the visibility of Vacancies to specific areas of the business
  • Restricting access to sensitive data, e.g. Equal Ops, to just those who need it
  • Read Only Mode
  • Super User Access

Each User must have a role assigned to them before they can access the system, but each User can have several Roles assigned to them.

As a default, your Eploy system will come with two Roles - Admin and Recruiter.  The Admin role gives full system admin access to the system; whereas the Recruiter role limits access to just those areas of the system which a recruiter needs to be able to cary out their duties e.g. they can see and edit Vacancies and Candidates, but they are not able to edit Email Templates and Workflow settings.

Your Implementation Manager will be able to tell you more about the default roles in your system, and can discuss with you the need for any additional roles you might have.

Hiring Managers

Hiring Manager Users access Eploy via the Hiring Manager Portal.

Within the Hiring Manager Portal, the view of data is limited to only those Vacancies the Hiring Manager is either directly associated with, or has visibility of thanks to Hierarchy and Security settings.

Within the Hiring Manager Portal your managers can:

  • Raise and Approve Vacancies
  • Review and progress Applications
  • Schedule and complete Interviews
  • Create and Approve Placements (offers)
  • Review returned References

Typically Hiring Manager Users would be those employees who need to be involved in some kind of Recruitment activity, either directly recruiting for themselves or others, assisting with recruitment activities, or approving Vacancies and Placements.

Hiring Manager Permissions

Hiring Manager Permissions give each Hiring Manager access to the relevant part of the system within the HM Portal.

These Hiring Manager Permissions work in tandem with Hiring Manager Settings, captured within the Recruitment Workflow.  

The permissions activate that part of the system within the Hiring Manager Portal. 

The Hiring Manager settings within the Recruitment Workflow dictate whether your Hiring Manager can see applications at a given point in the process and governs what they can do with the Application.

For example, for a Hiring Manager to be able to reject a Candidate, they'll need both the relevant permission and the setting within the workflow.  To make things more complicated, you can have multiple Recruitment Workflows, each with different a Hiring Manager might be able to reject a Candidate on one Vacancy, but not on another, because the settings on the workflows are different.

Hiring Manager Permissions are broken down in to 7 Categories, and the permissions available are largely the same for each:

  • Vacancy Submission - Do you want your Hiring Managers to be able to see Vacancies, create Vacancies (insert) and edit Vacancies?  In some circumstances, they may even be able to delete Vacancies.
  • Talent Pool - Do you want your Hiring Managers to be able to see talent pool candidates i.e. Candidates who have applied to their Vacancies in the past, but who might not currently have an active application (Hiring Managers do not have visibility of all Candidates)?  If they can see these Candidates, do you want them to be able to create an Application on their behalf, by moving them to a stage in the Recruitment Workflow?
  • Long List - this is a group of Candidates which the Recruitment Team has identified as potentially being suitable for a Vacancy, without actually submitting an Application.  Do you want your Hiring Managers to be able to see these Candidates and, if so, should they be able to create an Application for them, by moving them to a stage in the Recruitment Workflow?  Also, do you want them to be able to contact the candidates from within Eploy?
  • Application Stages - Typically, these are the initial review stages within your recruitment workflow and usually take place before an interview is scheduled.  While at these stages do you want your Hiring Managers to be able to Edit the Application and update the Application Status, see and add commentscontact the Candidates and move the application from one stage to another?
  • Action Stages - These are your Interview stages.  While at these stages do you want your Hiring Managers to be able to edit and update the Application and Status, see and add comments, schedule interviews, contact the Candidates and move the application from one stage to another?
  • Interview Slots - These are effectively empty interviews, typically used to capture a Hiring Manager's interview availability.  As Candidates are assigned an Interview Slot, the slot is removed and the Interview is scheduled (using an Action, which we'll talk about later).  For Interview Slots, do you want your Hiring Managers to be able to see them, create them, edit them or delete them?
  • Placement Stages - These are your Offer stages.  Candidates who reach these stages in your Workflow are about to be, or have been, offered the job.  Do you want your Hiring Managers to be able to see Placements, edit the Placement, create a Placement, delete a placement, contact Candidates or move the application from one stage to another?

It's worth reiterating that all these permissions do is give the Hiring Manager the facility to do these things - whether they have the ability to do them will all depend on the settings captured within the Recruitment Workflow.

If you have any questions about these permissions, please have a chat with your Implementation Manager.

Once you're happy, please fill in the Hiring Manager Permissions specification document, available within the Files tab in your Teamwork project.  You'll be able to tell us who your Hiring Managers are using a different specification document, which we'll talk about later.

Named or Generic Hiring Managers?

Typically, Hiring Manager accounts will be assigned to named individuals, and that account will be used exclusively by them.

There are occasions, however, where generic Hiring Manager accounts might be more suitable.

Retail and Hospitality organisations are great examples.  Head Office or Regional Managers would use a named account, whereas Store/Restaurant/Hotel Managers might use a generic account, named with the Store/Restaurant/Hotel Name, rather than the actual manager's name.  

If one of these managers had a named account, and they then left the business or moved to another location, you'd have to create a new account for their replacement and reassign all active Vacancies to the new manager.  Whereas if you used a generic account, the new manager would be able to pick up where the old manager left off without any admin intervention from you.

Obviously, there are security considerations to take in to account when setting up generic users, but we have tools available which can mitigate these, such as forcing a password change after a defined period of time (e.g. every 30 days) or using an IP Address restriction to prevent that Hiring Manager user from being able to log in unless they are connected to the the network.

If you'd like to explore these options in more detail, please have a chat with your Implementation Manager.


As we're talking about Hiring Managers, it's a good time to mention the Contact record. 

We'll go in to this in more detail later or in these articles, but at this stage it's enough to know that for someone to be given a Hiring Manager User account, they also need to be set up as a Contact within the system.

You're free to set up all employees as Contacts within the system if you wish, but only those who need to access the Hiring Manager Portal will need to have a Hiring Manager User assigned.

Next, we're going to talk about Vendor Users - these also need a Contact in the system.  Standard Users do not need a Contact (but you can give them one if you like).

Vendor Users

Vendor Users access Eploy via the Vendor Portal, also known as the Agency Portal.

As the name implies, the Agency Portal is used by employees from your preferred supplier list Recruitment Agencies.

Within the Vendor/Agency Portal, the user can:

  • See any Vacancies specifically assigned to them (i.e. they can't see all Vacancies)
  • Register Candidates and submit Applications on their behalf (up to a limit set by you when assigning the Vacancy)
  • View and accept Interview invitations
  • See what stage each of their Candidates have reached within your Recruitment process

Typically, any email that would normally be sent to a Candidate directly will go to the Agency User who submitted the Candidate's Application instead.


Your Candidates are those individuals who wish to apply for your Vacancies.

Candidates access Eploy via the Candidate Portal and their view of data is restricted to only their own data and those Vacancies which have been advertised.

Generally, Candidates will register themselves via the Candidate Portal, but their record can also be created by a Vendor User or from within the Core System.  Hiring Managers do not have the ability to create Candidates.

Within Eploy there is no difference between a "normal" Candidate and a Talent Pool Candidate - all Candidates are automatically available for Talent Pooling activities, unless they have specifically opted out of such activity.

As mentioned earlier, you're free to add all of your existing employees in to the system as Contacts, but if any of them wish to apply for a Vacancy, they must also have a Candidate Record.

Powered by Zendesk