Skip to main content

Robot is not Enrolling Records / Tasks

Abdullah Tarawneh
  • Updated

Overview

Your robot is not working and it is not enrolling records to a Play. If you are trying to open your tasks you might notice that Playbooks isn't loading your tasks or that you have fewer accounts loaded into Playbooks. You also find that all your records or tasks are supposed to be enrolled automatically into a play on a re-occurring basis via a Robot. However, not all expected tasks are loaded in Playbooks. This might happen when the robot that enrolls the records is not working as expected - it does not act on qualified records, while tests are successful.

Note: Normally, the robot is expected to pick up records/leads within 10 mins.

Solution

  1. Make sure that the robot responsible for entering the affected records into plays is turned on - from the Robots tab, find the robot and toggle the On/Off switch on the right.

    mceclip0.png

  2. Check if the Allow Action to Repeat setting is enabled - if you want to enable it, open the corresponding robot from the Robots tab, toggle the switch next to the Allow Action to Repeat option and click Save.
    Having the repeat the action setting disabled on a robot means that the record will not be acted upon until it requalifies. Please see the Robot Action Details of the Robots overview article

    mceclip0.png

    As a workaround, you can clone the robot, which should create a duplicate that will either run successfully or will generate logged data for further investigation by customer support. Ensure that the new cloned robot has its priority set higher than the old one so that the new robot tries to act instead of the old robot.

  3. Check that the records (which should be enrolled) match the filter criteria configured for your robot. For example, make sure that the team to which the owner of the records is assigned in Playbooks is selected in the robot settings - to do this, you can check which user owns the records in the CRM and which team they are assigned.
    Make sure to check other filter criteria as well.
    And then test the robot to see the number of records that qualify for the robot.

    mceclip0.png

    Notes:
    • When you validate the robot (by clicking TEST THIS ROBOT) and it finds records, it doesn't necessarily mean these records now have to be processed by the robot. The validation is done on the CRM side only, it doesn't validate criteria in Playbooks (e.g. the record must be shared, allow action to repeat is on, etc.). So even if you see a record count greater than 0 when testing a robot, that number is just the number of records meeting the criteria in your CRM. Once the additional Playbooks side validations are added, it may not have anything to process. The "Last Run" of a Robot reflects the last time when the robot had records to actually action!
    • 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 (under Settings > Company Settings in the manager app). You can check task sync logs (search for CRMuIDs) to confirm if the required records were processed.
  4. This issue may also happen when the records are removed by a robot with a higher priority, meaning that the records are meeting the criteria of multiple robots.
    Make sure to set up the correct prioritization for your robots (by dragging and dropping the robots) - Enrollment Robots must have higher priority than Robots that Remove records. Once a record is removed, it cannot be actioned unless the record is added back to Playbooks.

    It’s recommended you group your robots into buckets by the primary action it will take and prioritize as follows:

    1. Call Disposition Robots. These will trigger immediately once the call log is saved.
    2. Email Tracking Robots. For the same reason, next group email tracking robots because they will trigger immediately.
    3. Enrollment Robots. If the primary action is to enroll records in a Play list those next so that further Robot actions can be taken like updating CRM records.
    4. CRM Field Update Robots.
    5. Removal Robots. These should be last because once a Record is removed from Playbooks it can no longer be actioned, unless added back into Playbooks.
     

If the above actions do not help, and if Robots were enrolling records properly earlier, but recently stopped enrolling them, please raise a support ticket including the name of the robot and screenshots of the affected records (including their CRM IDs).

<supportagent>Previously, problems have been reported with Robots not picking up leads due to a database performance issue. See the below ZD tickets and Jiras:

If the customer has all the settings set correctly as per this article, and if the robots were working previously, create a SaaS Incident.

</supportagent>

 

Related Articles

Comments

0 comments

Article is closed for comments.