RAM User Guide

Summary

RAM uses automation to solve many business problems. It is important to take caution when creating, editing, and activating RAM triggers. Power Users can create RAM triggers in both Staging and Production environments, but can only activate them in Staging. To activate a Production RAM trigger, contact your IBM representative. It is recommended to test RAM triggers in the Staging environment before creating and activating a RAM in the Production environment.

Relevant eLearning

RAM Terms

• Action: An action can be defined to occur in the system when the conditions are found to be true.
• Activate: To enable or turn on your RAM trigger.
• Candidate in context: Meaning, the candidate that is associated with the trigger. For example, an HR status is updated for a candidate within a req. The candidate that this occurred for is referred to as the candidate in context.
• Condition: Conditions evaluate data in the system to produce a true or false result.
• Draft: RAM triggers are placed in a draft status or mode each time they are created or edited.
• Inactivate: To disable or turn-off your RAM trigger.
• Req in context: The req that is associated with the trigger. For example, an HR status is updated for a candidate within a req. The req where this occurs, is referred to as the req in context. Similarly, if a per req candidate form is added or updated for a candidate within a req the req where this occurs is referred to as the req in context.
• Rule: Rules are made of conditions and actions. The intention of creating rules is to allow for different logic to run in each rule, producing a different set of actions/results. Multiple rules can be configured per trigger.
• Trigger Event: Defined by the Trigger Mechanism; the event is the specific occurrence that dictates what causes the trigger to run. Examples: Candidate Not Interested and Offer Form.
• Trigger Mechanism: Category that allows the Workbench user to define what triggers the RAM to run. For examples, HR Status, and Candidate Form Insert.
• Trigger Timing: Define how the trigger is delayed and how long the delay occurs for.
• Version: Versioning is the process that assigns version numbers to a RAM trigger that has been edited. If a new version is created, the changes apply to reqs opened after the change was made active. Versioning allows all candidates, within a req, to follow the same trigger logic.

Notes and Best Practices

Trigger Frequency

RAM triggers run every minute. However, this is largely based on load at the time. Results vary. Large number of triggers decrease the frequency of triggers run.

HR Status Action Selections

Any HR status can be selected for actions. If selecting an HR status that does not follow the Closed tracking logic, then the action fails and the candidate is not updated. Closed tracking logic can also be disobeyed in the RAM by enabling the client setting RAM Disobey Closed Tracking Logic. When enabled, this allows the candidate to be updated to the HR status, even when the HR status is outside of the Closed tracking logic setup.

Req Edit and Req Form Fields Modified

Configure a trigger delay of at least 30 minutes when using the trigger for Req Edit followed by rules with conditions evaluating Req Form Fields Modified. This allows enough time for the data to be processed to evaluate both the old and the new values.

Req and Candidate Context

The list of conditions and actions available is based on the trigger mechanism, trigger event, and trigger context. Sometimes, req or candidate information cannot be used since the configured items do not have req or candidate context. As an example, the Talent-Gateway form is a multiple per candidate form not tied to a req. When using this form as the trigger, req conditions and actions are not allowed since the req is not in context. In addition, actions such as updating an HR status are not allowed, since the HR status update occurs within a req. The trigger context attribute can be used to bypass this, but it might produce undesired results. If using the Req Form Fields as a condition, it is important to also create a second condition to check the req template. This ensures that the field and operation combination is evaluated correctly even when the trigger is run in the context of another req template. Ensure that the field exists before checking that its value is different from another value when using not equals on an optional req field.

Sample Structure:

• Rule 1
  • Condition for req template = A.
  • Condition for req form fields: Req template A: field X != Test.
  • Action to send communication.
• Rule 2
  • Condition for req template = B.
  • Condition for req form fields: req template B: field X != Test.
  • Action to send communication.

Using RAM to Trigger Candidate Export Integrations

RAM can be used to trigger candidate export integrations. For example, New hires to HRIS, background checks, and Onboard. The client setting of RAM – Allow HR status update to trigger candidate export integrations must be enabled. When enabled, any HR status update by the RAM causes candidate exports that are defined for that same HR status to run. This setting is enabled for any new clients.

This limits error handling, since the user is not involved in updating the HR status, and does not receive a success or failure message, there is only one way to report errors. Within the candidate export subscription, a static email address can be provided. All errors are sent to that email address. In addition, the emails might require a subsequent help desk ticket to determine which req and candidate the error is for, since the email only contains a transaction ID.

Alternatively, BrassRing users can access candidate export errors by selecting Menu > Admin > Admin+ > Candidate exports.

User Guide Topics: