In my previous post I explored the current Dynamics 365 Customer Engagement solution update practices and used the Playbooks feature as an example. Here’s a quick overview of what the actual Playbooks offer.
The official MS documentation, “enforce best practices with playbooks”, gives you a list of what the initial October ’18 release of Playbooks contains. The feature is essentially a way for a sales manager to determine a set of activities that sales users should perform when a real life event takes place that the playbook contents has been designed for. A checklist, if you will.
To get started, you’ll need to have the Sales app upgraded to a recent enough version, so that the Sales Hub UCI app displays Playbook Templates under the App Settings:
Notice that you won’t find these anywhere in the legacy web client (“classic UI”). One thing you might want to do first via that legacy client, though, is to ensure that the associated roles for Playbook Manager and Playbook User are assigned to the required user accounts.
To kick things off, you could create examples of Playbook Categories for grouping your playbooks, since that’s a compulsory lookup on the Playbook Template form. The actual configuration work will all take place on the template, where you’ll first of all specify the record types that the playbook applies for. Right now it’s only lead, opportunity, quote, order, invoice, so don’t plan on using playbooks for any custom entities or other Dynamics 365 Apps than Sales.
The template shows a subgrid of Playbook Activities, which look pretty much like your regular activities on the surface. They are a separate entity, however, as this is how you define the parameters for an activity (task, phone call or appointment). You have the usual subject, description, duration etc. fields you’d find on a normal activity, but instead of fixed dates you give them relative due dates, calculated from when the playbook is launched.
How you actually launch a playbook is via the applicable entity form. Let’s say we have created a Playbook Template for the opportunity entity and activated it. When navigating to an opportunity record we’ll see a “Launch Playbook” button on the Command Bar. This gives a list of playbooks the user has access to, with the option to launch one of them.
This creates the actual activities for presumably the user who runs the “Launch Playbook” action. At least the owner of the associated opportunity didn’t have any effect, so all the activities end up on my own My (Open) Activities view:
The one thing to pay attention to here is that nowhere in the resulting activity does it actually say what the related opportunity was to which the playbook was launched. Instead the Regarding field points to the Playbook record, which essentially is an instance of the Playbook Template. Sure, here on this form you see the regarding opportunity, but for anyone working via their My Activities view this isn’t really ideal.
It’s understandable why this is the case, though: you just can’t set the Dynamics 365 activities to have multiple Regarding records. If you want to track the progress of the associated activities, then they need to be grouped under the Playbook (instance). This does give you metrics like the start date and estimated close date of the playbook, number of total vs. completed activities. There’s also a status value for the playbook itself, which you can complete as “successful”, “not successful”, “partially successful” or “not required”.
Personally I don’t find this structure of having the resulting activities hidden away behind the Playbook record very user friendly. You can’t see the Playbook entity anywhere in the main Sales Hub sitemap, it’s just a related record for the main business record, or for the Playbook Template. If we have open activities that are about working on a particular opportunity but you don’t actually see them in the opportunity Timeline, then did they ever even take place? Sure, you could try and build a subgrid with deep queries FetchXML to get over the 2 hops in the relational data model, but that’s a bit of a stretch.
The quicker way to simplify things is to go on the Playbook Template and set the field “Track Progress” to “No”. What this will do is generate all the activities directly regarding the business record. So, when launching the playbook for a record like lead, all of its activities will be found directly in the lead form’s Timeline. Also your sales users will directly see which lead they should be completing the calls, tasks or appointments for.
That’s pretty much all the features I was able to discover when playing around with Playbooks. If you need to create a fixed set of activities for fixed types of entities (5 currently supported ones) on a regular basis, then this can sure be a handy feature to have around. It’s not all that advanced in its current format, as there doesn’t seem to be any obvious way to automate the launching of Playbooks when a data driven event takes place. That may be something we’ll see in the future, though, since a feature like this would surely fit well into the AI demos of how to automate your sales activities when a machine learning algorithm somewhere in the cloud detects that a customer is in danger of discontinuing their service contract, for example.
Another thing to consider is how these Playbooks relate to the task lists you may have earlier defined via Business Process Flows. The checkboxes on BPF stages are certainly a more structured way to present things that must get done, but they suffer from the fact that they are just a checkbox on a record somewhere. Playbooks can produce actual activities that will sit on the user’s ToDo list until they get completed, with notifications and all the usual activity integration. Given how the new Unified Interface presents the BPF control as collapsed by default, thus hiding the fields defined for the BPF stages, these are less and less likely to be noticed by Dynamics 365 users. You do have more control over enforcing a business process via BPF fields, though, whereas Playbooks in their current form appear more as a guidance for actions the user should complete – as long as they’re aware that there’s a Playbook waiting to be launched.
UPDATE 2018-11-08: There actually is a way to automate the creation of Playbooks already today. Even though MS documentation doesn’t mention it, the creation of a new Playbook record via workflow (or Flow) will bring in the activities defined in the Playbook Template that you reference while creating the Playbook. Thanks to Kevin Annfield who wrote a great blog post about this feature.
Hello,
Thank you very much for this article, very detailed! My project has upgraded to version 9.1. However, the project does not require playbook category entity. I navigated in the solution to take off the tick mark for the ‘allow quick create’ but it’s greyed out. Just wanted to ask how to remove it? Thanks!
Kriz, I’m not sure if the removal of the Playbook Category is something Microsoft would support. It’s a feature they’ve built and the logic may well require a category value to always exist. What you might look at instead is using a Business Rule to populate a default category value into the Playbook Template during record creation. If this would work, then you’d be safe from the feature breaking in a feature update to the Sales App.
Your previous blog “Keeping Dynamics 365 Apps Up to Date” sounds great! This playbook article make me to explore how to create a playbook that successfully respond to external events.