Tip #989: Cross-survey reporting with Dynamics 365 Voice of the Customer

Consider this scenario: you are conducting 4 different surveys, each of a different industry. But you want to be able to report on Net Promoter Score across all industries. What are the options to optimally group and report the the NPS responses across all four surveys?

  1. On the question record, there is a field called “reporting text.” This allows you to add an ID/text tag to questions for grouping purposes on reports. For example, you could add “NPS” to all of the NPS survey questions, then group the responses by the question reporting text.
  2. Word the questions in the same way on on all surveys, then group by question text. One way to do this and prevent “fat finger” errors messing up your reports is to create a template survey that contains the questions you want to be on all surveys, then use the clone feature to copy the template survey to create each of the other surveys.
  3. The linked question feature allows you to link related questions on different surveys to a common question for reporting purposes. For our example, you could relate all of the NPS questions to the same linked question, then group by the linked question field in your report.
  4. Response routing lets you conditionally display fields or sections from another survey based on response rules. This is the one option to actually reuse questions on multiple surveys and have them share the same question ID/GUID. While this option works, you will have to think of some question to ask first to trigger the shared questions to appear on the survey.

A final option is to not group responses, but instead to score your survey responses. Voice of the Customer allows you to assign point values to responses to calculate an overall survey response score. You can then report on customer satisfaction across multiple surveys by tracking survey response scoring.

So the takeaway is, there are multiple options to configure your surveys so responses can be grouped and reported on across surveys. They important thing is planning for analysis before you distribute the surveys, and ensuring that once you get your 2,400 responses per day you will be able to use the data.

How do you track your customer satisfaction across multiple surveys?

Share on FacebookTweet about this on TwitterShare on Google+

Tip #988: Tracking confidential emails

Tip of the day reader Christian Schulte shares the following tip about tracking emails flagged “confidential” with Dynamics 365 for Outlook (the “Outlook client”).

Let’s say you get a mail with a confidential-flag with sensitivity level set. It is not important which sensitivity-level it is (private, personal, confidential).

If you decide to track this mail, it will get tracked and created just like any other mail. But: There will be no body in the CRM-mail.

