Category: Features

Keeping Dynamics 365 Apps Up to Date

We’re living in the “post-October” era where many of the new Dynamics 365 Customer Engagement features promised in the Oct ’18 Release are materializing into the live environments. Not all of them, though, since that space train carrying the Business Applications release bits has been scheduled to run from October 2018 to March 2019, as you can clearly see:

While some features arrive in preview and only for a specific geographic region, there is plenty of stuff that’s being deployed to nearly all Dynamics 365 CE online orgs. While we’re not quite yet at the target state of having every customer running the same version of the application, there’s no longer a process for scheduling the update for your own environments on a particular date in the distant future. v9.1 has most likely now been rolled out in all but the most exotic geos.

This lack of CDU calendars to pick the dates from doesn’t mean that everything would automatically get switched to the latest version. Remember that in addition to the underlying platform (now called Common Data Service for Apps, CDS) there are also the actual Apps to update. For example, if you’re running the Sales Hub a.k.a. the Unified Interface app for Dynamics 365 for Sales, the menu items in the App Settings section might look like the following:

Whereas what you should be seeing in the latest version currently is this:

How do we get there? Let’s dive into the world of solutions and find out.

Applying Solution Updates

How do we know which solution versions carry which new features? We don’t have a central place for such information right now, since the Microsoft Dynamics 365 Online releases page only lists fixes and changes to existing functionality (in theory at least). When we browse the documentation for specific features like Playbooks for example, we may see details like this:

OK, that gives us a hint about what versions we should be seeing inside Dynamics 365. Getting the platform version is easy enough via the About menu behind the configuration cog, and everyone who’s customized Dynamics CRM should know where to look for the solution version number.
(more…)

November 5, 2018
Unified Experiences in October 2018 Release
The October ’18 of Microsoft Business Applications is going to bring a whole bunch of exciting features, spread across the huge stack of products and apps that either make up or operate on the Power Platform. Much of them will be specific to an area that only some of the users or developers work with in their specific customer scenarios, but there are also going to be updates that will be visible to practically everyone. Here are some of those new experiences that we can expect to see within the next few months as the features are gradually released.

App Navigation

On the Model-driven App client side, there will be some changes to the navigation features in Unified Interface. Here’s what October ’18 update is going to look like for the end user:

The product team has communicated the following changes:
- Sitemap will now be expanded by default, so users don’t need to remember what icon stands for what entity/feature.
- Recent and Pinned items will be more prominently displayed at the top. MRU (most recently used items) will now be a single list instead of the earlier entity specific MRU list.
- Sitemap areas will be displayed at the bottom, with a more visible icon and area switcher feature instead of the tabbed area list on top in current version.
- Command Bar icons will have more color and hover effects to highlight their interactive nature.
- Both Sitemap and Command Bar color scheme will be changed to dark text on light grey background.
These are great enhancements that are aimed at making the Unified Interface work more smoothly on the desktop browser specifically. They will not affect the mobile or Mail app, but only the screens that will have a width of 480 or more pixels. It’s awesome to see that even though the clients share the same infrastructure, not everything is forced to work exactly the same way on a big monitor vs. small phone screen.

Hybrid Experiences on Unified Interface

For existing Dynamics 365 CE customers who are working in the “classic” web client, the question of “can we do this in Unified Interface?” is a critical factor in deciding on the strategy of how to migrate users to the latest experiences available in the cloud. There’s a list of capabilities not yet on Unified Interface over on docs.microsoft.com that should serve as the starting point for any such planning. For a more forward looking list, the Unified Interface roadmap presented at MS Business Applications Summit 2018 is currently the best summary of what to expect:

While there will be more and more entities and features natively supported on UCI, not everything from good ol’ Dynamics CRM is going to be rebuilt for the new client infrastructure – at least not yet. When you look at what’s happening on the broader Power Platform side, this prioritization makes a lot of sense, as porting over old UI controls as-is probably doesn’t fit with the long term platform vision. Still, you can’t just pretend that a few missing features like Advanced Find would NOT be critical to business users who’ve built their work processes around these core capabilities of Dynamics 365 CE.

The short term solution will be to offer a “hybrid UI”, in which the controls not yet ported to UCI will be opened up in windows that render the classic web client UI. So, things like merge dialogs, personal settings, SSRS reports and Advanced Find will be accessible to users from within Unified Interface, with the existing feature set that they’ve come to expect in earlier versions. Of course they won’t be mobile friendly like the responsive UCI controls, but desktop users aren’t probably going to care all that much about this anyway.

As we can see in the roadmap presentation, Microsoft aims to make Unified Interface the default experience first for new customers and shortly also to existing environments. There’s no need to panic over this change, though, as the plan is to introduce a “Side by Side” (SxS) option for administrators to define whether the classic web client is visible to users or not. If you have a good reason to not yet push everyone over to Unified Interface, you don’t have to – at least not with the Oct ’18 release.

Power Platform Admin Center

While the aforementioned changes are mostly relevant to customers who have bought Dynamics 365 Customer Engagement and are using it for either traditional CRM scenarios or more XRM style applications, it’s good to keep in mind that all these investments are actually done in the context of the greater platform. Starting from the July 2018 announcements, Power Platform is now an actual thing that Microsoft sells. To the developers and administrators it has seemed like a collection of separate product boxes of different shapes, but that experience is also about to get unified as the new Power Platform Admin Center is introduced:

You can already access this UI from either the short URL admin.dynamics.com or the longer (official) version admin.powerplatform.microsoft.com. Today you don’t yet see too many actual admin screens of individual applications within the Power Platform Admin Center, as the menu items will mostly redirect you to existing admin centers for PowerApps, Flow, Power BI and Dynamics 365 CE. Things are going to change soon, though, as a brand new admin UI will reveal the various Dynamics 365 CE settings that you’ve earlier been able to only access from the classic web client:

These images are taken from another Business Applications Summit presentation, “Key features coming to Microsoft PowerApps and Dynamics 365 admins”. Just like in the UCI session, there’s a great roadmap slide included that shows the stages via which the new features are planned to be rolled out:

Now, you may not want to look at the detailed dates, since both roadmaps are already ancient history from over a month ago and things aren’t necessarily quite where the initial targets were set. Nevertheless, these are the features and experiences that will soon be out there. If you compare this to the traditional Dynamics CRM world in which many current on-prem customers with their v8.2 (at best) environments are operating in, then it’s in many ways like a whole new application platform to work with. MVP Scott Durow has drawn a great diagram of the new admin experiences in Power Platform that also helps in illustrating the huge shift that is taking place here. We’ve seen architecture diagrams like the one below for a long time now, but once the actual user experience for solution designers also starts to reflect this, I believe that will have a “powerful” impact indeed!
September 6, 2018
Unified Interface Form Design Notes
It’s been around a year since Microsoft announced that Dynamics 365 Customer Engagement would be moving from the world of separate web, mobile and Outlook clients into a single Unified Interface (or UCI, as in “Unified Client Infrastructure”). At that time I made a prediction that this level of shift in the client technology would be a long road, and to date that still pretty much holds true.

