Common RAM Examples

1. Automated Disposition emails

RAM can send disposition emails to candidates that are moved to a disposition status by a BrassRing user. The example sends a predefined email template to a candidate, 24 hours after they are moved into a Company Not Interested HR Status. There is also a condition that states that the candidate must have a current candidate type of External, Agency, or Employee Referral. If the candidate is one of these candidate types, and is still in the Company Not Interested HR Status after 24 hours, the email is sent to the candidate.

How to Read or Create this RAM

• Trigger Name: Displays the name of this trigger. The name is used when troubleshooting in the RAM logs and submitting support tickets. There is no required format. It is recommend that consistent naming convention is used and that the Staging and Production RAM trigger names match.

• Triggering Mechanism: Select HR Status. This is the overall mechanism to trigger the RAM.

• Triggering Item: HR Status of Company Not Interested. This is the HR status that triggers this RAM. Your organization might have a different HR Status for dispositioning the candidates. If you do not see your HR Status in the list, it means that you are already using the HR Status for another trigger. In this case, add a rule to the other trigger to accomplish the goal.

• Timing Mechanism: Select Delayed Triggering. This option waits for the delay time to elapse after the event has occurred, and then fires the trigger. The trigger is fired and run at the same time, meaning Trigger event happens > delay elapses > trigger fires > trigger is run - rules are run. Delays are optional.

• Trigger Timing (hrs): There is a 24-hour delay that is built into the example trigger. This means that 24 hours following the HR status update by the BrassRing user, the RAM runs and sends the disposition email if the conditions are met. A shorter or longer delay can be added. Delays are optional.

Rule 1: Name the first Rule. The example name is External Candidate Disposition Communication. The name can be used when troubleshooting in the RAM logs and submitting support tickets. Multiple rules can be configured with different conditions to take different actions.

Conditions: Set the condition that the candidate must have a current candidate type of External, Agency, or Employee Referral. To do this, select Talent Record > Candidate Type > Equals External, Agency, Employee Referral. The communication can be standardized and automated and it allows BrassRing users to send a customized message to Internal candidates.

Actions: The Send Communication action means that the recipient can be selected as the candidate Talent Record email is used. The system sends the disposition email to the candidate’s contact email address.

2. Automated Disposition of Candidates (after a candidate is hired) and Unposting or Closing of the Requisition

A RAM can be configured to disposition all candidates that are not yet in a final disposition status, add a disposition form, and send a disposition email when a candidate is Hired to a req. The same RAM can also unpost and close the requisition. For this RAM to work properly, the client setting [ByPass ClosedLogic when Updating HRStatus in RAM] must be enabled. Contact your Infinite representative to enable this client setting.

How to Read or Create this RAM

• Trigger Name: Displays the name of this trigger. The name is used when troubleshooting in the RAM logs and submitting support tickets. There is no required format. It is recommend that consistent naming convention is used and that the Staging and Production RAM trigger names match.

• Triggering Mechanism: Select HR Status Req Options. The status update triggers the RAM and when req options are selected as the mechanism, it allows the RAM to run the trigger across candidates in the req.

• Triggering item: HR Status of Hired. This is the HR status that triggers this RAM. Your organization might have a different HR Status for the final [hiring] status for the candidates. If the HR Status is not in the list, the HR Status is being used for another trigger.

• Trigger Timing (hrs): A 10 minute (.10 hrs) delay is built into the example trigger. This means that 10 minutes after the candidate is moved to the HR status of Hired, the RAM runs and takes the actions if the conditions are met. Your organization might choose to implement a shorter or longer delay. Delays are optional.

Rule 1: Name the first Rule, for example Unpost and Close Req. The name can be used when troubleshooting in the RAM logs and submitting support tickets. Multiple rules can be configured with different conditions to take different actions.

Condition: No condition has been configured for this Rule. Having a condition is not always necessary.

Action: Select the Unpost and Close Req action. The RAM closes and unposts the req that the candidate is Hired for.

Rule 2: Name the second Rule, for example Disposition Remaining Candidates and Send Disposition Communication. The name is used when troubleshooting in the RAM logs and submitting support tickets.

Condition: Select the HR Statuses that are considered your non-final or intermediate statuses. The RAM looks for and takes action only on candidates that are currently in these statuses. Extra conditions can be added as necessary.

Actions:

• Select Send Communication. In this case, select the candidate Talent Record email so the system sends the disposition email to the candidate’s contact email address.

• If your organization uses disposition forms, the RAM trigger can be configured to create or populate the disposition form. Select the name of the Disposition form and the fields to populate. In this case, the form is called Disposition Form and populates the field of Disposition Category with the value of [Company Not Interested].

• Select Update HR Status. In this case, it updates all non-hired candidates, or candidates that are still in an intermediate status, to a status of Company Not Interested.

3. Candidate Accepts or Declines Offer

A RAM can be configured to notify the Recruiter, Manager, or other BrassRing users when a candidate accepts or declines an offer made through the candidate portal. This RAM can also update the candidate’s HR status.

• Improper RAM Trigger configuration, such as using the communication template with the new token but triggered by something other than the document subsidiary form insert or update, is not prevented in Workbench.

• This form cannot be accessed in add or edit mode from the eLink received by using email.

• The eLink in the communication is subject to the normal eLink expiration rules, for example clicks and days elapsed, as configured for your organization.

• The token text is the custom document subsidiary form title, in the same locale as candidate submitted it in. That is, if candidate responded with a French-Canadian document subsidiary form, the form token link shows the FR-CAN title.

Create a communication template

It is recommended to create a new communication template, or to have a communication template specifically dedicated for this communication. Within that communication template, add the merge token for document subsidiary form into the communication template, Merge fields category = Candidate Zone and Merge fields label = Completed Document Subsidiary Form (for RAM)

