Secure Candidates

Abstract

Product: Workbench

Summary

Candidates who are flagged secure are protected from being viewed in BrassRing from users who do not have a My Candidate relationship with the secured candidate or a My Req relationship with the selected req. To view secure candidates without the needed relationship, the BrassRing user must have the user type privilege Access Secure Candidates (ASC). Secure Candidates are excluded from the Candidate search feature for those user types without the privilege.

Clients have the ability, in Workbench, to configure the rules that define what makes a candidate secure.

Business Problems Addressed

Protect the privacy of certain candidates by limiting the access to these candidates to those BrassRing users that need to work with them. This might apply to candidates who are applying to highly visible positions such as CFO, or internal candidates applying to other internal opportunities. This function provides the ability to hide secured candidates within:

1. The Candidate search results.

2. Req folders for which the user does not have a “My req” relationship.

Relevant eLearning

Executive Recruitment by using the Secure Candidates Feature

Depending upon a client’s Executive Recruitment’s requirements, BrassRing customers might use the Secure Candidates feature along with the Secure Reqs feature for an executive recruitment solution. However, a comprehensive assessment of security requirements needs to be completed before the enablement and configuration process. It is also strongly recommended that extensive testing is completed in the Staging environment before going live.

Since the candidate’s security is based on the responses to candidate form fields, the candidate form fields can be:

1. Included as part of the Talent Gateway’s configuration. This way, as soon as the candidate applies to a position, the candidate is flagged as secure. It is important to note that the gateway that is used for Executive Recruitment should be configured for single job submissions only.

2. Updated by using a candidate import or candidate form import.

3. Manually added or edited in BrassRing.

4. Populated with a RAM trigger.

Capability Details

1. Workbench provides each BrassRing client with the ability to set their own rules for governing what makes a candidate secure. The security is based on the responses to a configured one per candidate form. A maximum of four candidate form fields can be used in configuring the secure candidate rules. Active and optionable field types can be used in the configuration (single select, radio button, check box, auto-fill fields whose source is one of these field types).

2. The Workbench user type privilege Access Secure Candidates grants users, in that user type, the ability to see secured candidates in the candidate search results and in reqs for which they are not part of the req team My req. Users without this privilege see their candidates in the req folders for which they have a My Req relationship, their secure candidates cannot be found by using the candidate search.

3. A backend flagging process marks candidates as secure based on the configured rules and the responses to those fields. The flagging process occurs:

   1. After any saved changes to the configured rules

   2. After any saved changes to the candidate form fields whether the changes are made manually or by using a TG update or candidate import.

4. After candidates are marked as secure, only BrassRing users with the Access Secure Candidates privilege can search and view secure candidates in the Candidate Search results. All other user types cannot search for secure candidates.

5. Only BrassRing users that have a My Candidate relationship with the candidate or users with the Access Secure Candidates privilege can view secure candidates in My Reqs. As well, only users with the Access Secure Candidates privilege can view candidates in req folders for which they do not have a My Req relationship. The secured candidates are hidden for all other users.

6. Confidential appears on the secure candidate’s Talent Record.

7. Manual stacking logic. When a user with the manual stacking privilege selects the Stack duplicates action item, Confidential displays next to the name for each Secure candidate that was selected.

Best Practices

As part of an overall solution to protect secure candidates, it is recommended to enable the Candidates in Queue privilege for ONLY the user types who also have the Access Secure Candidates user type privilege. The queue does abide by the secure candidate rules and does not breach security, however, best practice is to not grant it to the general population of users.

Process

Configuring Secure Candidate Function

1. Create or identify a ONE PER CANDIDATE form to be used in securing candidates. In some instances, an existing form can be used while in others, a new form is needed to secure candidates. In the example below, a new form is added specifically for securing candidates. In workbench select Tools → Forms → Candidate Forms.

   

2. Define your secure candidate rules by selecting Tools → Forms → Candidate Forms and selecting the candidate form that is used to secure the candidate. Select Candidate security admin”.

   

   1. Select the field, then select the field option to be used to secure the candidate. Select Save. A maximum of four fields can be configured.

      

3. Enable the user type privilege for those user types that should have access to ALL secure candidates, even if they do not have a my relationship. The user type privilege can be enabled by selecting Tools → Users → User Types. Edit the type permission for the user type and select Search. Enable Access secure candidates. This privilege is typically reserved for Admins within the system.

   

4. OPTIONAL: Your organization might choose to secure candidates based on a field selection that the candidate makes on the Talent Gateway. If so, update the Talent Gateway settings to include the questions that are used in securing candidates.

5. OPTIONAL: Your organization might choose to secure candidates based on a field selection on the requisition. For example: If the requisition’s job code is an executive level job code. If so, a RAM might be needed to populate the identified candidate form fields that secure the candidate upon submission.

6. OPTIONAL: Your organization might choose to secure candidates based on a user adding a ‘secure candidate’ candidate form. If so, permissions should be added to that candidate form to allow user types to add, edit, and view the form as needed.