Skip to main content
Documentation
Documentation
Administrator Guide
Last Updated: 2026-05-15
Concept: Masking Candidate Data

Concept: Masking Candidate Data

You can mask, or hide, some candidate data in VNDLY for specific scenarios. For example, you can mask candidate data when hiring for jobs in a country with specific anti-bias regulations. This feature can help your program reduce unintentional bias during the hiring process by enabling users to manage candidates without viewing their personal information.
Currently, you can mask these types of candidate data:
  • Names
  • Email addresses
  • Physical addresses
  • Residential statuses

Permissions for Masking Candidate Data

To view the types of candidate data listed above, users need view permissions for fields where the data displays. If you want to mask any of these types of candidate data, remove the permission from the user role:
Candidate Data Type
Fields
View Permission for Fields
Name
  • First Name
  • Middle Name
  • Last Name
  • Preferred First Name
  • Preferred Last Name
candidate.name.read
Email address
  • Candidate Personal Email
  • Candidate Secondary Email
candidate.email.read
Physical address
  • Address
  • Country
candidate.address.read
Residential status
  • Residential Status
candidate.residential_status.read
However, if you remove any of the above permissions from user roles that have the
candidate.read
 permission, users can still view candidate data on the
Candidates
 list page accessed from the VNDLY header and on candidate records.

Impacts to the User Interface

If you remove the view permission for any of the fields listed in the table above, users will see a
Hidden
 label and a lock icon next to the field instead of the candidate’s data.
Additionally, if you remove the
candidate.name.read
permission, users see a system-generated ID in places where a candidate’s full name typically displays. For example,
Candidate KZHRK
 displays instead of
Joe Smith
. This enables users to track specific candidates during the sourcing process without viewing their names.
These impacts apply throughout the VNDLY user interface, except on the
Candidates
 page and on candidate records for users with the
candidate.read
 permission.

Example

You want to mask candidates’ names from hiring managers during the job workflow to help reduce bias. However, you don’t want to mask candidates’ names from MSP users who oversee jobs but don’t select specific candidates.
To do this, you make sure MSP user roles have the
candidate.name.read
 permission, while hiring manager user roles don’t have it.
As a result, hiring managers see a system-generated candidate ID in places where candidates’ full names display, as well as a
Hidden
 label and a lock icon next to specific candidate name fields. MSP users see candidates' full names and individual name fields.