Although V9 has been available for quite some time for new cloud instances and also existing customers have been upgrading as the version has become available for them a bit later, the majority of current Dynamics 365 CE users won’t yet be on UCI – at least for the desktop usage. MoCA was already replaced with UCI in V9, so the mobile UI is now on the new infrastructure, no choices there. For the web, there’s still a fair bit of capabilities not yet on Unified Interface, which makes it hard for customers to move over to it.

Eventually everyone will need to migrate to UCI, though. It’s best to start exploring the scenarios where Unified Interface can fulfill the core needs and to gain the skills needed for designing great user experiences on this new client type. Even though the majority of the customizations will be rendered the same in UCI as on the current web client, there are still details that you should pay attention to. This is a collection of a few observations I’ve made when building a Dynamics 365 Customer Engagement App on UCI. Specifically, I’ll focus on the entity form rendering here, as a continuation of the previous post where I covered the new Card Form type.

The Header

Let’s start from the top. Form headers are where you would have previously placed up to 4 fields that you wanted to be always visible to the user when opening the form and scrolling down along it. Great for highlighting properties of the record that users needed to be aware of.

In UCI there can still be just as many fields on the form header, but unfortunately they won’t always be shown. Even on a 1920*1080 screen resolution you may only see the first 2 fields on the form. The rest are hidden behind a small downward arrow icon that the user would have to discover and the click on to see the remaining header fields. I’m pretty sure most will never even realize the fields’ existence.

When using a smaller mobile device screen the rendering changes quite significantly. Since on a vertical screen there’s no space for showing a header next to the record primary field (the name), in this form factor the header actually becomes the very first form section to be shown to the user. The nice thing is that it’s really “in your face” for the user. The downside is that this may not be the most logical information to be shown at the start of the form – or at least it will differ from what the user might expect to find there. Especially when creating new records these header fields rarely are the ones where you’d start the data entry process.

For now, I don’t really have a good guidelince on how to consistently leverage the form header with UCI. You probably want to minimize the number of fields shown there, instead of capitalizing on the full 4 field opportunity, and stick to 1-2 fields max.

The Footer

Like the header fields, also the form footer has enjoyed a persistent presence on the XRM entity form. Now with UCI and Dynamics 365 CE, this is no longer the case. On a PC screen the fields do get shown, though, but not in a very nice way.

As an example, a fairly common use case for the footer has been to present a few entity default fields that were hidden in CRM 2013 upgrade when the record properties dialog was removed from the UI. I’m referring to the created/modified on/by information, which can be very useful in determining the validity of the CRM data and persons responsible of the updates. You can still put them there, but currently the rendering looks so messy that I’d prefer not to show that to customers:

The icons of these fields are often overlapping, even in full screen. This also highlights one of the current issues with UCI, meaning it doesn’t respect the user’s format settings and instead forces “AM” & “PM” upon users who live in a country where these concepts are never used. (Do also watch out for the date fields that sometimes reverse the order of day and month around, creating interesting results with things like appointment data entry.)

The upside of the new design is that the footer fields don’t add up an extra row at the bottom, instead they are incorporated into the gray bar containing the record status and update indicators. This is very welcome, since in the old web client with especially entities using the BPF control, you’d sometimes have barely any vertical space left for working on the actual record fields, thanks to all the padding at the top & the bottom. Striking a balance with these responsive screen layouts surely isn’t an easy task for the engineers, with requirements for both information density and touch friendliness being presented to them.

On a mobile screen you will not see the fields of the footer at all. It doesn’t appear to be rendered anywhere else on the form, so any information presented in this form section will be inaccessible in some scenarios. Much like the header, I would also advise not to put many fields in the footer if you plan on using Unified Interface (or if your users need them while out on the road).

The Tabs

The return of the visible tabs is certainly one of the big UX improvements compared to the old web client. Having these anchors visible right at the start of the form’s loading is a great help especially with information heavy forms like what accounts tend to have. Adding the “Related” menu to the end of the tab list to reveal the child entities is also much better than the mystery arrow in the middle of the old Nav Bar at the top of the screen. Left navigation and Proper Tabs, woo-hoo! Go UCI!

Except that much like the header and footer, the tabs aren’t persistent either. The moment you start scrolling down the form, the tab labels get removed from the screen. Doh! Oh well, I guess we’ll just need to scroll down a bit further without the help of those anchors…

Except we can’t. Once we reach the end of the tab, it’s a hard stop. No matter how much you spin your mouse wheel or swipe your finger on a touch screen, there will be no more of the form revealed to you. You see, in order to go further DOWN on the form you’ll need to scroll all the way UP, reveal the tab labels and then click/press on them. The longer your forms are, especially when reflown as a single column view on a smartphone screen, the longer it will take for your users to reach the next tab.

Having the tabs as containers with hard boundaries might be an understandable design choice from a UX perspective. Getting lost on an endless list of scrolling fields and sections will not be fun for the users, so bringing some structure into this navigation experience is welcome. On the mobile form factor there’s also the Semantic Zoom option to help the user understand the form’s different tabs and sections. Just a shame that also the Semantic Zoom icon is hidden once move down an inch on the form…

Here’s an idea to upvote: Ability to Dock “Tabs” on top of Unified Client Interface Tabs.

We’re Getting There

Despite of these few challenges, there is a lot to like about the way Unified Interface changes the user experience of entity forms:
- Quick View Forms truly blend into the native form fields in UCI, whereas with the legacy web client the rendering was always quite clumsy.
- Timeline is far better at exposing related activities, notes, posts than the earlier tabbed UI hiding most of the content.
- Subgrids are actually actionable, with access to full grid features like sorting, select multiple.
- Subgrid content rendering can be customized via custom control configuration options like Card Forms.
- Business Process Flow consumes less vertical space (although BPF stage fields being hidden by default may cause challenges).
- Visual hierarchy is much more obvious than even with the web client “refresh UI”.
A big bonus is also the fact that by default you’ll get the same form customizations for desktop and for mobile users. It may or may not be suitable for real life mobile use cases, but at least you get the starting point for designing a mobile optimized UCI App to be targeted for specific scenarios that only need a subset of full form functionality.

