Start a conversation
  1. Playbooks Support
  2. Playbooks - Robots
  3. Articles

Robots Overview

Overview

Robots use automation rules to perform common administrative tasks in Playbooks and the CRM of choice. These rules query the CRM or Playbooks database to search for records that meet specific criteria and perform a predetermined action on that record.

One of the ways robots are used is to automatically enroll or remove tasks that meet certain criteria from a Play, making sure each rep has an updated list of tasks for the day. Whenever a task in a play has been completed or actioned, it is considered disqualified and removed from the query results. When a task is disqualified, the CRM results will be updated.

Robots are highly customizable. While there are certain examples that can be provided on how to configure a robot, most organizations will need to adapt these examples to their own processes. 

Topics

Robot Behavior

Robots can only be accessed from the Playbooks Manager App. To be able to configure a robot that behaves as expected and improves a process within an organization, it is very important to understand the anatomy of a robot. A robot is made up of the following:

Anatomy_Of_A_Robot_Shared.png

  1. Robot Name – Determines the title that appears in the Robot tab once a Robot is created. It’s best practice to name each Robot with the type of record it targets first followed by what it does (ex. Lead – Top Scored – Add to New Lead Play).
    NOTE: If the name is too long when viewing Robots in the Manager app, hover over the name to see the full name or zoom out the view in the Chrome window. 
  2. Filter Criteria – Establishes the criteria used to identify the records affected by the Robot. This is very important because if this is not specific enough, the user’s Playbooks could be flooded with more records than they could possibly manage and overwhelm their CRM with API Calls. Each of these criteria must be designated before assigning the action to the Robot.
    • Record Type – Defines the CRM object and which user in Playbooks will be impacted. What is selected 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 a Playbooks Consultant.
    • 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.
    • If a person meets this criteria… (Additional Filtering) – Additional CRM fields, call dispositions, or email tracking data to narrow down the applicable records. 

      Notes:
      • If a certain field is not visible for you when editing a robot, it means that your account (or access user) does not have Read permission to this field in your CRM, which should be adjusted by your CRM Admin. For more information refer to the article Why is a Field Value Missing In the Filter for a Robot?
      • Robots cannot be configured based only on cross-object filter criteria. For example, if a user creates a robot with filter criteria based on a secondary field value, the robot will not pull any records - a filter based on a primary field needs to be specified as well for a robot to work properly. Primary fields are record types (account, contact, opportunity, lead), and if a user wants to import leads that are added to a specific campaign, they need to add filter criteria for leads in a specific status and a separate criteria for a desired cross-object filter (e.g. campaign name) as described in the article Robot Finds no Leads from a CampaignMember Object.
  3. Actions to Complete – Specifies what actions the Robot will take. Each Robot can perform up to five actions. Since Robots can increase the CRM’s API and have real impact on a user’s Playbooks, Robots should be carefully crafted and tested before going live.

    Robot Action Details

    Robot Action Action Details
    Remove from Playbooks
    • Identifies field and value
    • Removes the record from the Play
    • Changes Playbooks Play Status to “Unenrolled”
    Attention Required Notification
    • Specifies the notification message to pop-up
    • Contains a maximum of 80 characters
    • Displays the message in Desktop Notification and Playbooks Alerts
    • Accesses the record by clicking the Playbooks alert
    Update CRM Field
    • Identifies the field name and static value to update
    • Excludes date and formula fields
    Add to Play
    • Identifies the Play Name
    • Adds the record to a Play
    • If the record is currently enrolled in a Play, unenrolls the record from the currently enrolled play and moves it to the specified Play
    • Includes an additional option to Reverse the Action

    NOTE: When reversing Play enrollment, the Playbooks Play Status field will be updated to “Unenrolled”. To track Play success, a task report can filter for the Playbooks Step Success checkbox.
    Remove from Play
    • Removes the record from the current play
    • Updates the Play Status to “Unenrolled”
      No additional configuration is required. The record will be removed from the current Play.

    Notes:
    Mark Successful
    • Marks the “Playbooks Step Success” checkbox on the last completed Play step
    Allow Action to Repeat

    Allows the Robot Action to be executed again on the same records.

    For example, if records were added to a Play by a robot, then removed from a Play, and if they still qualify for the same robot, they will be enrolled into Play again only if the Allow Action to Repeat option is enabled.

    NOTE: Any action above can use the Repeat Action setting. Without this setting turned on, a record will only qualify for a Robot once.
    Set Record View to Shared
    • Changes records to Shared

    NOTE: You must choose which teams will have access to this record when you create this action.
    Set Record View to Personal
    • Changes records to Personal

    NOTE: You must determine if the record is sent to the last person who performed an action or the CRM record owner.
  4. Test This Robot – When you click on this button, the number of records that match the robot criteria is being displayed for each owner, these records will be actioned by the robot once it is enabled. 
    Robots run automatically to complete whatever action has been assigned to them once they have been turned on. Each Robot should be tested before it goes live. Before making a Robot live, the “TEST THIS ROBOT” feature must be run. If the test indicates too many records will be actioned, the Filter Criteria must be reviewed and adjusted.
    • Note: When you test a robot, it may show no qualifying records if they were recently actioned by a robot; for example, when robots for your organization are scheduled to run every 5 or 10 minutes (this can be checked under Settings > Company Settings in the manager app). Also, you can check task sync logs (search for CRMUIDs) to confirm if the required records were processed.

    • If certain CRM Fields are not visible in the filter dropdowns and you cannot see which option is selected for a robot, you can click Test This Robot and then Copy Robot Criteria to see the configured rules in text format (it will be copied to clipboard). For more information about Custom Fields in CRM and related issues, refer to the article Overview of Custom and Default Fields in Salesforce and Data Synchronization.

      mceclip0.png

 

