Overview
You have observed that some records have been actioned by a Robot. Perhaps some tasks are not populating in Playbooks by the Robot, as you would have expected. You want to check what robots do, know what their trigger criteria are, and the actions that the robots will perform based on their configuration.
Information
When you create a robot, you configure three aspects that will define the way the robot will behave. These aspects are:
- Owned By: Robots can work on records that are owned by a Team, a Queue, or Anyone. You have the option of selecting multiple teams.
- The trigger criteria: This section will explain how the Robot will be triggered. (See #1 in the below picture)
- The action: The action(s) that the robot will execute to automate the process. (See #2 in the below picture)
If you want to check the Configuration of an already created Robot, complete the following steps:
- Open the Playbooks Manager Application tool.
- Go to the Robots tab.
- Click on the Robot's title you want to get the configuration from.
- Check the configured criteria and actions.
Bear in mind that you can have Robots with lots of conditions to be triggered, and lots of actions to execute once these conditions are met.
Robot Examples
In the following section, you will find examples of Common triggering criteria, Common configurable actions to be performed by the Robot's engine, and an Ownership Configuration.
Triggering Criteria Examples
To illustrate how to refine the amount of records actioned, here are some examples of ways to narrow down Filtering Criteria within a Robot.
Filter for Current Records
Let’s say your CRM has a lot of old records that need to be archived. Even with basic criteria the returned results might be staggering. Employ Last Date Modified to include records that have been touched in the last 7 days.
Filter Out Records Already Evaluated by Playbooks Users
Perhaps you are using an enrollment Robot for a team of Playbooks users who have already been using Playbooks for a while. Consider using the Created Date field with the “on or after” operator and identify the absolute date as the date you launch the Robot. This would prevent the Robot from enrolling records that the users had already filtered out of their Playbooks.
Target Records in a Specific Play
You can also use Playbook fields in your filtering. If the Robot Action is to mark a Play Successful or move records from one play to another, you would want to specify the original Play Name the records are enrolled in. You’ll identify the Play the record will move to when you setup the action.
Identify Records at the End of a Play
If a record makes it all the way through a Play without success, you can move the record to a different Play or remove it from Playbooks entirely. Set the Playbooks Play Status to identify failed records.
Common Actions Examples
Here are some examples of commonly requested Robot Actions to help you determine which Robots will work best in your sales process.
Remove Successful Records from Playbooks
If you are trying to clear out Playbooks users after they have been marked successful in a Play, you might consider the Remove from Playbooks action. When this action is used, it will remove the record from the current Play and Playbooks, so you won’t have to create two Robots to clean up old records. In your filtering, set the Playbooks Play Status to equal ‘Success’. It is not recommended to broadly apply this Robot to all Plays, so include the Play Name in your filtering as well.
Remove Over-due Tasks from Playbooks
Another useful Robot tactic is to clear out records that contain substantially overdue Playbooks tasks, especially if those tasks are for lead records. If a lead isn’t being pursued because there are better leads to contact, clear it out with the Remove from Playbooks action. Identify the overdue tasks where the Playbooks Next Step Due Date is at least 30 days in the past.
Ownership Configuration
Let's say your triggering criteria match 4000 records. But a user is not seeing any records enrolled in plays. This can be because the user is not a member of any of the teams that are selected under the "Owned By" configuration. You may have to include another team, where the user is a member, or add the user to a team that is part of the ownership criteria. E.g. in the below screenshot, the user was a member of the "VIP Ops" team that was not originally part of the ownership criteria.
Comments
0 comments
Please sign in to leave a comment.