The key thing to keep in mind when considering the choice between the classic web client and UCI is this, though: UCI is the future. It will be continuously updated with more supported features and optimized for the end user experience with the latest browsers and devices. These updates don’t even require the customer to schedule their version upgrades via the CDU calendar, since from V9 onward all the Dynamics 365 online updates will be deployed automatically to customer environments. See the new continuous deployment policy that Microsoft just announced for more details.

More and more areas of the classic XRM UI will be moved over to Unified Interface with every release. Although we don’t yet know any dates for end of support for the web client nor the target date for UCI’s full parity, the next wave of features in October 2018 release will be published as release notes on July 23rd at the Microsoft Business Application Summit. Better keep an eye on that one!
July 10, 2018
Exploring CDS for Apps Platform Licensing (PowerApps)

When Microsoft originally made the Spring 2018 release announcement for Business Applications products and essentially promoted XRM to be the Common Data Service for Apps, they didn’t yet disclose the finer details about how the CDS for Apps license model would work outside the Dynamics 365 Apps and Plans that we’re familiar with. On May 1st the details were revealed alongside the blog post “Which PowerApps plan do I need for model-driven apps and CDS for Apps”.

In his earlier blog post, Frank Weigel announced that PowerApps Plan 2 officially became the platform SKU for CDS for Apps. In the updated PowerApps pricing page we can see that actually the license types and prices have effectively remained the same as they were before Spring 2018 release:

The changes are mostly on the new Model-driven App side (formerly XRM), but since there’s now also a wealth of server-side functionality made available for PowerApps via the new CDS for Apps concept, it also affects the Canvas Apps designers. Let’s dive into the details and explore the license model from a few different angles.

PowerApps for the Productivity Folks

A customer who’s got Office 365 will already have the specific PowerApps license type included in that subscription. As stated by the Licensing overview page over on docs.microsoft.com, this allows them to create and run applications within the context of this service (O365), as well as connect to “common cloud services including Box.com, Facebook, and many more”. Not D365 and not CDS, but that still covers a lot of interesting scenarios for building an app to replace a manual process that used to run on email or Excel.

Since it never was a “pure business app” like Dynamics 365 CRM and ERP products, PowerApps has grown into a highly versatile tool that connects with the more mainstream Microsoft services. You can embed them into a wide variety of places within your MS Cloud environment, like on Power BI dashboards or modern SharePoint pages. For your data collection forms, they are InfoPath on steroids. An Office 365 customer might therefore get pretty far with just mashing up the UI’s of different apps and storing data into less structured places like SharePoint lists or OneDrive files.

If they’d like to introduce more solid capabilities for relational data modeling, process automation and granular security management, the PowerApps Plan 1 would unlock this scenario for €5.90 per user. With this the data could be managed in CDS for Apps database, a much more robust back end for a business application than simple lists in the Office tools. The users still couldn’t access any Dynamics 365 style UI, since Plan 1 doesn’t grant the access to Model-driven Apps. You would need to construct the required lists, forms, navigation and client side logic with the traditional PowerApps “maker” experience and publish it through the same channels as what the Office 365 users already have access to.

This Plan 1 approach could be viewed as the first step up from the starting point where a knowledgeable power user or “citizen developer” had built a PowerApp with the license they already had via Office 365 and now the app needs to be adopted more widely within the organization. The new admins and designers of the app would need a Plan 2 license for €33.70 but the users could be assigned the cheaper Plan 1 license for €5.90 a piece. It shouldn’t be too difficult a business case to build if there’s real demand for the app and it either saves time or money in some business process that used to be a painful manual operation before Microsoft Cloud came along. If things work out well, these same P1 licensed users can then go and use any number of apps that the P2 power users design for them, since each P2 gets 2 databases with it and no limits on how many PowerApps you have on top of those.

PowerApps for the Dynamics Crowd

Dynamics 365 has a powerful, growing set of first party Apps from Microsoft, but sometimes there isn’t an app for that particular business process you’re looking to digitally transform with the help of MS Cloud. This is where the power of the platform comes to rescue and saves you from custom software development and maintenance efforts. Earlier this platform was called “eXtended Relationship Management” (XRM) but now we refer to it as the Common Data Service for Apps. We don’t even need to buy a Dynamics 365 license for it anymore, since we could just use PowerApps Plan 2 instead.

What sets Plan 2 apart from Plan 1 is that you can work with the application data via the Model-driven App UI that is automatically generated for you when you design your data model. Sure, you’ll need to configure the details of it to deliver a pleasant UX, but you’re not forced into pixel-perfect design work of the Canvas App. Navigation is provided for you, there’s the full search capability, you can quickly configure dashboards, Business Rules can make your entity forms adapt to field data values, and so on. With the new Unified Interface your Model-driven App will adapt to any screen size, and the solution framework ensures you can easily transport your customizations across environments. The Model-driven sample apps will give you a quick idea of what a non-Dynamics 365 app on CDS might look like.

There are limitations, though, and you’ll find them listed on the “license requirements for entities” page on CDS for Apps documentation. As mentioned, P1 users can’t access the Model-driven App UI, but they also aren’t authorized to access a Canvas App that runs on a CDS for Apps instance and uses entities that have real-time workflows or plug-ins associated with them. These require a P2 license, which unlocks the full XRM style functionality of the platform.

Now, just because the Dynamics 365 first party Apps from Microsoft are built on the same platform as your custom Model-driven Apps, that doesn’t mean a PowerApps P2 license would fully cover their usage. There’s a list of restricted entities that are used in MS apps like Sales, Customer Service, Field Service, that you aren’t allowed to touch without the proper Dynamics 365 license. For example, you’re free to work with leads and opportunities, but you can’t use cases or knowledge articles in your custom PowerApps – because Microsoft said so.

For an overview of the different license types and privileges, be sure to check out the great blog posts and ever so slick videos that MVP Scott Durow has created for explaning the topic of PowerApps to those of us who’ve got a Dynamics background.

PowerApps vs. Dynamics 365 License Model

Just because we now have something declared as Platform SKU on a Microsoft blog post doesn’t mean we get to skip the finer details laid out in the Dynamics 365 Licensing Guide. Anyone working on the partner side must have experienced the amount of documentation that goes into performing changes to the licensing practices of Dynamics products. (Remember that deck about transition from Dynamics CRM to Dynamics 365? Of course you do, how could you ever forget…) I’ve got a feeling that we’re going to see more licensing related information emerge about the new PowerApps Model-driven Apps offering in the near future, as this initial announcement raises many questions that need to be answered before customers and partners can fully embrace the new platform opportunities. (more…)

