Create and Activate a RAM Trigger

Relevant eLearning

Create a RAM Trigger

See Common RAM Examples, for examples of RAMs that can be created.

1. To create a RAM trigger, in Workbench, select Tools → Automation Manager → Admin.

    

2. To add a RAM trigger, select Actions → Add new trigger.

    

3. Name the RAM trigger. Enter a name that easily identifies the purpose of the trigger.

4. Select Select trigger type → RAM Trigger.

5. A red alert message displays. Select I agree.

6. Select Save and Continue.

   

7. Select the Trigger Mechanisms by using the pull-down menu.

   

   • Trigger Mechanism can be considered as a [Category] that defines what triggers the RAM to run. RAM can be triggered to run when HR statuses are updated, or actions are performed on forms or reqs.

   • After one or more rules are created for the trigger, the Trigger Mechanism cannot be modified. To modify the trigger mechanism, all existing rules must be deleted first.

   • See Trigger Mechanisms please see in this page for more information on the Trigger Mechanisms available.

8. Select the Trigger Event by using the List icon.

   • The Trigger Event is defined by the selection of the Trigger Mechanism. The event is the specific occurrence that dictates what causes the trigger to run. After one, or more, rules are created for the trigger, the Trigger Event cannot be modified. To modify the trigger mechanism, all existing rules must be deleted.

   • Only one RAM trigger is allowed per HR status and per Form when the same combination of Delay Mechanism and Trigger Delay are not used. Different scenarios based on a single HR status, or form, must be handled within the rule.

      

9. Select the Timing Mechanisms, and Trigger Timing by using the pull-down menus.

   • The timing mechanism and trigger timing fields define how the trigger is delayed, and how long the delay is.

   • See Timing Mechanism and Trigger Timing please in this page for more information.

    

10. Select the Trigger Context.

    • The Trigger Context extends the scope of the trigger. After one or more rules are created for a trigger, the Trigger Context cannot be modified. To modify the Trigger Context, all rules must be deleted.

    • There are four Trigger Context options. For Trigger Contexts please see in this page for more information.

11. After the Trigger Mechanisms, Trigger Events, Timing Mechanisms, Trigger Timing and Trigger context have been configured, select Save.

12. Select Add Rule. Rules allow for different logic to run in each rule, producing a different set of actions and results.

13. Name the rule, and select Save & Continue.

    

    • Existing configured rules are displayed by row in the [Defined Rules] section. Configure the rule’s Condition(s) and Action(s).

    • Do not add more than 50 rules or actions to any trigger. Doing so has the potential to cause performance problems, and cause the trigger to be automatically disabled.

    • Please see in the page for more information on Conditions.

    • When creating Conditions a Category must be selected. Please see in this page for more information on Category Reference.

    • For more information on Actions, see Actions and Action Types

    • If a rule runs an [EXIT] action, such as an HR Status update, the entire trigger exits, and no additional rules run.

    • Rules are run in the sequence on the screen. Depending on the logic that is needed within the trigger, the sequencing might or might not be important. However, in most cases the order is important to produce the business logic that is wanted within the trigger. To change the order in which the rules run, use the arrows to move the rules up or down in the sequence.

14. Select Save.

    

15. After a condition is saved, it displays in the [Existing Conditions] section of the rule screen. To edit the existing condition, select Edit for the specific condition. To delete the existing condition, select Delete for the specific condition.

    

16. After an action is saved, it is added to the [Existing Actions] section. To edit the existing action, Select Edit for the specific action. To delete the existing action, select Delete.

    

17. Add Additional Rules if needed.

    • Rules are run in the sequence on the screen. Depending on the logic that is needed within the trigger, the sequencing might or might not be important. However, in most cases the order is important to produce the business logic that is wanted within the trigger. To change the order in which the rules run, select the arrows to arrange the rule sequence.

       

18. Select Save after all rules are added and sequenced.

    

19. Select Edit to edit a rule, or select Delete to delete the rule. To view a rule select the hyperlinked rule name. The RAM is available in Draft status.

Activate a RAM Trigger

• By default, RAM triggers are placed in a draft status during initial creation. This allows configuration to occur periodically before testing. RAM triggers are also placed in draft after selecting edit on an active trigger. These triggers can be activated after all changes are completed.

• 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 Infinite representative.

• Reactivated triggers are treated as if this is the first time the trigger has been made active. All trigger events that occur during the time the trigger is inactive, are not held until the trigger is active.

To activate a draft trigger,

1. Select Draft or Inactive depending on whether the trigger is in draft or an inactive state.

2. Select the trigger and select Activate trigger.

3. After it is activated, the trigger is live.

To activate multiple triggers at the same time,

1. Select Draft

2. Select Bulk activate RAM triggers.

3. In the window that opens, select the triggers to activate, and select Activate.

Edit a RAM Trigger

