Secure Requisitions

Abstract

Product: Workbench

Feature Summary

Requisitions that are flagged secure are protected from being viewed in BrassRing from users who do not have a My Req relationship with the secured req. To view all secure reqs without the needed relationship, the BrassRing user must have the user type privilege Access secure reqs. Only users with this privilege, or users with My reqs relationship with the Secure req, can view the candidate information pertaining to the Secure req submission. Otherwise, ALL secure req submission data is hidden from the user.

This function hides secure reqs from users without a My req relationship within Search Reqs results (Regular and Quick Search) and View all Reqs results.

Reqs are flagged Secure depending upon configurable rules. The privacy of certain recruitment efforts is protected by limiting access.

Relevant eLearning

Business Case

Protect the privacy of certain recruitment efforts by limiting the access to these reqs to those users that need to work on them. This might apply to highly visible positions such as CFO or internal positions that need privacy.

Executive Recruitment by using the Secure Reqs feature: depending upon Executive Recruitment's requirements, clients might use the Secure Reqs feature along with the Secure Candidates feature for an executive-level solution. However, a comprehensive assessment of security requirements needs to be completed before the enablement or configuration process. It is also recommended that extensive testing is completed in Staging before going live.

Capability Details

1. Workbench configuration can set rules for governing what makes reqs secure. Rules can be set per req form or applied to multiple req forms. The security is based on select fields and their options, found on the configured req form, up to a maximum of four fields. Only active and optionable fields can be used in the configuration (single select, radio button, check box, auto-fill fields where the source is one of the previous field types).

2. The Workbench user type privilege Access secure reqs grants users the ability to see secured reqs for which they are not a part of the req team my req. Users without this privilege see their req folders for which they have a My Req relationship.

3. A back-end flagging process marks reqs as secure based on the configured rules and the responses to those fields. The flagging process occurs:

   1. At the time a req is created and saved

   2. After any saved changes to the req fields whether the changes are made manually by using Edit Req or req import, up until the req is opened. After the req is opened, its security cannot be updated or changed.

   3. If Custom Approval Workflow (Smart Approval) is configured and the user sees a Save and Continue button on the Edit req page, req security is checked before sending the req through the approval process.

4. To search for and view reqs that have been flagged as secure, and req submission data, the user must have either:

   1. My req relationship (req creator, a req team member, the hiring manager role in BrassRing or Recruiter role in BrassRing

   2. The user type privilege Access secure reqs along with one of the All Reqs - xxx privileges.

5. Confidential appears on the Req details page for secure reqs.

6. All candidate req data pertaining to a secure req is hidden from users without My req relationship or Access Secure Reqs (on the Talent Record, on the grid views, and Send Communications, Print Resume, Forward by using email, Bulk print, and eLink action items). Candidate Req Data ('Submission data') includes:

   1. Codes (All code types that are associated with candidate submission such as Req Code, Job Code, Source code, and custom code types)

   2. HR Status data on HR status tab.

   3. eLinks History data on eLinks tab.

   4. Resume data on Resumes tab.

   5. Forms data on Forms tab.

   6. Attachments data on Attachments tab.

   7. Communications History on Communications tab.

What data can or cannot be viewed in candidate views

1. Icons display based on their calculated value; therefore, the condition or status they reflect might refer to data the user cannot access.

2. Last Codes: becomes a Click here hyperlink to the Add codes page, displaying accessible req codes.

3. eLinks: 'eLink' action that is taken from within a req or Working folder view or grid:

   • Resume: The system sends the resume that has been submitted for that requisition. If the eLink action is taken from within the Talent Record, the system sends the resume currently being viewed. If no resume has been submitted for that resume, the system sends the most recent resume that the user has access to.

   • With HR Status:

     • System user recipient only sees the HR statuses to which they have access to

     • Non-system user recipient only sees HR statuses to which the sending user has access to at the time of viewing the eLink

     • Best Practice: It is recommended that the client setting HR Status limited to req folder in eLinks is enabled for clients that want to use the Secure req client setting.

     The HR Status limited to req folder in eLinks setting displays only the candidate’s HR status information for the folder from which the eLink was sent is displayed in the eLink’s HR status tab. This applies to the display in the View Current and the View History views

   • With form to view:

     • Sending user: is only able to send forms to view which they have access as per the User type privileges permission combinations table or which are not per-req.

     • Recipient is able to view forms that they have access to by using form privileges. The Access secure req privilege is not evaluated on the premise that an appropriately privileged individual sent the eLink to the recipient. If eLink is sent to a non-system user, the user type that is used to determine access is Quick Start User.

   • With form to complete:

     • Sending user is only able to send forms to view which they have access as per the User type privileges permission combinations table or which are not per-req.

     • Recipient: is able to view forms that they have access to by using form privileges. The Access secure req privilege is not evaluated on the premise that an appropriately privileged individual sent the eLink to the recipient.

4. eLink action that is taken from a view or grid other than req or working folder:

   • Resume: The system sends the most recent resume that the user has access to as per the User type privileges permission combinations table. If the eLink action is taken from within the Talent Record, the system sends the resume currently being viewed

   • With form to view:

     • Sending user is only able to send forms to view which they have access as per the User type privileges permission combinations table (section 7.3) or which are not per-req.

     • Recipient is able to view forms that they have access to by using form privileges. The Access secure req privilege is not be evaluated on the premise that an appropriately privileged individual sent the eLink to the recipient. If eLink is sent to a non-system user, the user type that is used to determine access is Quick Start User.

   • With form to complete:

     • Sending user is only able to send forms to view which they have access as per the User type privileges permission combinations table or which are not per-req.

     • Recipient is able to view forms that they have access to by using form privileges. The Access secure req privilege is not be evaluated on the premise that an appropriately privileged individual sent the eLink to the recipient.

   • With HR Status:

     • System user recipient: only sees HR statuses to which they have access to.

     • Non-System user recipient: only sees HR statuses to which the sending has access to at the time of viewing the eLink.

5. Candidate search criteria:

   • Job Req Codes: can be dynamically removed from the criteria as defined by the user’s access to the req

   • If the secure req client setting is enabled AND the Job Code field is selected as a configured in the rules, all users are unable to use Job Code as a search field. The Job Code field is hidden from searching criteria page.

   • If the overnight search criteria uses Req Code, then a message displays: Note: Secure req client setting is enabled. Overnight searches exclude Req Code as search criteria.

Process

Configure Secure Req Function

1. Enable the Secure Reqs Client Setting. This is completed by an Infinite team member.

2. Identify a field or add a field on the req form that is to be used to secure the req. This can be created specifically for securing reqs. Select Tools → Forms → Reqs → Req Forms → Define Custom Req Fields.

    

3. Define your secure req rules by selecting Tools → Forms → Reqs → Req forms. Select the req form that you have added your field to and select Req Security Admin.

    

   1. Select Add rule.

   2. Select the field. Then, select the field option that is used to secure the req. Select Save. A maximum of four fields can be configured.

       

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

    

Secure Reqs in BrassRing

Users can mark the req secure or confidential when they are creating their requisitions. For example:

After a req is secured, it is marked as Confidential in BrassRing.