• Sample Token: [#Candidatezone:CompletedDocSubForm#]

• Upon saving the template in add or edit-mode, a validation is performed to ensure that this token may only be used if Sending method = Auto Send.

• As this token is intended to use only with RAM, this communication template is not to be available for send candidate communication workflow.

How to Read or Create this RAM

• Trigger Name: Displays the name of this trigger. The name is used when troubleshooting in the RAM logs and submitting support tickets. There is no required format. It is recommend that consistent naming convention is used and that the Staging and Production RAM trigger names match.

• Triggering Mechanism: Select Document Subsidiary Form Insert or Update. The insert or update of the selected doc sub form triggers the RAM to run.

• Triggering item: Select the appropriate Document Subsidiary form. This is the actual form that triggers the RAM. Your organization might have named the doc sub form differently.

• Trigger Timing (hrs): Delays are optional.

Rule 1: Name the first Rule, for example Offer Accepted. The name is used when troubleshooting in the RAM logs and submitting support tickets. Multiple rules can be configured with different conditions to take different actions.

Condition: Select the Offer Response document subsidiary form and select the Employment Offer Decision of I accept this offer of employment. When the candidate accepts the offer, the condition is met and the trigger runs the actions.

Actions:

• Select Send Notification to the Recruiter that the candidate has accepted the offer.

• Select Update HR Status to a status of Offer Accepted.

Rule 2: Name the second Rule, for example Offer Declined. The name can be used when troubleshooting in the RAM logs and submitting support tickets. Multiple rules can be configured with different conditions to take different actions.

Condition: For this condition, select the Offer Response document subsidiary form and select the Employment Offer Decision of I decline this offer of employment. When the candidate declines the offer, the condition is met and the trigger runs the actions.

Actions:

• Select Send Notification to the Recruiter that the candidate has declined the offer.

• Select Update HR Status to a status of Offer Declined.

4. Assessment, Background, or Interview Result Update

A RAM can be configured to update the HR status of the candidate based on results of an assessment, background check, or interview. If the result is captured on a form, this is an easy trigger to set up and run. For Background check, ensure that the results are not sent back repeatedly for the same candidate or req. Use the delay triggering to limit the number of times it triggers a RAM to run.

Trigger mechanism: Candidate form insert or update.

Trigger event: Background check results form, or other applicable form. For assessment, only use the KAS Overhall form and not the KAS Assessment form.

Rule 1:

1. Conditions:

   • Results form, Overall results field = Pass.

   • Req template = US salary.

   • Match form version for this req.

2. Actions: Update HR status to Passed Background Check.

Rule 2:

1. Conditions:

   • Result form, overall results field = Fail.

   • Req template = US salary.

   • Match form version for this req.

2. Actions: Update HR status to Failed Background Check.

5. Eligibility Check

A RAM can be configured to conduct a series of eligibility checks before the candidate is added to a req. If the candidate fails one of these checks, they are automatically dispositioned, resulting in an applicant pool that only consists of eligible candidates. All eligibility checks that are not req specific, must be completed on the evergreen req and non-eligible candidates should be dispositioned.

Trigger mechanism: HR status

Trigger event: Pending eligibility check status. This status is usually hidden from recruiters and hiring managers.

Rule 1:

1. Conditions:

   • Disposition form reason = Failed drug screen

   • Disposition form date greater than -365 days. This means that the date is within 365 days of today.

   • Candidate type = External

   • Match any form version across reqs.

2. Actions: Update HR status to Failed Eligibility

Rule 2:

1. Conditions:

   • Disposition form reason = Failed background check

   • Disposition form date greater than -365 days.

   • Candidate type = External

   • Match any form version across reqs.

2. Actions: Update HR status to Failed Eligibility

Rule 3:

1. Conditions:

   • Disposition form reason = Failed interview

   • Disposition form date greater than -365 days.

   • Candidate type = External

   • Match any form version across reqs.

2. Actions: Update HR status to Failed Eligibility

Rule 4:

1. Conditions:

   • Internal eligibility form = Previous poor performance

   • Candidate type = Internal

   • Match any form version across reqs.

2. Actions: Update HR status to Internal Failed Eligibility

Rule 5:

1. Conditions: None.

2. Actions: Update HR status to Passed Eligibility. This status is usually visible to recruiters and hiring managers.

6. Evergreen Pull Candidates

When using the evergreen pull candidate feature, standard reqs cannot be used and a specific evergreen req must be selected. A common evergreen pull example is where the client would like to open a hiring req, store and position specific, when a hire is needed. To get qualified candidates more quickly into the hiring req, it pulls candidates that are sitting in existing evergreen reqs. Candidates are usually matched based on location preferences and position type preferences. Those candidates that meet the criteria are pulled into the hiring req, and would be considered hire-able for the newly opened job. The identification of the candidates is done by three layers of conditions. It is recommended to also set up an archive to candidates get dispositioned after a certain time. Otherwise, the number of candidates continue to increase in the evergreen req, which might result in performance issues. This trigger is complex to set up; therefore, consult with your Infinite representative before starting any work on the trigger.

Note

RAM only pulls the first 1,000 candidates.

1. Filtering for evergreen reqs to identify the starting set of evergreen reqs to look at.

2. Matching those evergreen reqs to the hiring req based on req field value comparisons.

3. Matching values input by the candidate (on candidate form fields) to the req field values of hiring reqs.

The RAM can automate this entire process.

• Trigger mechanism: Req open

• Trigger event: Stores req template

• Trigger context: Run trigger to pull candidates.

Note

A pull-down in the upper left of the conditions tab is critical for this trigger. It has options for Standard and Evergreen. This selection allows defining whether the condition is tied to evaluating evergreen reqs or evaluating the hiring (target) req, or the req in context. This is provided since conditions are needed for both evergreen and hiring reqs. Appropriate selection is indicated in the conditions.

After the conditions are evaluated for this type of trigger, if there are more than 1000 candidates, then only the first 1000 are chosen based on Date that it is filed to the folder.

Rule 1:

1. Conditions:

   • Upper left pull-down is Evergreen: Evergreen req field is Yes.

   • Upper left pull-down is Standard: Req field Pull candidates is Yes.

   • Upper left pull-down is Evergreen: Evergreen req field Location compared to hiring req field Location.

   • Upper left pull-down is Standard: Candidate form field Position Type compared to hiring req field Position Type.

2. Actions:

   • Copy/Move.

   • Copy/Move: select as needed.

   • Retain HR status selection: select as needed.

   • HR status: select HR status candidate should go to in destination req.

   • Candidate forms to copy: select per req forms to copy into destination req.

   • No selection is necessary for req selection category, name, and field since the req that triggered the RAM is the destination req for the copy/move.

Do not use Evergreen trigger if a candidate is eligible. If the candidate failed the assessment, the candidate should not be part of the req. They should be dispositioned. Only keep in the Evergreen Req those candidates who passed the Assessment.

7. Evergreen Push Candidates

If a push trigger is needed, ensure that the reqs are closed as soon as they are filled. Otherwise, push triggers continue to file candidates to these reqs, which results in performance issues over time. A common evergreen push example is where the client would like to push candidates to open hiring reqs, store and position specific, as they apply to evergreen reqs. This has the effect of the candidate applying to one or more broader evergreen reqs, and then immediately getting copied or moved into matching hiring reqs that are open at the time the candidate applies. Candidates are usually matched based on location preferences and position type preferences. Identification of the reqs to copy or move the candidate to is evaluated by two layers of conditions.

1. Matching values input by the candidate, on candidate form fields, to req field values of any open hiring reqs.

2. Matching values on evergreen req fields to field values on any open hiring reqs

The RAM can automate this entire process.

• Trigger mechanism: HR status.

• Trigger event: Eligible for Evergreen.

• Trigger context: NA.

Note

For candidate form comparisons, left side should select the req field to compare; right side of the comparison is the candidate form field.

You can save multiple action-conditions to apply more than one filter for identifying the hiring reqs to copy/move the candidate to. The logic uses AND (same as in condition setup).

For subsequent action-conditions (more than 1), the copy/move, retain HR status data, HR status, and candidate forms to copy selections are disabled. These settings as configured in the first action-condition are used. When editing any action-condition, changing one of these settings changes it for all action-conditions within that rule.

A move to req action and an HR status update are not be allowed within the same rule.

Rule 1:

1. Conditions: Add conditions where necessary to run the trigger if the candidate meets certain criteria (that is Candidate eligible = Yes). If push happens after eligibility, then this condition is not required.

2. Actions:

   • Copy/Move

   • Copy/move: select as needed.

   • Retain HR status selection: as needed.

   • HR status: select HR status candidate should go to in destination req

   • Candidate forms to copy: select per req forms to copy into destination req

   • Req selection category, name, field, operation, and value: select appropriate filtering to identify hiring reqs

8. Interview Manager Reminder

Interview Manager Reminder

• This trigger is used to send reminders to candidates and interviewers before the scheduled interviews. The RAM is designed to run for Interviews with a status of [Interview Scheduled] where all the invitees have accepted the invites.

• Communication templates that have Interview Manager tokens must be filtered out based on Correspondence table Attribute (denoting Interview Manager) for non-Interview Manager RAMs

• If this RAM trigger is set to send a reminder for duration longer than that between interview creation date and time and the interview completion date and time, then no reminder is sent.

How to Read or Create this RAM

• Trigger Name: Suggested: [Send reminders to Candidates/Interviewers for Upcoming Interviews].

• Trigger Type: RAM Trigger.

• Triggering Mechanism: IM: Upcoming Interviews.

• Select Trigger Event: Disabled.

• Timing Mechanism: Before Interview Start, selected by default.

• Trigger Timing (hrs): 48 hrs [2 days in advance, default value, can be changed]. This field only accepts integer values with a minimum value of 1.

• Select recipients: Includes normal recipient options, for example "[Talent Record] email") and the interview options: [Interview Fields] Interviewer, [Interview Fields] Lead Coordinator and [Interview Fields] Coordination Team