May 10, 2018
Look Out for The End Of Outlook Client

It’s been a while already since Microsoft announced they were deprecating the Outlook Client for Dynamics 365. This announcement applied to the release formerly (and partially still) known as July 2017 Update, which everyone should rather be calling by its version number, i.e. v9.0. Since this version has only very recently become available for existing customers to schedule their CDU dates, it’s a good moment to remind everyone what this means in practice.

You’ve Been Replaced By An App

They all keep saying that robots will take away our jobs, but in the meantime it’s apps that are taking over Dynamics 365. Like I explained in my earlier blog post “What’s An “App” in Dynamics 365 Anyway?”, one of the many uses for the term “app” is now the way you integrate Outlook with your CRM system. Unlike the earlier COM add-in of Outlook Client for Windows PCs, this App will now work in any client environment – both in the browser and in mobile environments. That’s why the App is the future and the Client is the past. Well, actually that’s just one of the reasons, but let’s keep it simple for now, since the outcome remains the same nonetheless.

So, if we’re just getting more of everything then isn’t this the easiest thing to sell in the world? It probably is a no-brainer for the IT guys who’ve had to struggle with the installation, configuration and updating of the locally installed Outlook Clients for years, as the administration overhead is reduced significantly. For the real end users of the CRM system, the perspective may differ, though. A user will immediately see the things that work differently with the App than they did before. Regardless of all the improvements, it will mean changes to their personal workflow, which is why you should pay attention to how the replacement is communicated and what support the users will need in this process.

In your initial tests of the new features with a V9 environment and the App for Outlook, it’s good to keep in mind that this is still work in progress. The V9 Readme / Know Issues page has a list of technical glitches and unsupported environments for the App that is today still in Preview mode. It’s expected that by the time the current customers get their V9 updates the fully supported App version would also be available. Even with these hotfixes, you should prepare to see some usability gaps remain in the product for a while, as we’re dealing with a technology that’s fresh from the oven: the Unified Interface.

In The Name Of Unification

The Dynamics 365 App for Outlook is one step on the long road towards a Unified Client Infrastructure. The earlier v8.x incarnation of the App was a limited side pane that would show information about records related to the email while browsing your inbox. The V9 App is a miniature app module built on the same Unified Interface that will power all the Dynamics 365 Customer Engagement UI’s in the future. This means that the feature set available is far greater, with the ability for you to scroll through the entire contents of a contact form while remaining in your inbox – or even navigate to related records. Similarly the commands at your disposal will allow completing tasks like adding new competitor records into your CRM database from within the single UI.

For anyone who’s used the Outlook Client mainly for tracking items from their mailbox, calendar or contact list into the shared Dynamics 365 customer database, this will surely seem like a big step forward in terms of the new contextual actions being offered. These users will have gotten used to opening a browser tab whenever they’ve needed to actually view and search the contents of the CRM database in full screen mode.

Then there is the group of users who’ve been in the Dynamics game for a longer time – at least from the CRM 2011 version. Back in those days the whole concept of Dynamics CRM might have been sold to them as “never leave your Outlook”. These people may not have actually seen a lot of the UX enhancements that have taken place in the browser and mobile clients in the past few years, since to them CRM has always looked like this:

A “next generation Microsoft Outlook Experience” revealed seven years ago. Yeah, you probably wouldn’t buy a Customer Engagement solution today that looked like an ERP built into Office 2010. That doesn’t mean there wouldn’t be power users out there who still rely on the feature set of the trusty old Outlook Client to keep them productive, because they have mastered the Ribbon, the panes, the tabs, the whole shebang.

The End Is Near …ish

Microsoft has stated that by the time V10 rolls out, the client UI pictured above won’t work with Dynamics 365 anymore. That’s kind of understandable we consider that the Unified Interface will also replace the web client at some point in the future – possibly at the very same moment. If that is the case, we might not yet be all too close to the final removal of the Outlook Client yet.

There’s going to be a lot of work needed before every last bit of legacy client infrastructure will have been replaced with the UCI based components. Microsoft remains committed to the guidance they’ve given to customers about the update schedule, which states there should be two new releases per year. However, we don’t really know much anything about at what point in time the next major release will arrive. Even things like rebranding Dynamics CRM to Dynamics 365 were handled over a minor update of v8.2, so who knows if we’ll see v9.1, v9.2, v9.3 etc. before the plug is finally pulled on the Outlook Client and (presumably) a whole bunch of other deprecated features in V10.

It also remains to be seen whether Microsoft intends to evolve the desktop experience of using Dynamics 365 Customer Engagement. For example, at the moment the documentation states that the offline functionality is available via the phone and tablet apps. The table app for Windows 10 could of course be used on a regular PC as well, but it’s not completely unrealistic to expect some more targeted client applications appear for the desktop environments. When it comes to the App for Outlook on a PC, the current version still installs an add-in to manage your contacts, for example. So, just because the UI controls are being unified now, this doesn’t necessarily mean we’d be forced to use an “oversized phone app” on our big monitors.

No More Updates – But Don’t Forget To Update!

Even though the Outlook Client is now deprecated and there will not be any feature enhancements made to it, that doesn’t mean it would be completely left to rot. In fact, it is very important that once your Dynamics 365 Customer Engagement instances moves up to V9 also your Outlook Clients are using the latest version. This version is now the 8.2.2.137 Update for Dynamics 365 for Microsoft Outlook, available for download here. Yes, it’s V8 and not V9, but don’t let that mismatch distract you.

You see, with V9 the XRM platform has moved up to using TLS 1.2 protocol for securing the connections between the clients and the server. The earlier Outlook Client versions do not support TLS 1.2 and the V9 server will not accept anything but 1.2 as the cryptographic protocol, which means you’re going to need the latest bits. If you have developed your own clients or code that relies on an earlier TLS version, then be sure to read this in-depth description provided by Matt Barbour of the possible errors you’ll encounter with V9 and the ways how you can avoid those by recompiling your code.

Update on 2018-01-29: Deprecation of Deprecation

Against all odds, Microsoft actually decided that they would reverse their previous decision to deprecate the Outlook Client. Read the following blog post and draw your own conclusions:

Continued support for Outlook add-in (Dynamics 365 for Outlook)

January 22, 2018
From AppSource to Solutions to Dynamics 365 Apps

In my previous blog post I presented the various different meanings that an App can have in Dynamics 365 Customer Engagement. Now that we’re aware of this jungle, let’s grab a machete and start making our way deeper into the heart of it, to understand how a system customizer can survive in there.