Christian uses CRM for Outlook ( It is also referenced in a CRM idea.

This feature can be a good or bad thing. If you are in a highly confidential industry, tracking the email without tracking the contents of the conversation can be a benefit, as you can record that an interaction took place without risking revelation of sensitive details. But if this doesn’t apply to you and you want to capture the contents of the email, finding out the body was not tracked may be an unwelcome surprise.

So what happens in the Outlook App?

Microsoft does not document this behavior, so there is no official “how it should work” documentation. Based on our preliminary tests, it appears that if you track an email with sensitivity level of private or confidential and track it with the Outlook app, the contents of the email body is tracked in Dynamics 365.


Share on FacebookTweet about this on TwitterShare on Google+

Tip #987: Kill a few millions async jobs

When Jonas “Surströmming MkII” Rapp said that “someone should probably get fired”, he was careful to qualify the statement with “asking for a friend”. Sure, we’re here to help, friend or foe.


Some integration job happened to touch fields that should not have been touched, and triggered a few async plugins a couple of million times. Async server is short-cutting from sweat, SQL ready to commit suicide, UI taking a nap while her friends are busy staying alive.

The only thing I can think of to fix it in reasonable time is to stop async service, run SQL update on all jobs to set status to cancelled, and then restart async service.

Any ideas or advice for me?

Truck to the rescue

Tipster truckThe replies came thick and fast. Below is the readers digest version. Thanks to Joel, Mitch Milam, Andrii Butenko, and David Jennaway for their throughtful contributions.

Supported option or not, if on premises, then the first thing you’d want to do is to stop async service. Regardless where your instance is, take a backup for a good measure, you might need it if things go pear-shaped.


For supported approach you’d need to cancel the jobs then delete them. You can cancel in bulk without any code by using a third-party SSIS package. If coding does not scare you then use an Update to change the status of the asyncoperations, and you’d get the best performance by wrapping this in an ExecuteMultiple. To minimise latency, run the code directly on the CRM server, also run multiple instances in parallel (code should need to be able to handle concurrency).

Once all jobs are cancelled, use bulk deletion job to mop up. Don’t sweat writing code for that – bulk delete is already very efficient.


On-premises only, of course. Everyone seems to agree that direct SQL will be by an order of magnitute faster though it probably should be the very last resort. Some say that there are too many variables to use it safely while others were “a bit more gung-ho” as far as canceling the jobs is concerned. But everyone seems to agree that deleting records using SQL is not a good idea.

To determine what script T-SQL should be used to cancel the job, run SQL Profiler and cancel a single job while capturing the trace. This trace should give you a solid starting point for the script.

Again, use bulk deletion job to delete the canceled jobs.

Joel: Using bulk delete to kill asynchronous jobs is like a science fiction story where they build a robot that gets out of hand, so they have to build another robot to kill the first robot. Wonder how Asimov’s three laws apply?

Share on FacebookTweet about this on TwitterShare on Google+

Tip #986: Specify language for Online Management API

As soon as the word got out that I managed to use Online Management API to create backups in Azure, Marius Agur Pedersen reached out to me about the support case with Microsoft that he had in the limbo for a number of weeks.

Basically, Marius was able to retrieve instances but any attempt to backup was failing with the error 500. My code, however, was working just fine. After couple hours of joint efforts (plus whopping 50+ days for Marius), success! Long story short, accept-language header is a must have for some operations but not the others.

After a bit more digging, it turned out to be a well-hidden case of RTFM. As documented in getting started (highlight mine):

Standard headers

The Online Management API has following standard request and response headers.

Request headers

Header Type Description
Accept-Language “en,” “es,” etc. Specifies the preferred language for the response. Services are not required to support this, but if a service supports localization it MUST do so through the Accept-Language header.
Authorization String Authorization header for the request. See Authenticate to use the Online Management API

All problems went away after this line of code:

   .Add(new StringWithQualityHeaderValue("en-US"));

(While you’re at it, check out his admin api project. It’s early days but looks promising).

In Marius defence:

  • How do we tell if a service supports localization? What is so locale-specific about the backup, for example?!
  • Is that such a big deal to assume the language of the instance or imply en-US and issue a warning but without failing the entire operation?
  • Would it kill to return something better than a non-descriptive error 500?

The reason it worked for me was that I used a wrapper class that automatically inserted that header. To confusing everyone even further, for quick testing I was using Postman extension while Marius was using the desktop version. Former would add the language header automatically just for giggles.

Current advice? Always add accept-language header – no harm done if it’s not needed.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #985: Use Azure for permanent instance backups

In the tip 759 we suggested keeping a sandbox instance as your persistent backup because Dynamics 365 Management Center provides no control over the backup lifetime. Later, we were excited about introduction of the Online Management API and, as it turned out, all for the right reasons.

Using the API, administrators can now backup a Dynamics 365 instance into Azure blob storage using Backup Instance request. The expected request data are json, you will need an Azure account and typical request would look like:

POST /api/v1/InstanceBackups HTTP/1.1
Host: admin.services.crm.dynamics.com
Authorization: Bearer token-here
Content-Type: application/json
Cache-Control: no-cache
 "Label" : "Blob it is!",
 "IsAzureBackup" : true,
 "AzureStorageInformation" : {
   "ContainerName": "foo",
   "StorageAccountName": "bar",
   "StorageAccountKey": "baz"

After backup completes, it is properly recognized by the admin center:

Azure backup

Blob storage in Azure also gives us an insight how backups are organized:

Backup blob

As you can see, full backup of an [almost] empty instance takes just over 850Mb, followed by transaction log backups every 15 minutes. And no, I wouldn’t waste time trying to restore that on premises.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #984: App confusion

Following the word “insights,” the most overused word in Dynamics 365 is “app.” App is used in multiple contexts, and can create confusion when discussing Dynamics 365. I find it helpful to use the following terminology to add clarity when discussing Dynamics 365 apps.

  • Mobile app: The official Dynamics 365 mobile app, available for iOS, Android, and Windows.
  • App for Outlook: The Outlook integration for Dynamics 365, not to be confused with Dynamics 365 for Outlook, the now deprecated legacy Outlook client.
  • Dynamics 365 App Modules: modular business applications that provide access to a subset of Dynamics 365 Customer Engagement. Built in the Dynamics 365 App Designer, app modules break the monolithic application into smaller business apps that address specific line of business scenarios, and only include the dashboards, entities, views, and forms needed by users for those scenarios.
  • PowerApps: Mobile applications built in Microsoft PowerApps that can include Dynamics 365 data and processes, as well as data from other Microsoft and third party platforms.
  • There are also apps for field service, project service, and third party mobile apps like Resco.

Where it gets confusing

If I go to a Dynamics 365 user group meeting and ask if anybody uses the Dynamics 365 app, any user of any of the above “apps” might raise their hand. This is why it is important to be precise.

Consider that in version 9, business apps built with Dynamics 365 App Designer will be recognized by the Dynamics 365 mobile app. If you are leading CRM training (and want users to understand what you are saying), saying “CRM mobile app recognizes Dynamics 365 apps” will only confuse your students. Instead, you will want to say something like “The mobile app for Dynamics 365 allows users to select a specific app module when configuring the mobile app, and users can switch to other business app modules if they work with multiple app modules.”

Hopefully this tip has provided some insight into Dynamics 365 apps.

Speaking of apps, have you checked out our new CRM Audio app for iOS? Get notified when there are new episodes, download and mark your favorites, and even an alarm to wake you up to Dynamics 365 podcasts.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #983: Why Excel templates are better than dynamic spreadsheets

With the deprecation of the Outlook Client, some users are wondering about dynamic spreadsheets. If you are moving to the cloud or have IFD on premises, you need to run Dynamics 365 for Outlook (the Outlook client, not the new app) to use dynamic spreadsheets.

I’ve had this conversation with multiple clients, and while they have been initially disappointed that they won’t be able to use dynamic spreadsheets after they go to the new Outlook App, once they get their hands on Excel templates, they aren’t so sad anymore. Some say they are actually a better solution.

The big value of Dynamic spreadsheets is that you can export data to Excel from CRM with an embedded query. Every time you open the spreadsheet, you can refresh the data from CRM, without having to log in to CRM.

That can be a nice timesaver; however, the thing about people who are Excel junkies is they typically don’t want to just get the data in Excel–they want to do something with it. Add formulas, pivot tables, charts, calculations. And while you could add these items to a dynamic spreadsheet on a separate tab, it was never a truly supported feature, and you definitely couldn’t change the table in a supported manner. If you got your dynamic spreadsheet extended with charts and pivot tables and then you needed the same spreadsheet with a different query, you would need to re-export a second copy of the spreadsheet from a different view.

Enter Excel templates.

First thing to note, Excel templates are NOT dynamic. They don’t refresh each time you open them.

But what they do is give you the ability to export data from Dynamics 365, modify the export table (add columns, calculations, totals, etc) and pivot tables, charts, and anything else your little Excel loving heart desires. Then you can upload that template back into Dynamics 365 and run it from any view of the selected entity in Dynamics 365. Even if the view doesn’t include all of the fields in your template, it will work with the view.

So as a trade-off for giving up the dynamic query, you get the ability to more extensively modify the spreadsheet, including the table, you can run it with any view from the entity, and (IMO) best of all, you can run it from mobile.

Fair trade I would say.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #982: Before you fire your administrator

Please be careful when disabling System Administrators in Dynamics 365. They are likely to own things, such as workflows. Before disabling System Admin accounts, check to see if there are any organization scope workflows that they own. If there are, reassign the workflows to another System Admin user account. If you don’t, these processes won’t run.

Better idea — make all of your workflows owned by a system account so this doesn’t happen in the first place.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #981: Sharing knowledge with Australians

For years Dynamics CRM/365 has been ignoring language variations like Swedish (Finland), English (Irish), and Spanish (Traditional Sort). People working on portals and new knowledge management features thought otherwise and now you can do either using local language variety.

Neil “New Release – New Country” Benson always tries to play nice with the locals, this time of the year it’s in Australia. This is his story.

Our Australian knowledge managers recently started changing the language of their knowledge articles from the default ‘English – United States’ to ‘English – Australian’.
Setting KB language
Later we discovered that their articles were not appearing in the KB Records search widget on the case form even though the Dynamics 365 user’s language was still ‘English’.

Thanks to Dileep Singh at Microsoft for pointing out that system admins need to adjust the ‘Set Default Language’ option in the Knowledge Base Search tab of the social pane on the case form. To resolve our issue, we changed the default language to ‘English – Australia’.
Set search language filter
Knowledge article documentation can be a little tricky to find because most internet searches will return results about the deprecated knowledge articles instead of the new knowledge articles. Thanks again to Dileep for stepping in: https://technet.microsoft.com/en-us/library/dn946902.aspx.

If you’re planning a multi-language knowledge management solution or your users prefer to specify one of the many language variants supported in the new knowledge articles feature, remember to adjust your case form’s knowledge base search properties accordingly.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #980: Unified User Interface Myths

In Dynamics 365 v. 9, Microsoft is releasing a whole new interface called the Unified User Interface (UUI). This doesn’t mean that the Dynamics 365 Enterprise interface is going away yet, but it does mean that for certain types of users and applications, the interface is changing. Other bloggers have done a better job than I could explaining the “why” behind the UUI. In this post, I want to clear up some misconceptions about what UUI is and who will get it. Read the myths below (in bold) followed by the reality.

Myth #1 — It’s Business Edition. Dynamics 365 v.9 also introduces a new license SKU called Business Edition. While the UUI will be the interface of Business Edition, it is not limited to only business edition. But if you meet the licensing restrictions of Business Edition and only need the functionality available in the UUI, Business Edition may be a fit for you. UUI is not the Business Edition, but it is the only interface available to Business Edition users.

Myth #2 — Enterprise Edition users don’t get it in v.9. Enterprise Edition customers have a choice. They can use the traditional web user interface (which has received significant updates so the forms and views look and feel a lot like UUI). But they also can use the new UUI, and using Dynamics 365 App Designer, you can give Enterprise users an app that is Unified experience or traditional web. Any functionality like campaigns and goals that is not yet available for UUI will not be available from the app.

Myth #3 — It’s more limited than the traditional user interface. This is true or false, depending on your perspective. You can’t configure, create workflows, or run advanced find from the Unified User Interface. However, there are a number of new features that are in UUI that are not in the traditional interface. Some examples:

  • Snazzy new sitemap that doesn’t take up the whole screen.

  • Entity level dashboards (like an account dashboard filtered by account view)

  • Visual filters on dashboards visually summarizing lists

  • Real tabs on forms!

  • Timeline view

  • New features on mobile: By unifying the web and mobile experiences, mobile gets a bunch of new features previously only available in the web. Things like email a link, alphabet selector on views, full sitemap, multiple forms per entity, and more.
  • Consistency: For users of the unified user interface, the interface will be the same between web and mobile experiences. This means that training will be significantly easier, as you won’t have to say “if you are in mobile…” Also, configuration testing is dramatically simplified, as you can test in web on the same interface that mobile users will see.


The Unified User Interface represents the future of user interface in Dynamics 365. While System Administrators and some power users will not want to use it day-to-day (yet), for many users, the UUI will provide a rich, consistent experience. My recommendation when deploying Dynamics 365 is to look at the capabilities that users need. If they fit within the limitations of the UUI, consider deploying a Unified Interface app. If users cannot completely get by in the UUI experience, you will still want to familiarize yourself with it, and since the interface for mobile and Outlook app is UUI, you will still want to configure the UUI experience for mobile and Outlook.

George gets the last word

UUI represents a major architectural shift. Unlike previous clients who used the same definitions to deliver different experience on web vs mobile, UUI uses single rendering engine to deliver the same experience. The other important architectural bit is CCF. Once it’s made available, it will reinvigorate ISV market and will spell the end of “all CRM forms look the same” era. Looking forward for 37 editable grids from Infotec’R’Us companies.

Share on FacebookTweet about this on TwitterShare on Google+