• When Edit Trigger is selected a notification appears. The notification recommends one of the options for the trigger that varies depending on whether the trigger uses versioning or not. Make the selection carefully as this affects how the RAM trigger functions moving forward.

  • Create new version and apply changes to new reqs:

    • Selecting this option applies the changes to reqs opened after the change was made active. This allows all candidates within a req to follow the same trigger logic. While saving the changes in the new version, a different trigger name must be specified. It is recommended to append version names such as v2 or v3 to the name. After versioning is activated, only one trigger is seen under this new name.

    • After versioning is selected on a trigger, all additional changes use versioning as well.

    • To disable versioning for a RAM trigger, select Delete previous trigger versions.

  • Make changes to existing version and apply changes across all reqs:

    • Does not create versioning for RAM triggers.

    • Selecting this option makes the change immediately, upon activation, across all reqs. The new trigger logic takes effect immediately, and a mixture of trigger logic for candidates within a req might be seen.

• After edits are finished, the trigger must be activated.

• If the trigger is in draft status, all trigger events are held until the trigger is made active again, up to 2 weeks. After the trigger is activated, the events that occurred during the time the trigger was in draft status are processed. After 2 weeks, any events during the draft period are ignored.

• Do not leave triggers for a long time in draft mode in the Production environment since all testing must be completed in staging.

1. To edit a trigger, select Tools → Automation Manager → Admin

2. select the trigger and select Edit trigger.

3. Edit the trigger as needed.

View Trigger Versions

To view the versions of a trigger, select the trigger and select View trigger details.

Inactivate a RAM Trigger

• It is recommended to inactivate triggers rather than delete triggers.

• When a trigger is inactivated, triggering events are no longer processed or held.

• Only active triggers can be moved to the inactivate status. To inactivate a trigger in draft status, the trigger must first be activated.

• If an HR status, or form, is selected for a trigger that is inactive, it is not available for selection as a trigger event.

• See RAM FAQs for more information on inactivating RAM Triggers.

To inactivate a trigger,

1. Select Tools → Automation Manager → Admin.

2. Select the trigger, and select Inactivate trigger.

Delete a RAM Trigger

• If a trigger was created in error, or is no longer needed, it can be deleted.

• It is recommended to inactivate triggers rather than deleting. This option is available only for triggers in Draft status.

1. To delete an active trigger, select Tools → Automation Manager → Admin.

2. select the trigger and select Edit trigger.

3. Select Draft.

4. Select the trigger, and select Delete trigger.

Delete Previous Trigger Versions

• This option is available for triggers in Active and Inactive statuses.

• Any new trigger events use the configuration as defined in the most recent trigger version.

• When the triggers are edited the next time, the user is presented with the option to use versioning or continue without using versioning.

• For Active triggers, no events are missed when the delete versioning is processed.

1. To Delete Previous Trigger Versions, select Tools → Automation Manager → Admin.

2. Select the trigger and select Delete previous trigger versions.

Trigger Mechanisms

Abstract

Trigger Mechanisms

Assessment Initiated

• An assessment session is initiated when:

  • The candidate selects Continue after submitting to a job on the Talent Gateway apply flow.

  • A BrassRing user selects RUN assessment from within BrassRing.

  • A BrassRing user sends a communication or email to the candidate with a link to complete an assessment.

• The trigger event field is used to select one or more req templates.

• The Aging Timing Mechanism is the only delay option available.

Candidate Form Approval

When the candidate form is approved, the trigger runs.

Candidate Form Approval Reminder

Identifies the user with whom the approval is pending and sends them an email communication after a preset delay. The candidate form approval link is added in the communication that is sent to the system user whose approval is pending.

Candidate Form Insert

When the candidate form is first created, the trigger runs.

Candidate Form Insert or Update

• When the candidate form is either first created, or updated at any time, the trigger runs.

• This option cannot be used with the individual form insert, or form update, for the same form.

Candidate Form Update

• When the candidate form is updated at any time, the trigger runs.

• Ensure that forms are not being updated too often. If multiple updates happen in a short period, use Delay Triggering to reduce the number of times the trigger runs. Example: If delay is set up to 1 day, multiple updates during the same day do not trigger multiple triggers, but only one per day.

Document Subsidiary Form Insert

When the document subsidiary form is first created, the trigger runs.

Document Subsidiary Form Insert or Update

• When the document subsidiary form is either first created, or updated at any time, the trigger runs.

• This option cannot be used with the individual form insert or form update for the same form.

Document Subsidiary Form Update

When the document subsidiary form is updated at any time, the trigger runs.

HR Status

When the candidate gets updated to the selected HR status, the trigger runs.

HR Status Req Options

• When one candidate gets updated to the HR status, the trigger runs, and allows rules to be run on the entire req folder (all candidates within the req).

• Use this Trigger Mechanism with the Trigger Context of Run trigger across candidates. This is primarily used when dispositioning all candidates in a req after a candidate is Hired.

• When using this trigger to disposition candidates, enable the client setting of RAM - Allow HR status update for closed reqs. This ensures that all candidates that meet the conditions are dispositioned.