9. Interview Manager Invitation Reminder

This trigger is used to send reminders to candidates and interviewers that did not respond to the interview requests. This trigger helps the interview coordinator ensure that the rescheduling or cancellation can be done in time if required. The RAM is designed to run for interviews with the statuses of Invitation Sent, Invitation Accepted - Candidate or, Invitation Declined - Interviewer.

How to Read or Create this RAM

• Trigger Name: Suggested: [Send reminders to candidates or interviewers for aging interview requests.].

• Trigger Type: RAM Trigger.

• Triggering Mechanism: Interview Manager: No response from participants.

• Select Trigger Event: [Disabled - this field is marked as None or static value like: Interview Request Pending]

• Timing Mechanism:

  • After interview request received.

  • Before interview start. [Default]

• Trigger Timing (hrs): 48 hrs [2 days in advance, default value, can be changed]. This field only accepts integer values with a minimum value of 1.

• Triggering Context:

  • Run across candidates only (with interview availability request or invitation). [Default]

  • Run across interviewers only (with interview invitation).

• Select recipients: Includes normal recipient options, for example [[Talent Record] email] and two new interview options: [[Interview Fields] Interviewer], [[Interview Fields] Lead Coordinator].

  The recipients list is filtered based on the triggering context:

  • If candidates only is selected, then interviewer is unavailable.

  • If interviewers only is selected, then, candidate [[Talent Record] email] is unavailable.