Skip to main content
Manager ApplicationRobots

Robot Filtering

By April 22, 2020April 21st, 2021No Comments



Robot Filtering

How to set Robot Filtering Criteria

The Robot Filter Criteria identifies the records each Robot will action. This is very important because if you don’t filter enough, you could flood the user’s Playbooks with more records than they could possibly manage and overwhelm your CRM with API Calls.

Types of Filter Criteria

Each of these criteria must be designated before you assign the action to the Robot. The criteria should be as specific as possible to prevent overwhelming your CRM with API calls.

  1. Record Type – Defines the CRM object and which user in Playbooks will be impacted. What you select here determines which fields are available below. Account, Contact, Lead, and Opportunity objects are available by default. The Case object and Custom objects can be enabled with the help of your XANT Technical Consultant.
  2. Owned By – Specifies who is impacted by this Robot. This filter can be set to Teams, Queue, or Anyone. Only pertinent Teams or users should be assigned to a Robot to prevent unnecessary API usage.
  3. If a person meets this criteria… (Additional Filtering) – Use additional CRM fields, call dispositions, or email tracking data to narrow down the applicable records. Several examples are listed below in this article. Cross object filtering is a supported form of filtering but is not covered in this article. Before attempting any Cross Object Filtering, read the Robots Cross Object Filtering article and consult with your XANT Technical Consultant.

Using Date and Time Fields in Filtering

If a Robot’s function is dependent on the timeliness of a Robot, then the Robot administrator needs to understand how the Robot engine translates Date & Time fields from the CRM.

  • CRM Date & Time fields – The time is based on the CRM Company time zone
  • CRM Date Only fields – Time is appended to the date as midnight UTC time

To compensate for time zones, Robot filter criteria can be specified in percentages of a day written in decimals. For example: Last online interaction was in the last 1.25 days. However, the smallest interval allowed is .1 which is 2.4 hours.

Here is a scenario to illustrate how to offset a Date Only field where time is recorded in UTC time:

A Play and Robot strategy has been designed to move records from Play to Play based on the age of the “Last Interaction Date” field, which is a date only field. The Sales team assigned to this Play and Robot are located in the Central time zone of the United States which is -6 hours after UTC time.

First is the “Hot” Play with an aggressive cadence that lasts 48 hours after an online interaction happens. Then, a Robot moves the record into the “Cool” Play with a less aggressive cadence for the following 48 hours.

The “Cool” Robot’s filter criteria identifies the CRM field “Last Interaction Date” is at most 3.25 days in the past. If the Robot did not include .25 days, the records would be pulled into the “Cool” Play 6 hours too soon and doesn’t adhere to the team’s 48-hour response strategy.

Use the table below to evaluate how much your Robot should be offset by. The time zone offset only needs to be considered for short intervals.













































Note: Time zone offsets don’t automatically adjust for Daylight Savings Time (DST). Managers and Admins need to manually adjust these offsets in Robots to account for DST in Spring and Fall annually.

Summary of Filter Criteria

Criteria Type Criteria Details
CRM Field Value
  • Identify field and value
  • Dates evaluated in UTC time
  • Commas are not supported. Picklist and checkbox fields are preferable to open text fields
  • Not recommended to use ID, phone, address, and description fields
  • Null Date Values are supported but all other Null Values are not supported
Call Dispositioned
  • Identify call result(s). Multiple options can be selected
  • Operators: Equals or Not equals · Robot is evaluated when call log is saved. It does not wait for the usual query runtime cycle.
  • Robot is evaluated every time a call disposition matches the criteria even if the other Robot criteria does not match. This can cause an increase in API calls.
  • Only evaluates the record being dialed
Email Opened
  • Only available for O365 and Gmail
  • Evaluates all emails opened by the Playbooks record, not individual emails (Example: you can’t specify certain templates that are opened.)
  • Set number of occurrences before trigger
Email Link Clicked
  • Only available for O365 and Gmail
  • Evaluates all links clicked by the Playbooks record, not individual emails (Example: you can’t specify certain links that are clicked.)
  • Set number of occurrences before trigger
Email Bounced
  • Only available for O365 and Gmail
  • True or False
Email Response
  • Only available for O365 and Gmail
  • Evaluates all emails responses by the Playbooks record, not individual emails (Example: you can’t specify certain templates that are responded to.)
  • Set number of occurrences before trigger

Things to Consider

Filter Criteria are the most important pieces of the Robot since they target the records the Robot will impact. Keep these details in mind while establishing your Filter Criteria.

  • Robots can contain up to eight different Filter Criteria, but not all criteria can be combined. For instance, you cannot mix Call Disposition and Email Tacking filters in the same Robot.
  • Query results must meet all filter criteria built into the Robot. Multiple values can be listed in one filter, but they must be separated by a comma. If the filter criteria contains a comma in the text, put it in quotes around the text to prevent confusion. Up until the July 7, 2020 release, queries could only use the AND operator.
  • Most Robot queries run every 10 minutes. This means the record won’t be impacted by the Robot action until the next 10-minute query is run. The runtime for Robots is set at 10 minutes by default. If you would like to change the time between queries, contact your CSM and request they change your Robot’s runtime interval.
  • There are two criteria exceptions that break the query runtime rule. Call Disposition and Email Tracking will trigger a Robot to run immediately.
  • When you set the criteria filters, operators are only selectable from a fixed set of options. Options for selectable operators include:
    • Text – equals or not equals
    • Number – equals, not equals, greater than, greater than or equal to, less than, or less than equal to
    • Date – equals, not equals, after, on or after, before, on or before
    • Checkbox – on or off

Frequently Asked Questions

Q: Does the action “Add to Play” only fire if the record is already in Playbooks?
A: No. This action will add the qualifying record to Playbooks (if applicable) as well as enroll them in the specified Play.

Q: How frequently will Robots be evaluated?
A: CRM Field-based Robots are powered by a service that runs queries against your CRM data every 10 minutes as default. Query runtime may be changed to run at a different interval by reaching out to your CSM. Call Disposition and Email Tracking data filters cause Robots to run immediately.

Q: What if a record qualifies for multiple Robots at the same time?
A: The Robot with the higher priority will action the qualifying record. The record will be disqualified from Robots with a lower priority. Learn more about prioritizing Robots in the Robot Strategy article.

Q: If I have just manually deleted a record from Playbooks that was added by a Robot, will it immediately re-appear since it qualifies?
A: The record will stay deleted out of Playbooks unless Allow Action to Repeat is enabled and the record is disqualified from the Filter Criteria and requalified at a later time.

For more information, check out the other Robot Articles and the Play Maker Course on XANT University.

Related Course: Play Maker Course
For more information on Robots, take the Play Maker Course at XANT University.



Was this article helpful?