Before there was Microsoft AppSource for Dynamics 365, the methods available for distributing apps in a generic sense were pretty basic: you downloaded a zip file (or several) from a location provided by some party, then navigated to the solutions menu in your XRM environment and started importing them. When there were updates to those apps, you needed to repeat the procedure. If there were some other configuration steps needed in getting the application properly set up, you had to read the friendly manual and complete those. In a more tech savvy environment the Package Deployer might have been used here, but that was hardly a task for the accidental CRM administrator.

What AppSource aims to change in the Dynamics 365 app distribution process is similar to what the smartphone app stores did a decade ago, i.e. simplify the steps for the customer and also provide a better channel for app developers to deliver their updates. When you go to AppSource and choose to either install a free App or start a trial on a paid one, the next screen will provide an instance selector to determine where in your Office 365 tenant you want to put this App in. Also presented are the checkboxes for agreeing on both Microsoft’s as well as the ISV’s legal terms.

From here you’ll be taken into Dynamics 365 Administration Center. This part of the process nor the UI of the admin center isn’t very intuitive, so let’s pause here for a moment. While you’ll land on the Solutions view of an Instance after clicking on “Agree”, on the logical level we should be paying attention to the Applications tab instead. The chosen ISV (or MS) App will have been added as a row in the applications list, which applies to the whole tenant. In this example we see that North52 Business Process Activities is now available in our tenant. It doesn’t have any configuration options in this UI, but the Microsoft apps like Portal Add-on or Voice of the Customer both have an additional “Configure” button that is accessed via this Manage Applications screen.

If we click back to the Instances tab in the admin center, select one of our instances and click the Solutions icon on the right side, we’re now presented with the list of solutions available to this instance via the AppSource delivery channel. It is not the same as going to your XRM instance and clicking Settings – Solutions, as there can be more solutions within that instance. For example, the organization specific solutions that you’ve created as a container for your own customizations. Not even the managed/unmanaged status of those solution has anything to do with what’s shown in the admin center, because whatever zip files you imported directly into your XRM instance as a solution is only visible from within the XRM UI.

The solutions list in the admin center is also different in the way that it shows also the solutions you haven’t installed in the instance. These are applications that someone, either MS or your D365 admin, has made available in your tenant and possibly installed them into some other instance (a test sandbox, for example). To get them installed you don’t have to go to AppSource, rather you can start the process from here.

What makes this view so relevant for the Dynamics 365 instance administrator is that here’s where you’ll see what solutions have upgrades available. In the above example, Microsoft has released a new version of the Relationship Insights solution. Since they don’t want to accidentally break your dev/test/production orgs by changing the solutions on their own, they are rather giving you the controls to click on the “Update” icon for the particular instance when you’re ready for it. This same process is applied also for third party ISV solutions to deliver updated versions of their apps.

Now when we have deployed the app from AppSource and the Solutions view in the Dynamics 365 Administration Center for our chosen instance shows the status as “installed”, let’s use the Office 365 app launched to navigate to our Dynamics 365 start page, meaning home.dynamics.com. And… there’s nothing new here. Even if we click the “Sync” button to refresh the My Apps view, our AppSource app doesn’t appear. What gives?

At this point we need to take a step back from the UI and think about how these different components relate with one another. On the highest level we have AppSource, which is more of a marketing UI for products. From there we get Applications into our Dynamics 365 Administration Center. These manifest themselves as single solution rows for an instance when viewed via the admin center, but they can actually contain N separate solution files (look at Dynamics 365 Portals, for example). Finally, these solutions may or may not contain Apps – from 0 to N. This diagram illustrates these four conceptual levels and their relationships:

In our example we’ve installed North52, which is an administrator/customizer tool designed for “building simple or complex business rules using point-click editor, eliminating C# and JavaScript coding”. In short, it’s an app for configuring apps, but it’s not a business app in itself. That doesn’t mean it wouldn’t need a UI, of course, but the Command Bar shortcuts and the dedicated home page web resource with navigation options quite frankly is much better suited for this type of a power user tool than the new Unified Interface apps that are supposed to work even on 4″ mobile phone screens.

This brings us back to the App Module concept that was briefly mentioned in my earlier blog post. Before V9 and the Unified Interface there wasn’t so much benefit in building separate Apps for different functional areas of the XRM platform, as we had the one master UI for the instance available anyway. When the features are migrated over to the new Unified Interface, basically everything must be an App. In v9.0 we’ve yet to see how the more complex admin features will be implemented as Unified Interface versions, so currently it’s a somewhat jarring experience of 2011 meets 2018 for the system customizers.

Even when all the actual business application functionality has moved over to Unified Interface, there will still be many scenarios in which presenting an AppSource app as a Dynamics 365 App Module App doesn’t necessarily make any sense. UI extensions like Checklists will not have much use outside the actual business entity in which they are used. Any app that connects to an external web service to enrich the contents of Dynamics 365 records mainly needs a configuration admin UI somewhere. Sure, there’s nothing stopping developers from using the App Designer to define an App for their solutions, since all you technically need is a single HTML web resource to publish an App with a single menu item. However, separating the tool from the XRM instance in which it lives isn’t going to make the UX of configuring features any easier, so I’m not really hoping for the app clutter to increase this way.

Both the AppSource marketplace and the App Module in Dynamics 365 Customer Engagement provide significant improvement on how the business application features can be presented to business users and decision makers. What they don’t do is completely remove the need for Dynamics 365 system administrators to understand how the various layers and parts of the application platform are wired. XRM will likely remain an environment that’s just inherently more complex than an iPhone screen with its pretty app icons lined up just the way the single device user likes to see them.

January 14, 2018
What’s An “App” in Dynamics 365 Anyway?

Everywhere you look you see apps these days. Or more truthfully, you’ve been seeing them for ages already. Even in this blog I used the term “applification” over 2 years ago already, so it’s fair to say we’ve been living on the planet of apps for a long time by now. As catchy as those three letters are, the overuse of the term has some side effects that may lead to confusion when people refer to something as an “app”. With Dynamics 365 Customer Engagement (a.k.a. XRM), this danger is very real, since the term has been used in quite a carefree way when naming the different components found in the platform.

In this blog post I’ll try to provide some clarity for those that are less familiar with the various dimensions that a Dynamics 365 app can have. I will go through the places in which apps can be found and explain their intended usage scenarios. Then in a follow-up post I’ll dig deeper into the architecture of how apps relate to solutions and the XRM customization capabilities in the latest V9 version.

Mobile Apps

Since smartphones are to blame for the app craze, we might as well begin by doing a search in the iOS App Store. With the term “Dynamics 365” on my iPad I get a list of various different apps I could install on the device. The top there results present a row of apps from Microsoft, but they are all built on completely different architecture.

The first result named “Microsoft Dynamics 365” is the actual “CRM” app, meaning the one that’ll give you roughly the same features as you’ll find on Dynamics 365 Customer Engagement when accessed via a browser. Once the Unified Interface is fully developed, the mobile & the web will be almost identical, but currently it’s likely that you’ll see a somewhat different experience on mobile than what the browser UI looks like. You’ll find the app’s setup guide here.

The seconds result is “Dynamics 365 Unified Ops”. Yes, it’s also by Microsoft, even though the name doesn’t include the corporate brand this time. Now, if you’re looking for the CRM capabilities then don’t get mislead by the app’s description talking about mobilizing your business processes. This is the mobile ERP application and you’ll need the “cloud AX” environment to use it for anything. No, Dynamics 365 isn’t “unified” on the level yet that you’d have just one client for CRM & ERP, but most people probably wouldn’t need a phone app that huge anyway. If you’re into ERP, read more about the Unified Ops mobile app here.

The third result is “Field Service- Dynamics 365”. Although the app developer info on iOS says “Microsoft Corporation” this is actually the mobile app developed by Resco & licensed by Microsoft to be offered as a part of the Dynamics 365 for Field Service app license. It operates by connecting to the “CRM” instance and using its customer data, but the configuration is separate from the customizations you might have done to your Dynamics 365 Customer Engagement environment. The user guide for this app can be found here, while the customizers will find information about installing the Woodford solution for changing the app configuration here.

App for Outlook

For as long as Dynamics CRM has been around, the integration to Outlook has been one of its main selling points against alternative CRM products. The CRM Client for Outlook has served us well over the years but the time has come to lay it to rest and replace the Client with the App. The change is far more significant than what Microsoft’s product naming here would suggest, with “Dynamics 365 for Outlook” being the legacy client for your PC and “Dynamics 365 App for Outlook” referring to the lightweight app that will work on pretty much any device.

Unlike the mobile apps, the App for Outlook isn’t something that a normal end user can (typically) download and configure for themselves. A system administrator or system customizer must take care of the deployment steps, which may include switching over to server-side synchronization, approving user mailboxes (with O365 Global Admin rights) and finally pushing the app to either selected or all eligible users under the menu Settings – Dynamics 365 App for Outlook.

As of the first week of 2018, the Dynamics 365 App for Outlook in V9 is still in Preview mode, so a sysadmin needs to enable it from the System Settings – Previews tab. This is because the earlier app has been replaced with a completely new app in this release, built on UCI (Unified Client Infrastructure) that is used in the new Unified Interface. This will actually turn the previously feature limited Outlook sidebar app into a full Dynamic 365 Customer Engagement app that has similar capabilities as the mobile app mentioned above.

Dynamics 365 App Modules

When you’re logged in to Office 365 and you click on the Dynamics logo in the app launcher, you’ll be taken to the Dynamics 365 home page at home.dynamics.com. Depending on your environment’s configuration, you’ll see a few or a whole number of rectangular icons on this page. Those are all “apps”, but not like the previously described mobile or Outlook apps. More importantly, not all of them are necessarily Dynamics 365 Apps either. Huh?

The explanation is that the Dynamics 365 home page lists also your Office 365 tenant’s PowerApps apps (which probably should be just called “PowerApps” to make my head hurt less while reading that). Aside from those, the list will include apps from all across your Dynamics 365 Customer Engagement instances, so if you have sandboxes for development and testing purposes, the very same app name & description may appear here multiple times. Furthermore, if you’re also using the ERP side of Dynamics 365, the home pages covers them as well.

In the Customer Engagement world an app module is basically a subset of the components you can find within a single instance. It can include navigation, dashboards processes, entity views, forms and charts. Aside from a few app specific configuration items, it doesn’t really add anything that you wouldn’t have in the “full” XRM instance already. They are a way of controlling what contents of that particular instance is visible to the end user.

Each XRM instance has by default at least one app, which will be called “Dynamics 365 – custom” unless you rename it in the System Settings menu. In addition to this, there can be N apps built and configured via the App Designer, or provided as readymade apps from Microsoft, like Field Service in the screenshot. Both the old web apps and the new Unified Interface apps will be present here if your instance is V9+. With so much going on here, I personally try to avoid ever navigating to the Dynamics 365 Home page and just store the direct URLs in my browser’s bookmarks bar where I’m in total control of how the apps are named and organized neatly into folders.

Microsoft AppSource

If you feel like you don’t have enough apps on your Dynamics 365 Home page, you can click the “+” icon that says “Find more apps that work with Dynamics 365”. This will open a modal window of AppSource, filtered down to the apps that are designed for, integrated with and some even built on top of the Dynamics 365 platform. Many of these will be built by partners (ISVs) but some of the content is authored by Microsoft themselves, either as officially supported solutions like the Social Selling Assistant, or as “accelerator” style solutions from Microsoft Labs with no warranty or promise of future support like Attachment Management.

The AppSource apps are closest to the concept that the word “app” was associated with when the iPhone’s App Store was launched ten years ago. These may be small extensions to the common CRM feature set, like a Marketing Calendar component for visualizing campaign records, or integrations between Dynamics 365 and a standalone service like Adobe Sign. Just like in a smartphone app store, some items are completely free of charge while others will cost you dearly. Since we’re dealing with enterprise systems here instead of individual mobile devices, some services allow you to do a test drive in a sandbox completely isolated from your organization’s Dynamics 365 instances, like the CPQ solutions from Experlogix and PROS.

What can be confusing about AppSource in the Dynamics 365 context is that probably the majority of the apps available in AppSource will not actually result in a new app icon being added to your Dynamics 365 home page. This is because up until V9 and the Unified Interface there wasn’t really a proper presence for the App Module in the XRM platform, so the world is only slowly adjusting to this new reality. I’ll delve into this very topic in my next blog post.

Dynamics 365 App Licenses

The concept of an app exists not only in the visible UI and logical platform component containers but also in the contractual world of software licensing. If you go to the Dynamics 365 Pricing page and download the Licensing Guide PDF, you’ll see the detailed way in which the rights of a licensed App user are defined in relation to the features provided by the XRM platform. There are in total 176 occurrences of the word “application” in this document, so don’t expect a quick answer. However, since XRM still largely follows an “honor system” where it’s up to the system administrator to limit the security roles of a user to match those to the rights given to him or her via the assigned Dynamics 365 license type, you’re going to have to understand the concepts.

Even though you can purchase and assign a user a license for Dynamics 365 for Sales, i.e. an app license, this doesn’t mean that the only thing this user would see or would be legally allowed to access would be the Sales app icon on the Dynamics 365 home page. They can be allowed to view the entire contents of any XRM instance in that particular Office 365 tenant, thanks to the first row in the above table (“all Dynamics 365 Enterprise Edition data”). They could access the “Dynamics 365 – custom” app to look around the whole suite of features in Customer Engagement. They could leverage the Dynamics 365 App for Outlook to track emails to records. But if you misconfigure their security roles and allow them to track emails against case records (a Customer Service app feature), you are in breach of the licensing contract.

Alright, that’s about as many “app” mentions as I can reasonably fit within one blog post. Next time I will take a look at Apps from a system customizer perspective.

January 6, 2018
Activity Management Enhancements in Dynamics 365 (v8.2)
Whenever a new version of Dynamics CRM and now Dynamics 365 (the XRM part) are released, the first thing you should review is the “what’s new” documentation that Microsoft produces for three different audiences: users, admins/customizers and developers. For the “December 2016 update for Dynamics 365” a.k.a version 8.2 of what used to be called CRM, these articles can be found from the following links:
As always, there’s way more goodies in there that a single blog article could ever hope to cover in meaningful level of detail. One area that deserves a mention in terms of the core XRM platform enhancements is the way activities can now be presented in the UI, so let’s focus on those in this here post.

Display the associated activities of the related entities

If you’ve happened to read my ancient CRM 2011 era blog post about how subgrids ain’t what associated views used to be, then the concept of activity rollup may be familiar to you. The way Dynamics CRM has worked up to this point is that for out-of-the-box core entities like Account and Opportunity the activities from under the child entity were presented also under the parent entity’s Associated Activities View. If you created a custom entity under the Account, though, then none of the activities linked to it would show up in the rollup view. A major inconvenience for any XRM scenarios where you then had to instruct the users not to track their activities against any of the child entity records but rather put them all to the Account level.

In v8.2 this limitation has now been addressed by the product team:

“We added a new flag called Rollup View in the customization user interface, on the Relationship Behavior form. It lets customizers indicate that associated activities of the related entity should be included in the Activity Associated View for the primary entity.”

Woo-hoo! Let’s go and try this one out in an example scenario with a custom entity called “Account Plan” that we’ve linked to the standard Account entity via N:1 relationship. Meaning: there can be several Account Plans (per year, for example) for a single Account. Being the “plan” and all, you’d find it pretty natural to track tasks and other upcoming activities against this record, but also would probably prefer to have access to them from under the parent Account of this plan.

When we open up the relationship configuration screen and have a look at the Relationship Behavior section, we find our usual list of actions where cascading behavior can be configured. Down at the bottom there’s a new option: Rollup View. This is where the magic will happen for activity rollup between the two entities. (Note: if the field is disabled, make sure your entity is enabled for activities before trying to enable the Rollup View.)

With the Rollup View behavior set to “Cascade All”, we can now go and do some activity entry on the Account Plan form. Let’s use the Social Pane to add some tasks that are set regarding this particular plan. Normally this would be the only place where we’d see them (aside from the owner’s My Activities view and their task list synced to Outlook, of course), but thanks to our cascading relationship behavior this will no longer be the case. Let’s navigate up in the hierarchy towards the Account record.

Now, in addition to the activities that have been either directly set regarding the Account or one of the built-in roll-u enabled child entities, we also see those activities created from the Account Plan form listed in the Social Pane of the Account record. A tiny step towards the mythical “Customer 360”, but a major improvement nonetheless for ensuring the complete communication history for a particular customer account is easily accessible for the Dynamics 365 end user. In case you were wondering: yes, these child entity activities also roll up the account hierarchy, so a global group’s top account may end up having a BIG list of emails in its Social Pane.

As for another follow-up question related to the article from five years ago: no, the activity subgrid still won’t show any of these “special” relationships. The feature is specific to the Activity Associated View, which is also a “special” thing in the XRM platform, supported by another “special” component called the Social Pane. The implications from this are laid out bare in the feature documentation:

“The primary entity for the relationship must be Account, Contact, or Opportunity. This is because these are the only entity forms in the system where the Activity Associated View appears. You can’t specify any other primary entity for activity rollups.”

So, this is not a generic Holy Grail to presenting activity data in XRM just the way we’d want to, but one big rock rolled in the ditch from that long road at least.

Control how activities are sorted by date

Another new feature in v8.2 that touches upon the same functional area is related to the Social Pane configuration options. Traditionally, these words would not have existed anywhere near each other – aside from the countless feature requests on ~~MS Connect~~ CRM Ideas forum. Everybody liked the CRM 2013 feature in terms of rich presentation and inline editing capabilities, and simultaneously loathed it for being a completely uncustomizable component placed smack in the middle of most XRM entity forms.

(more…)
November 22, 2016
CDM: New Data Model For The Common Good?

The first new component of the upcoming Dynamics 365 platform that has reached a stage of public preview is the Microsoft Common Data Model (CDM). Available via PowerApps, CDM can be provisioned in your Office 365 tenant with only a few clicks, so there’s little reason for not having a look an early look at it. In fact, you only need to sit back and relax while watching CRM MVP Scott Durow walk you through a first look at the Common Data Model:

So, there you have it! That’s what CDM looks like when accessed via the PowerApps web management UI. Any questions?

Yeah, I actually do have a couple.

How will this work with CRM and AX?

What we have available in the preview is pretty much the most straightforward part of the very big puzzle to put together, meaning a database on Azure with some preconfigured tables and data model management tools. We do not yet know much about how the Dynamics CRM and Dynamics AX functionality will be linked to CDM as part of the Dynamics 365 cloud platform, so there’s plenty room for speculation, which honestly is mostly what I’m about to do here. In a way I’m just continuing on the theme of my previous post about Dynamics 365 and its potential implications for XRM, to pass the time as we wait for Microsoft’s plans to be revealed in more detail.

Right now the only way to push data into CDM is a Flow. If you’ve ever played with automation tools like IFTTT or Zapier, then you’ll quickly grasp the idea of Microsoft Flow. The application itself shouldn’t be underestimated just because of its current simplistic demo scenarios that usually are along the lines of “when a new row is added to a SharePoint list, send an email to this address”. Built on top of Azure Logic Apps, there’s actually a next generation BizTalk type of cloud integration platform under the hood, which should provide plenty of future potential for advanced messaging solutions to orchestrate business processes across a number of different systems.

Once Dynamics 365 Enterprise arrives and gives us the features of CRM and AX in one seamless cloud environment, there’s naturally going to be a need for something a lot more than a “build your own” type of Flow integration. Keeping the Sales and Operations apps of D365 in sync with the customer and transaction data managed in the process of making an delivering a sale involves a fair amount of business logic. If you’ve ever designed and developed a custom integration for this type of a scenario, you’ll know the requirements can quickly grow a bit hairy. Assuming Microsoft can come along and say “we’ll take care of that hairy part, don’t you worry about it” then who could resist it?

The reason CDM exists is that there will be more than one physical database in the Dynamics 365 suite. It’s not all XRM, which means you can’t find the Operations app entities inside your CRM solution files. For the business processes to work seamlessly, someone needs to keep those database closely in sync with one another. From reading through the Common Data Model tutorials, we can see that at least as of now, Flow is not the system that can handle it:

“Today, when you use Microsoft Flow to import data or export data, it is not a full synchronization service. Whenever an object is added to one service, it will be imported into the other system. However, that means if an object is deleted from one system it will not be deleted in the other system.”

So, the sync part is still in the “To Be Implemented” bucket. So is security, since the passing of a record from CRM to CDM via Flow will not carry over any details about who should have the rights to do some CRUD work on it. Again, it may not sound like such a mission impossible to build. However, if you’ve ever faced the requirement in a Dynamics CRM project to implement SharePoint document library integration with account records that includes not just linking the folders but also enforcing the account access rights on the documents, you’ll know the struggle is real. Sure, a collaboration solution like SharePoint has very different security concepts than a system designed for structured business records management like CRM or ERP. But if Microsoft hasn’t been able to offer OoB synchronization of access rights across Dynamics CRM and SharePoint despite of the clear business demand for it, maybe we’d be foolish to expect that it will all be seamless inside the Dynamics 365 world either.

The thing here is that unless the solution provided by Microsoft is going to be fairly advanced, it might not be an actual solution. It’s like the old saying from the dawn of the internet:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

When confronted with the need to integrate processes across two different cloud business applications, there’s always the danger of someone rushing into thinking “I know, I’ll build a database in the middle to unify the process data”. So we end up with three cloud business applications… Now, I’m not saying that Microsoft wouldn’t have the type of application architecture masterminds working on the Dynamics 365 platform that can solve these complex problems when developing a new product. I’m just afraid that things may still turn out a bit more complex in reality than the marketing pitch for the new product launch might lead people to believe.

What limitations will this impose on customization?

The one reason why many of us love the capabilities of the Dynamics XRM platform is the awesome flexibility it offers us to customize the application to meet the specific needs of customers. And by “customize” I actually mean “configure”, since these days you can build such amazing features for business users without writing a single line of Javascript or C#. With Dynamics 365 now promising to deliver so many preconfigured apps for different departments’ needs, as well as making them all work together, I bet some of us are thinking about whether there’s a potential threat to the platform’s flexibility buried in the new approach Microsoft is taking. (more…)

August 29, 2016
A Million Voices: VoC Survey Results Analysis

A few weeks ago I launched a demo survey built on Voice of the Customer, the brand new survey tool from Microsoft. The goals I had for this exercise were twofold: 1) see how these type of interactive tools could be used in live events like eXtremeCRM 2016 Warsaw, and 2) gain some experience on what it is actually like to work with incoming survey response data inside Dynamics CRM. In this post I’ll mainly be focusing on the latter one, although the example data we’ll be looking at are the live answers you & other readers of this blog submitted via the eXtreme MVP Survey.

As you may know, Voice of the Customer (or VoC as we’ll refer to it from now on) is a pure XRM solution. Although the actual customer facing survey forms are of course not presented via the Dynamics CRM client UI, everything that you use for configuring the survey questions and logic, as well as the incoming survey responses, is managed with CRM entities and stored into the CRM database. The reason this is such a big deal is that most of you will already possess the skills needed for leveraging such data via views, charts and dashboards as it’s just XRM all the way. Furthermore, you’re free to design business processes around the survey functionality with tools like real-time workflows or business rules. Naturally you’re also able to interact with the survey entities and records via the latest CRM Web API, should you come across some integration scenarios where data needs to either flow in or out to another system.

The flip side of this coin is that VoC is unfortunately very XRM-ish to work with. If you compared it to dedicated survey apps that do nothing but questionnaire design (like SurveyMonkey, Surveypal and the likes), survey publishing and response data analysis, then there’s still quite a big gap for Microsoft to work on bridging when it comes to the end user experience of this tool. In a way this is quite understandable since the value proposition of VoC really is all about the tight integration with your customer data and the ability to send survey invitations automatically as a part of your customer facing processes; such as a survey link being emailed to a customer after a support case is closed in CRM, to gather quick ratings and design automatic escalation paths if the KPI’s are not met. Nevertheless, since VoC does also support creating pretty advanced surveys for collecting quantitative data from a broad target group in more traditional campaign style satisfaction surveys, as well as anonymous survey links presented on website, it’s good to understand what it’s like analyzing such data inside Dynamics CRM.

There are a lot of components in the VoC solution right out of the box. First off, there are four SSRS reports: Survey Summary, Question Summary, Net Promoter Score and Survey Export. The first two are general purpose reports with tables and charts summarizing the data either across a single survey or a specific question, as illustrated in the screenshots shown here. The NPS report is naturally aimed for this particular survey type, whereas the export one is a single huge matrix for dumping out the raw survey response data into Excel for further manipulation.

For more interactive data analysis there are eight dashboards in the VoC solution. However, these may not be all that useful for many real life scenarios, since they suffer from the same limitation as all Dynamics CRM dashboards: there are no global filters you can apply for all the dashboard components. Meaning, unlike with an SSRS report launched from CRM, you can’t set the context of the dashboard to be a specific survey. Yes, with the new “interactive experience dashboards” introduced in CRM 2016 you do get this type of filters, but since right now those features are limited to the Interactive Service Hub only (which in turn has a fair number of limitations for general use), it’s not exactly the kind of solution we’d need right here.

That doesn’t mean we couldn’t build pretty dashboards to summarize our survey responses, though. I had a go at this with the eXtreme MVP Survey and it turned out pretty well. Have a look (click for a larger image):

In the survey form I had three pages full of questions and I constructed the corresponding pages as personal CRM dashboards. This allowed me to both monitor the incoming responses during the survey data collection period as well as present the results to the audience at the MVP Showcase session in eXtremeCRM. It looks good, it appears very familiar to existing CRM users and it gets the job done without having to resort to any complex report development. (more…)

May 8, 2016