Once a Robot has been created, enabled, and prioritized, it is possible that unexpected records are found in a Play that is impacted by the robot. Or, some of the records that are expected to appear in a play are not included. This can happen due to the following:

  • The Robot used to add records to a play was not configured correctly.
  • There is another robot with a higher priority that is removing or adding records to the play. Priority is given by the order of the robots in the Robots list.
    Note: If a record was actioned by a robot with a higher priority, it will not be actioned by any other robot (for which this record may qualify).
  • The play already contained open tasks before the robot started adding records to it. Additionally, the tasks within the play are not sorted correctly and these old open tasks are displayed first. 
  • Records are owned by a user in CRM who does not match the owner criteria configured for the robot.
  • The Allow Action to Repeat option is disabled for the robot and it cannot perform the same action to the records again.
  • Records that are already in a Play are being qualified each time an existing Robot run, as the filters don't exclude already enrolled records for your robots. In such cases, Robot hit the 2000 records per user limit - no actions will be performed by a robot. Hence, you need to exclude enrolled records from filtering criteria of robots, which are used to add records into Playbooks. 
    For example, this can be done by setting a specific Owner of the records in the filter criteria for robot or by excluding records that have the Playbooks Play Name field value (it is not blank).

Modified By, Modified Date and Last Run.

When investigating discrepancies in robot behavior (e.g., records stopped being enrolled), you can check the Modified By and Modified Date fields, which will indicate who updated the robots and when (only the most recent update is logged). The Last Run column shows the last time the Robot ran and actioned on a qualifying record.
Note: When priority of one robot is changed (i.e., it is moved up or down in the list), the priority of all of the related robots is changed as well - the Modified date and Modified By fields are updated for all of these robots.
For example, if you move a robot down from the first priority to seventh, robots that are in the 1st to 7th places will have a new Modified Date and Modified By values. If you move a robot up from 10th position to 7th, the priority and Modified Date/By values are updated for robots on 7th to 10th positions. 

mceclip0.png

Related Articles

Choose files or drag and drop files
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted
  3. Updated

Comments