• Any HR status can be used for this trigger mechanism, and the standard HR status trigger.

• RAM triggers that use the HR Status trigger mechanism always precede RAM triggers that use the HR Status Req Options trigger mechanism.

• To perform actions against the candidate that triggered it, use the HR Status trigger mechanism. The req that triggered this is excluded from the Rules.

Interview Manager: No response from participants.

• Added Build 20.09.08.

• 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.

Interview Manager: Upcoming Interviews.

• Added Build 20.06.01.

• Can be used to send reminders to candidates and interviewers before the scheduled interviews.

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

Interview Manager: Expiring Interviews

• Added Build 21.01.20

• This triggering mechanism can be used to send reminders to interview coordinators about the interviews that are about to expire.

• This will help interview coordinators intervene and ensure that the interview is completed without expiring.

Job Post

• Triggers off the action of Posting a job to the Talent Gateway.

• The Trigger Event field displays all active req templates. Clients can select up to 10 req templates.

• The Timing Mechanism field allows the user to select from Delayed Triggering or Aging.

• Only req based conditions and actions are available for this trigger mechanism.

• Batch posting is excluded.

Job Repost

• Triggers whenever a req, from one of the configured templates, is reposted. Reposted is defined as posting a job to a BrassRing Talent Gateway after its removal date, or reposting a job to a BrassRing Talent Gateway (that is select Repost) from the [BrassRing Req Posting Options] page.

• The [Trigger Event] field displays all active req templates. Clients can select up to 10 req templates.

• The [Timing Mechanism] field allows the user to select from Delayed Triggering or Aging.

• Only req based conditions and actions are available for this trigger mechanism.

• Batch posting is excluded.

Job Unpost

• When the job is unposted from any Talent Gateway (excluding external job boards), the trigger runs.

• This is mainly to be used with the Trigger Context of Run trigger across candidates, which runs the trigger for all candidates within the req.

• If you want to target a specific Talent Gateway, add a Condition to the Rule to determine whether the job is still posted on that Talent Gateway.

• If the T rigger Context field is set to None, then only req data is available for any Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

• When Trigger Delay is used, it is applied before unposting the job. A 24-hour delay runs the trigger 24-hours before the unpost happens.

Lead Campaign Status

Updated Build 19.06.03. When a Lead is updated to a Status in a campaign, the trigger runs.

Lead Creation

Updated Build 19.06.03. When a new Lead is created, the trigger runs.

Req Approved

• When a req is moved to the Approved status (meaning the final approver approves the req), the trigger runs.

• This is used to populate other req fields or send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Canceled

• When a req is moved to a Canceled status, the trigger runs.

• This is used to send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Closed

• Functions are limited for what you can do with reqs and candidates when the req is in a closed status.

• When a req is moved to a Closed status, the trigger runs.

• This is used to send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Create

• When a req is created and saved for the first time, the trigger runs.

• This is used to populate other req fields, or to send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Declined

• When a req is declined (meaning an approver declines approval and the req moves to a Declined status), the trigger runs.

• This is used to populate other req fields, or to send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Deleted

• When a req is moved to the Deleted status, the trigger runs.

• This is used to send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Edit

• When a req is edited at any time, the trigger runs.

• Req status updates are not considered an edit.

• This trigger mechanism should be used with the condition field changes. Only changes made manually by users in BrassRing are considered.

• Updates that are completed through integration are ignored. If integrations are set up to update requisitions regularly, this trigger mechanism should not be used.

• This is used to populate other req fields, or send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Form Approval Reminders.

• Added Build 20.01.13.

• Identifies the user with whom the approval is pending and sends them an email communication after a preset delay.

• A req form approval link is added in the communication that is sent to the system user whose approval is pending.

Req On Hold

• When a req is moved to an On Hold status, the trigger runs.

• This is used to send a communication.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Open

• When a req is moved to an Open status, the trigger runs.

• This is used to send a communication, or used in req disbursement pull scenarios.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• Do not select the Trigger Context field to Run trigger across candidates as there aren’t any candidates when the trigger mechanism is req create, open, or approved.

Req Pending

When a req is moved to a Pending status, the trigger runs.

Req Subsidiary Form Approval

• When a req sub form is approved, the trigger runs.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Subsidiary Form Insert

• When a req sub form is first created, the trigger runs.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Subsidiary Form Insert or Update

• When a req sub form is either first created OR updated at any time, the trigger runs.

• This option cannot be used with the individual form insert or form update for the same form.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Req Subsidiary Form Update

• This trigger runs when a req sub form is updated at any time.

• If the Trigger Context field is set to None, then only req data is available for Conditions and Actions within the trigger.

• If the Trigger Context field is set to Run trigger across candidates, then all Condition and Action categories are available.

Talent Record Viewed

Triggers each time a candidate’s BrassRing Talent Record is viewed from within a req folder.

• Trigger Event field displays all the active req templates. Workbench Admins can select multiple req templates.

