Password and Security Settings - What are they?
Password and Security settings is the catch-all term we use to represent several settings within Eploy.
In general, these settings allow you to configure the access restrictions you want to use within your system for your Core System Users, Hiring Managers, Candidates and Vendors.
📌 Note :These settings won't apply across all user types - several of these settings don't apply to Candidates, for example. We'll highlight in the following section where each of these settings apply.
What do I need to think about when planning?
For a lot of these settings you might want to get your IT and Security teams involved, to ensure the settings you apply are aligned to similar settings in your other systems.
Having read the descriptions of each setting, you'll need to decide how you want each one to behave, assuming you want to use it at all.
Email Contacting Preferences
These settings apply to Core and Hiring Manager users, with separate settings for each user type.
These settings allow your users to send emails, from within Eploy, and have that email come from an alternate email address.
There are two things to consider, both for your Core Users and Hiring Managers:
Do you want all users of this type to be able to send emails from any email address (they'll be able to type in the email address they want to send from)
Do you want to give all users of this type a standard alternate email address to send from, and if so, what will this email address be? This setting can be really useful if you want to give your users the option of sending emails from either their own email address or your central recruitment email address
One key thing to bear in mind here is email white-listing.
Without getting in to too much detail around how this works, as part of the set-up of your system, you'll basically be allowing Eploy to pretend that any emails it sends have come from your internal email servers - this white-listing is what ensures that emails sent from Eploy don't get blocked by firewalls or junk/spam filters.
If you allow your users to send from any email address, there's a risk that the email sent will get blocked by the recipients email filters, or marked as junk - there's nothing we can do to prevent this, so you'll need to bear this in mind.
Password Policy
These settings apply to all users, with separate settings for each type.
This is where you control things like password complexity and age.
For each user type, you'll need to decide:
Minimum Password Length: how many characters, as a minimum, each password should be.
Password Strength: do you want to use Strong or Very Strong passwords? Our passwords are configured to accept Upper and Lower case letters, numbers and special characters. Strong passwords must have at least three of any of these character types (e.g. you could have just three numbers to satisfy the criteria) whereas Very Strong passwords must contain at least one of each character type.
Password History: this setting controls whether the user can re-use a previous password when they change their current password. Specifically, you're controlling how many previous passwords Eploy will remember and therefore prevent the user from using. E.g. if you set this to six, Eploy will remember the last six passwords I've used and if I'm changing my password I won't be able to re-use any of these six.
Password Age: this setting allows you to control how frequently your users must change their password, in days.
Remember Username: this setting controls whether the users internet browser is allowed to remember the username.
Autocomplete: this setting controls whether the user can use their internet browser's in-built ability to remember both the username and password and auto-fill these fields when they come to log-in.
Forgot Password: this one is quite simple: do you want your users to be able to click a forgot password link and have the system send them a password reset email.
Lockout Policy
These settings apply to all users, with separate settings for each type.
You can specify how many invalid attempts a user can make to log-in before a CAPTCHA window will be displayed. This CAPTCHA window will challenge the user to do things like identifying Cars, Busses and Bikes in a picture, to prove they're a human.
If they pass the test, they'll be able to try logging in again.
You can also specify how long Eploy will remember the invalid login attempts for, before resetting.
For example, if I set the invalid attempt counter to three and time period to 30 minutes, then if I have three failed login attempts within 30 minutes, the captcha will display. If I do two in a 30 minute period, and the third after a further 15 minutes, the captcha won't display.
Social Logins
These settings apply to all users, with separate settings for each type.
This one is simple - do you want your users to be able to login to the system using a Social Media platform?
You have three options: Facebook, Google and LinkedIn.
For Candidates, there's also the option of having Eploy save the profile picture when logging in via Facebook and LinkedIn.
Corporate Single Sign-On
These settings do not apply to Candidates. There is a different setting for Core Users, Hiring Managers and Vendors.
You'll only need to worry about this section if Corporate SSO has been included within the scope of your system.
If it has, we'll have already discussed with you how this works and we'll work with you to get this set up.
Corporate Calendar Sharing
These settings apply to Core and Hiring Manager users, with separate settings for each user type.
This setting allows you to link your system with your corporate calendar provider (Office 365 or Gmail).
As far as preparation is concerned, the only thing you need to think about is:
Whether you want to use it, and if so...
Who can see the full details of a calendar
Who can see the limited details of a calendar
Who can see availability only
For each of these settings you can specify that nobody can see this, all users can see this, or only specified users can see this.
🤓 Tip if you're using Office 365, there's also the option of linking your Eploy system with your Teams account, giving you the option to schedule Teams meetings directly within Eploy.
We'll run through in detail how to configure these in the next phase of your Implementation.
Online Meetings
These settings are configured against Core System Users, but will automatically apply to Hiring Managers as well. They don't apply to Candidates and Vendors.
This is our integration with Zoom and gives you the ability to set-up Zoom meetings from within Eploy.
Again, the only thing to think about at this point in your Implementation is whether you want to use it or not. Chances are, if you use Teams internally, you won't want to use Zoom (especially as each user and Hiring Manager will need their own Zoom account).
If you don't use Teams or Zoom (you might use something like GoToMeeting), then you won't be able to use this integration.
IP Address restrictions
These settings apply to Core Users, Hiring Managers and Vendors, with different settings for each user type.
This is your ability to really restrict where someone can access the system from, thinking in terms of IP Addresses.
For example, if you want to ensure that your users can only access the system when physically connected to your network or VPN, you can enter the relevant IP Addresses here.
As this stage of your implementation you simply need to decide whether you want to use this feature and, if so, start pulling together a list of the IP Addresses you want to use for each user type.
2-Factor Authentication
These settings apply to Core Users, Hiring Managers and Vendors, with different settings for each user type.
2-Factor Authentication is an additional layer of security you can add to your login process. When used, and a user accesses the system with Username and Password, the system can send a 1-time-use code to their registered email address or mobile phone, or they'll be able to use an Authenticator app (such as Google Authenticator) to generate a 1-time-use code.
The user will then need to input the code in addition to their username and password - if they enter the wrong code, they won't be allowed to login.
From a preparation perspective, you'll need to:
Decide whether this is a feature you want to use
If you are going to use it, do you want it to apply in all situations, or only when someone is trying to access from outside an approved IP Address range...and whether this should apply to all users or specific user types
Which authentication methods do you want to use
Portal Configuration
This setting only applies to Hiring Managers, and it's technically not a security setting.
This setting allows you to configure how how the Candidate Overview and Vacancy tabs behave within the Application Dialogue in the Hiring Manager Portal.
You have the ability to configure which fields are displayed in each of these tabs and the ordering of each field. Whatever settings you input here will apply to all Applications and all Hiring Managers.
To configure this properly, you'll want to consider (both for Applications and Vacancies):
Which fields do you want your Hiring Managers to see
Which order should the be displayed in
Do you want to group the fields in to bespoke sections
View an example
Log in to your Demo Core System and click on Admin, followed by System/Security Settings.
Here you'll see the various user types - select the appropriate user type and that will display the security settings for that user type.
