Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
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.
The post Playbooks for Dynamics 365 Activity Templates appeared first on Surviving CRM.
Business Applications communities