• The req must be in an Open or On hold status for the trigger to fire. This is an implicit check that is performed by RAM, and does not require a condition to be built into the trigger.

• The timing Mechanisms that are supported by this trigger are Delayed Triggering, and Aging.

Timing Mechanisms, and Trigger Timing

Abstract

Timing Mechanisms, and Trigger Timing

Delayed Processing

When the trigger event occurs, for example, a candidate’s HR Status is updated, if Delayed Processing has been selected, the RAM trigger fires but is then put on hold from processing the trigger for the specified duration. After the delay has elapsed, the trigger runs. Then, the conditions are evaluated and actions are performed if the conditions are met. Only use Delayed Processing if there is no delay or if the delay is less than one hour. If the delay is greater than or equal to 1 hour, use Aging or Delayed Triggering.

Trigger event occurs > trigger fires (looks at the mechanism and event) > delay elapses > trigger is executed - rules are run (without looking at the mechanism and event again)

Delayed Processing triggers that have been fired cannot be stopped even if the trigger is inactivated or if the HR Status was updated by mistake and undone, the trigger still fires and runs after the delay.

• The conditions are evaluated and the actions are taken when the trigger is run so after the delay has occurred.

• Trigger timing (hours) value:

  • Is the number of hours the trigger processing is delayed.

  • Decimal places are allowed. For example, to delay the trigger for 15 minutes, the value 0.25 should be entered.

  • Maximum value that is allowed is 4560 (190 days).

Delayed Triggering

If Delayed Triggering is selected, the RAM trigger looks if the event happened 72 hours ago, fires, and process the trigger for this event at the same time. The trigger triggers and runs 72 hours after the HR Status was updated regardless of the current HR Status. If the HR Status was updated by mistake and undone, the trigger does not fire. This trigger with triggering delay should be used when a candidate has reached a certain HR Status, for example sending a survey 1 year after candidate has accepted an offer.

Trigger event occurs > delay elapses > trigger fires (looks at mechanism and event) and is executed - rules are run.

This trigger triggers after 72 hours for every candidate that has been updated to the HR Status even though the candidate is still in that HR Status.

• Trigger timing (hours) value:

  • Is the number of hours the trigger is delayed.

  • Accepts only whole numeric values. Decimals are not accepted and the minimum delay is 1 hour.

Aging

If Aging is selected, the RAM trigger triggers and runs if the candidate has been in the HR Status for 72 hours. If HR Status was updated to another HR Status, the trigger does not fire. The timing mechanism of Aging is typically used for all reminder triggers, for example if candidate is still in pending assessment after 3 days, then a reminder notification is sent, or to detect whether a candidate is stuck in a specific HR Status. Since there is no delay between triggering and processing, there is no need to check the current HR Status as it is the HR Status that is used for trigger Mechanism.

This trigger only triggers for candidates that have been updated to the HR Status and are still in that HR Status for the delay. Only candidates that are in pending assessment for 3 days trigger such trigger.

Trigger event occurs > delay elapses without other event > trigger fires (looks at mechanism and event) and is executed - rules are run.

The trigger does not trigger if the candidate took the assessment during the 3 days and was updated to a different HR Status. For example, assessment passed or assessment failed.

• Trigger timing (hours) value:

  • Is the number of hours the candidate has been in the Trigger Mechanism HR Status.

  • Accepts only whole numeric values. Decimals are not accepted meaning that the minimum delay with Delayed Trigger is 1 hour.

• Any reminders triggers should use such delay.

• It’s recommended to use Aging when to trigger actions based on a Requisition or HR Status has not changed for the time of the delay.

• If a Req Status or HR Status has been the same status for 72 hours, the trigger fires and runs.

• This timing mechanism is comparable to the old Candidate HR Status Aging and Req Aging Automation Manager triggers.

Delayed Processing (Field Value)

When the trigger event occurs (for example, a candidate’s HR Status is updated), if Delayed Processing (Field Value) is selected, the RAM trigger fires but is then put on hold for the specified duration. After the delay elapses (defined by the Delay Field that is selected in the trigger), the trigger runs. Then, the conditions are evaluated, and actions occur if the conditions are met.

• Delay Field Value:

  • Choose to delay the trigger based on a Candidate form field, a Req form field, or a Req sub form field.

  • Only Numeric, or Single-Select, field types can be used.

  • Field types that are not selectable: Query-select, radio, check box, text, text area, multi select, date, email address, label, SSN, and autofill).

     

• Delayed Processing (Field Value) functions the same as the Delayed Processing type. That is the RAM trigger is fired and is processed after the delay elapses.

• This timing mechanism allows the client’s users to define the delay period. For example, if the client would like their BrassRing users to define how long they would like to delay a disposition email, they can select it from a single-select, or numeric field on the disposition candidate form.

Timing Mechanism available for each Triggering Mechanism

• Assessment Initiated - Aging

• Candidate Form Insert - Delayed Processing, Delayed Triggering

• Candidate Form Approval - Delayed Processing

• Candidate Form Update - Delayed Processing, Delayed Triggering

• Candidate Form Insert or Update - Delayed Processing, Delayed Triggering

• Document Subsidiary Form Insert - Delayed Processing

• Document Subsidiary Form Update - Delayed Processing

• Document Subsidiary Form Insert or Update - Delayed Processing

• HR Status - Delayed Processing, Delayed Triggering, Aging, Delayed Processing (Field Value)

• HR Status Req Options - Delayed Processing, Delayed Triggering, Aging, Delayed Processing (Field Value)

• Job Post - Delayed Triggering, Aging

• Job Repost - Delayed Triggering, Aging

• Job Unpost - Delayed Processing

• Req Create - Delayed Processing

• Req Approved - Delayed Processing, Delayed Triggering, Aging

• Req Open - Delayed Processing, Delayed Triggering, Aging

• Req Edit - Delayed Processing

• Req On Hold - Delayed Processing, Delayed Triggering, Aging

• Req Declined - Delayed Processing, Delayed Triggering, Aging

• Req Closed - Delayed Processing, Delayed Triggering, Aging

• Req Deleted - Delayed Processing, Delayed Triggering, Aging

• Req Canceled - Delayed Processing, Delayed Triggering, Aging

• Req Pending - Delayed Processing, Aging

• Req Subsidiary Form Approval - Delayed Processing

• Req Subsidiary Form Insert - Delayed Processing, Delayed Triggering

• Req Subsidiary Form Insert or Update - Delayed Processing, Delayed Triggering

• Req Subsidiary Form Update - Delayed Processing, Delayed Triggering

• Talent Record Viewed - Delayed Triggering, Aging

Trigger Context

Abstract

None/NA

• This option means that a Trigger Context is either not available for the Trigger Mechanism used, or the scope of the trigger does not need to be expanded beyond the simple trigger mechanism that occurred.

• For example, if Req Edit is selected as the Trigger Mechanism, and the goal is to send a communication to the Manager on the req, then no additional Trigger Context is needed, since the conditions and actions only need req data. No candidate actions are needed.

Run Trigger Across Reqs

• This option is available to handle circumstances when a single per candidate or multiple per candidate form is selected as the Trigger Event. When these types of forms are selected, a req is not in context. Therefore, req related conditions, and actions, cannot be used.

• In the case where req data is still needed to get the req context, this setting runs the trigger across all reqs that the candidate is filed to. This might result in multiple actions occurring and produce undesirable results.

• For example, when you configure an action to send communication when a single/candidate form is created, and this setting is used, a communication is sent out for each req the candidate is in. If the candidate is in three reqs, then three communications are sent.

• In most cases, this setting should not be used. Furthermore, this setting is disabled if the Trigger Event is not a single per candidate or multiple per candidate form. If you use this context, make sure to set up a limit on the number of times a candidate can apply to reqs.

   

Run Trigger Across Candidates

• This option is available to handle triggers where the trigger should be run across all candidates within the req. A common example is the dispositioning of all candidates in a req that haven’t been dispositioned after a candidate is hired. It is used with the Trigger Mechanism of HR Status Req Options, Job Unpost, Req Create, Req Edit, and Req Subsidiary Form Approval/Insert/Update. For evergreen reqs, ensure that the trigger does not run on these reqs to avoid any negative impact on the system.

   

Run Trigger to Pull Candidates

• This option is available only for the Trigger Mechanism of Req Open, and is strictly used in Evergreen req scenarios to pull candidates from Evergreen reqs.

• RAM pulls the first 1000 candidates found. These types of triggers should only be set up by Infinite representative.

   

Conditions

Abstract

Conditions

A rule is composed of conditions and actions. Conditions evaluate data in the system to produce a true or false result. Actions perform automated tasks in the system when those conditions are true.

When more than one condition exists in a rule, the conditions are bound together by using AND logic. For example, condition 1 has field X equal to Yes. Condition 2 has field Y equal to Yes. In order for the overall rule conditions to be true, and an action to occur, field X, and field Y both need to be Yes. OR statements are added by creating another rule with a different set of conditions, or by using the Link to existing rule condition where branching of rules can occur.

Multiple existing conditions that are using different fields on the same form are grouped, and thus evaluated together for multiple form instances.

Category

To create a new condition, select a Category.

• The category selection further refines the selections to specify the condition.

• The list of categories that are available might change depending on the Trigger Mechanism and Trigger Context that is selected for the trigger.

• In cases where there is no candidate in context, all candidate conditions are hidden. In cases where there is no req in context, all req conditions are hidden.

• For more information on the available categories and typical uses, see the Category Reference in this page.

Name

If applicable, the Name selection is presented when the category is selected. For more information on names available for categories, see the Category Reference in this page..

Field

If applicable, the Field selection is presented when the Name is selected. For more information on the fields available for categories, see the Category Reference in this page..

Operation

The Operation selection is presented when the Field is selected. Operations determine how to evaluate the field or category that is selected. The available operations depend on the field type selected. The following lists the operations based on field type.

• Single select, Multi select, Query select, Radio button, Checkbox fields

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

• Date

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Is Blank

  • Is Not Blank

  • Greater Than (# days)

    • Using this operation takes the Define Value for this condition and adds it to today’s date, producing Date X. The date field selected (say Date Y) here is then compared to Date X. If Date Y is greater than Date X, then this condition is true.

    • Negative values can be input into the Define Value box.

    • Within scenario – use Greater Than (# days) with negative value.

  • Less Than (# days)

    • Using this operation takes the Define Value for this condition and adds it to today’s date, producing Date X. The date field selected (say Date Y) here is then compared to Date X. If Date Y is less than Date X, then this condition is true.

    • Negative values can be input into the Define Value box.

    • Not Within scenario – use Less Than (# days) with negative value.

    • If date on the form is considered as an actual expiration date – use Less Than (# days) with 0.

• Numeric

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Is Blank

  • Is Not Blank

• Text

  • Contains

  • Not Contains

  • Is Blank

  • Is Not Blank

  • Equals

  • Not Equals

Select Values.

When the field or category that is selected has a finite list of options to choose from, for example a single select list, then the Select value(s) option is available. This allows selection of the specific value to evaluate. It is evaluated based on the operation selected.

Compare Value

When the field or category that is selected is available to be compared, then the Compare value option is shown. This selection compares this field to another field. A second field must be selected to be used in the comparison. The comparison logic uses the Operation that is defined.

• Date and Numeric field types can only be compared to fields of the same type. All other field types can be interchanged for comparisons.

• If comparing a text field with an options list (that is Single-select), then the comparison uses the Code of the options list to compare. It does not compare the Description.

• Multi-selects are always treated as an OR scenario when performing the comparison logic. For example, if a text field is selected, and the comparison is to a multi-select field with two options (Option A and Option B) selected, then the condition evaluates whether the text matches either Option A OR Option B.

• Example: an internal candidate selects a question about their current division. A comparison can be used to determine whether the answer matches the req division field

Define Value

When the field does not have a finite list of options to choose from (a text field) the Define value option is available. Text that is entered into this text box is evaluated based on the Operation defined.

For example, the assessment form banding field is of type text. It is selected with an operation of “Contains”. The Define value text entered here is “Pass”. When this condition runs, it looks up the band field to see whether the value has the text “Pass” in it.

Use a semi-colon to separate multiple contains statements within the same condition.

Multiple Form Instances

When you select a multiple per candidate, multiple per candidate per req, or multiple per req form (req sub form), you must specify which form version to use, since more than one might be on file for the candidate or req. In addition, you can add logic for the form to apply the condition scenario across reqs for candidate forms. The following options are available for each form type.

• Single per candidate

  • Not applicable

• Multiple per candidate.

  • Match most recent version.

  • Match any form version.

  • Match all form versions.

• Single per candidate per req.

  • Match form version for this req.

  • Match most recent version across reqs.

  • Match any form version across reqs.

  • Match all form versions across reqs.

• Multiple per candidate per req.

  • Match most recent version for this req.

  • Match any form version for this req.

  • Match all form versions for this req.

  • Match most recent version across reqs.

  • Match any form version across reqs.

  • Match all form versions across reqs.

• Multiple per req (Req subsidiary form)

  • Match most recent version.

  • Match any form version.

  • Match all form versions.

Category Reference

Abstrac

Category: Candidate Filing

• Name: N/A

• Field: Available Options:

  • Date when filed to current req.

  • Date when filed to first req.

  • Date when filed to most recent req.

  • User who filed to current req.

  • User who filed to first req.

• Available Operations for ‘Date’ options:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Less Than (# days)

  • Greater Than (# days)

  • Is Blank

  • Is Not Blank

• Available Operations for ‘User’ options:

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

• Value: User can Define a value (date format: MM/DD/YYYY) or use Compare value.

Category: Candidate Forms

• Name: Includes a list of candidate forms.

• Field: Includes a list of fields on the candidate form that is selected.

• Available Operations for Single-select, Multi-select, Check box, Radio button fields:

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Date fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Less Than (# days)

  • Greater Than (# days)

  • Is Blank

  • Is Not Blank

  Available Operations for email fields:

  • Contains

  • Not Contains

  • Is Blank

  • Is Not Blank

  Available Operations for Text, Text Area fields:

  • Contains

  • Not Contains

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Numeric fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Is Blank

  • Is Not Blank

  Operations available for Autofill fields depend on the field type that is being used in the autofill.

  SSN and Label field types are not selectable in the Candidate form category.

• Value: Value section depends on the type of field selected. (Select value(s), Compare value, Define value)

• Notes: Allows the rule to evaluate information that is entered in candidate form fields.

Category: Candidate proximity

• Name: N/A

• Field: N/A

• Operation:

  • Within

  • Not Within

• Value: User can Define distance in Miles or Kilometers. (Example: Within 50 miles, then perform an action.).

• Notes:

  • Evaluates the candidate’s proximity to the req.

  • Compares the candidate’s Zip or Postal Code or City (on their Talent Record) with the proximity that is defined on the req (Zip or Postal Code or City).

Category: Candidate tier visible

• Name: N/A

• Field: N/A

• Operation: N/A

• Value: selecting Select value(s) presents two options Yes and No. (Example: Yes, the candidate is in a tier visible for a req, or No, the candidate is not in a tier visible for a req.).

• Note: This condition category is hidden when the trigger does not have req context.

Category: Count # Candidates in HR status for this req

• Name: HR Statuses that are listed for selection (Multiple HR Statuses can be selected).

• Field: Available Options

• Operation:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

• Value: Use the ‘Define value’ or use the ‘Compare value’ option.

• Notes:

  • Gives a count of the number of candidates at the specified HR status at the time the trigger runs.

  • Uses the req that is in context for this event.

  • For example, if this req has fewer than 10 candidates at this status, then perform an action.

Category: Count # active reqs candidate is in

• Name: N/A

• Field: N/A

• Operation:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

• Value: User can ‘Define value’ or use the ‘Compare value’ option.

• Notes:

  • Counts the number of reqs the candidate is in.

  • Does not include final statuses.

Category: Document subsidiary form fields

• Name: Includes a list of doc sub forms.

• Field: Includes a list of fields on the doc sub form that is selected.

• Operation:

  Available Operations for Single-select, Multi-select, Check box, Radio button fields:

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Date fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Less Than (# days)

  • Greater Than (# days)

  • Is Blank

  • Is Not Blank

  Available Operations for email fields:

  • Contains

  • Not Contains

  • Is Blank

  • Is Not Blank

  Available Operations for Text, Text Area fields:

  • Contains

  • Not Contains

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Numeric fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Is Blank

  • Is Not Blank

  Operations available for Autofill fields depend on the field type that is being used in the autofill.

  SSN and Label field types are not selectable in the Candidate form category.

• Value: Value section depends on the type of field selected. (Select value(s), Compare value, Define value)

• Notes:

  • Allows the rule to evaluate information that is entered in document subsidiary (doc sub) form fields.

Category: Form existence

• Name: Includes a list of candidate forms.

• Field: N/A

• Operation:

  • Is True

  • Is Not True

• Value: N/A

• Notes:

  • Evaluates whether a candidate form exists or does not exist on the candidate’s Talent Record.

  • If the form selected is a single per candidate per req form, then the req in context is used to determine whether this form exists for this req.

Category: HR Status

• Name: N/A

• Field: N/A

• Operation: N/A

• Value: User is allowed to select one or more HR statuses to include in the condition.

• Notes:

  • This can be used to determine whether the candidate is presently at that status when the trigger runs. Example: Candidate is in the “Applied” status.

Category: Lead Manager fields Updated Build 19.06.03.

• Campaign Fields

• Lead Campaign Fields.

• Lead Fields.

Category: Link to previous rules

• Name: Lists other rules within the same trigger that precedes the rule being created or edited.

• Field: N/A

• Operation:

  • Is True

  • Is Not True

• Value: N/A

• Notes:

  • You can only link to a previous rule for true or false.

  • If you reorder the rules, you need to make sure that conditions are changed.

  • Allows linking this rule to previous rule.

  • Used in rule branching scenarios. Example: rule 2 only runs when rule 1 conditions are true.

Category: Positions Filled

Name: N/A

• Field: N/A

• Operation: N/A

• Value: N/A

• Notes:

  • This is only available when the trigger mechanism is HR Status Req Options.

  • When this condition is used, it determines whether the positions for the req are filled (# remaining positions = 0) when the candidate in context gets to the selected HR status. The condition accounts for the candidate in context.

Category: Req form fields

• Name: Includes a list of all active req forms

• Field: Includes a list of fields on the req form that is selected.

• Operation:

  Available Operations for Single-select, Multi-select, Check box, Radio button fields:

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Date fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Less Than (# days)

  • Greater Than (# days)

  • Is Blank

  • Is Not Blank

  Available Operations for email fields:

  • Contains

  • Not Contains

  • Is Blank

  • Is Not Blank

  Available Operations for Text, Text Area fields:

  • Contains

  • Not Contains

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Numeric fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Is Blank

  • Is Not Blank

  Operations available for Autofill fields depend on the field type that is being used in the autofill.

  Label field types are not selectable in the Candidate form category.

• Value: Value section depends on the type of field selected. (Select value(s), Compare value, Define value)

Category: Req form fields modified

• Name: N/A

• Field: N/A

• Operation: Has Changed

• Value: Includes a list of req fields.

• Notes:

  • This category allows the selection of req fields to identify whether those fields changed.

  • Typically used with the trigger mechanism of Req Edit.

  • Available on other triggering mechanisms but with a restricted list of req fields.

  • When using the Send Communication action with this category, the check box (on the Send Communication action page), Include old and new values for req form fields modified, are available.

Category: Req status

• Name: N/A

• Field: N/A

• Operation:

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

• Value: Includes a list of all req statuses except Pending and Deleted.

• Notes:

  • This selection does not trigger the RAM to run. It only evaluates the req status based on some other event that has been triggered.

  • This category is only available when the trigger has a req in context.

Category: Req subsidiary Form

• Name: Includes a list of all active req subsidiary forms

• Field: Includes a list of fields on the req subsidiary form that is selected.

• Operation:

  Available Operations for Single-select, Multi-select, Check box, Radio button fields:

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Date fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Less Than (# days)

  • Greater Than (# days)

  • Is Blank

  • Is Not Blank

  Available Operations for email fields:

  • Contains

  • Not Contains

  • Is Blank

  • Is Not Blank

  Available Operations for Text, Text Area fields:

  • Contains

  • Not Contains

  • Equals

  • Not Equals

  • Is Blank

  • Is Not Blank

  Available Operations for Numeric fields:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Is Blank

  • Is Not Blank

  Operations available for Autofill fields depend on the field type that is being used in the autofill.

  Label field types are not selectable in the Candidate form category.

• Value: Value section depends on the type of field selected. (Select value(s), Compare value, Define value)

Category: Req templates

• Name: N/A

• Field: N/A

• Operation: N/A

• Value: Includes a list of all req templates/forms.

Category: Talent Gateways

• Name: Includes a list of all Global Talent Gateways and Talent Gateways.

• Field:

  • Currently Posted

  • Posted Date

  • Removal Date

• Operation:

  Available Operations for “Currently Posted”:

  • Is True

  • Is Not True

  Available Operations for “Posted Date” and “Removal Date”:

  • Equals

  • Not Equals

  • Greater Than

  • Less Than

  • Less Than (# days)

  • Greater Than (# days)

  • Is Blank

  • Is Not Blank

• Value: No Value available when selecting Currently Posted. Selecting Posted Date or Removal Date allows the user to Define value, or Compare value.

• Notes: If selected, the system evaluates data that is associated with req postings. For example, job is not posted.

Category: Talent Record

• Name: N/A

• Field:

  Includes the fields from the Applicant Master (fields that are found on the candidate profile):

  • Address 1

  • Address 2

  • Candidate Added On

  • Candidate ref num

  • Candidate Stacking Field

  • Candidate type current type

  • Candidate type previous

  • City

  • Country

  • Date last loaded

  • Degree

  • Email

  • Educational institute

  • Employer

  • Fax number

  • Field of study

  • First name

  • First name pronunciation key

  • Location

  • Middle name

  • Other phone

  • Position held

  • Work phone

  • Years Experience

  • Zip or Postal code

• Operation: Option section depends on the type of field selected.

• Value: Value section depends on the type of field selected. (Select value(s), Compare value, Define value)

RAM Trigger - Enhanced View Details Page

Workbench Power Users now have the option to view RAM Trigger details in an enhanced view.  This advanced view aids in the ability for users to navigate RAMs that may have multiple Rules by collapsing the Rules, reducing potential rendering issues. The collapsed sections show the number of conditions and actions in each Rule. There is also a search at the top, allowing users to search for specific conditions, actions, or elements of a Rule easily in the user interface. Collapsed sections are also easily expandable, giving users a full view of the configuration of the Rule.

To access the Enhanced view:

• Workbench > Tools > Automation Manager > Admin

• Select a RAM Trigger

• Select Enhanced view trigger details

   

   

• Rules are automatically collapsed by default.

• The number of conditions and actions are displayed.

• Edits to the RAM cannot be made through this page.

• NOTE: The classic view details page is still available (through the View trigger details icon) as we allow users to experience this new view.

   

• Rules can be expanded or collapsed by using the carets icon.

• Conditions will be displayed on the left side of the window while Actions can be viewed on the right.

   

Searching in the Enhanced View Details Page

1. Workbench users can use the Search option to search for elements within the RAM (names of rules/conditions/actions, form and form field names, communication template names, HR Statuses, etc).

2. While typing, the search will display elements of the RAM that match your entry.

   

    

   

3. After selecting the item from the search list, the Rule list below is filtered down to display only that Rule. Use the Caret to expand the Rule.

   Note

   No highlighting is shown, however, the Rule list is filtered to display only the Rule that includes the value the user searched for.

    

4. To navigate back to the full list of Rules, select the “x” icon next to the search field.

    

Viewing RAM Triggers with Versions

1. If there are versions of a Trigger, users see an icon at the top next to the name of the trigger.

    

2. Selecting the icon displays the version selection window. Users can select a version of the RAM trigger by selecting the version link. The same view and search functionality is present on past versions of the RAM.

   

   Note

   Currently being worked on:

   • Form Multiples selected in the RAM trigger rules are not currently viewable in the Enhanced RAM view. This is being worked on (RTC 305207) and the projected release date is January 2022.