Sonoma Partners Microsoft CRM and Salesforce Blog

No Code Needed: Requiring Fields when Closing an Opportunity in D365

A recent requirement came up on a project to require specific fields when marking an Opportunity as Won.  The reasoning for this request is that you want your sales team to be able to quickly enter their opportunities without having to fill out a bunch of required fields.  However, you may also have specific fields that are needed upon closing the opportunity as Won, that you encourage your sales team to capture along the sales process.

At first, I thought that you could accomplish this by requiring fields in the last stage of the Business Process Flow.  Nope, that’s not the case.  Even if there are required fields in the BPF at any stage, users can go ahead and close the Opportunity as Won or Lost at any point.

Consider the Opportunity below.  Notice how Contact, Est. Close Date, Est. Revenue, and Budget Amount aren’t required.


However, you want this data captured before someone can mark the Opportunity as won.  You could invest in a developer and have them write a plugin to prevent save, but that would be costly.

The easy “no code” option is to use a Synchronous Workflow.  Head over the Settings –> Processes to create your new workflow.  Make sure to uncheck “Run this workflow in the background (recommended)” in order to make the workflow synchronous (or in other words, the Opportunity form won’t refresh until the workflow has run and completed).  This is key, because we’ll add a step in the workflow that will prevent the save, if our fields aren’t populated.


Your workflow would need to run After the “Record status changes”, and it will only need three steps:

  1. A Check Condition that will continue if the Status is set to Won.
  2. A Check Condition that will look and validate that all required fields have data.
  3. A step to stop the workflow as “Canceled” with an error message, if one of the required fields is missing data.

The overall workflow would look something like the following, along with the individual steps:





Now, when someone attempts to close an Opportunity as Won with those four fields above not populated, they’ll receive an error message as shown below.  All of this was done without a single line of code, and should the business requirements change and warrant future modifications, you can easily hop back into the workflow and make those changes quickly.


If you’re looking to leverage Dynamics 365 to better monitor, track, and move through Opportunities, let us know! We’d be happy to discuss your existing environment and how we might be able to help.

Contact Us

Topics: Microsoft Dynamics 365 Microsoft Dynamics CRM Microsoft Dynamics CRM Online

Dynamics 365: Speeding up API Access with the Async Service

Today's blog post was written by Angel Shishkov, Development Principal at Sonoma Partners.

When we need to do a recurring custom calculation or integration in CRM, we usually build a console app, or Azure Job. These solutions run on a schedule and use the CRM SDK along with a service account to connect to CRM and perform the necessary retrieves, creates, and updates. Since these are external to CRM, there is some performance overhead when data is sent over the internet to the CRM server.

It is generally much more efficient to interact with CRM on the server-side; through plugins, workflow activities, custom actions, etc.

I was wondering how much more efficient and how feasible this would be, so read on to find out.

Setting up a test scenario

I specifically wanted to test how the CRM Async Service will perform as a substitute to a recurring calculation job. The theory being that the Async Service physically lives very close to the CRM database (in the same data center, most likely) and will therefore have much lower overhead when transferring data. On top of that, the Async Service does various caching and other optimizations, that allow it to connect to the database without going through the normal authentication steps that a console app would. So, I wanted to test a bulk update scenario using a console app, versus the same scenario using the Async Service, and see how much of a difference in performance there was. If you’re not interested in the technical details, scroll down to the Results section.

The test scenario I chose was a mock case of reading data and creating records. The requirement would be to read some data from CRM, with a FetchXML query, then create a small record with the results of that query. We would then do this several thousand times. This roughly simulates a bulk calculation scenario (like a custom calculated field that is refreshed daily) or an integration scenario (reading and/or writing to CRM).

For the query, I used a sum aggregation of the extendedamount of all the salesorderdetails in the system. Basically – get the total amount of all the Orders in CRM.

For the record creation, I used a custom entity with two fields; an Index field to hold the index number of the record and a Total field to hold the calculated total amount. The Index was just incremental numbers, starting at zero and the Total amount was always the same value repeatedly retrieved by the query above.

Implementing the console app

The console app was a basic application using the CRM SDK to create a connection to the server and perform the queries and creates. It loops 20,000 times and each time it runs the aggregate query, gets the resulting sum, and creates a new_loadtest record with that sum as the total and an incremental number as the Index. I decided to use ExecuteMultipleRequest in batches of 100, since this approach is standard for these kinds of apps and it would be an unfair comparison not to use it. Here is the loop code:

Implementing the async job

The async service implementation was more interesting. The idea here was to leverage the CRM Async Service to do the work, so we would need an async plugin. CRM Online has a 2min timeout on server-side custom code and this includes plugins, workflow activities, etc. On top of that, CRM has a mechanism to detect and prevent infinite loops on the server side where a component could trigger itself indefinitely, like a plugin that fires on the creation of a record, which triggers itself again by creating a new instance of that record.

Based on the above, it becomes difficult to write an async plugin that runs for more than 2min, so the work would need to be broken up into chunks. Since the test case was very simple - run the same fetch query, create a record with an incremental index – I opted for a simple approach as well. I created a new_asynctrigger entity with a new_startindex and new_endindex field. An async plugin would fire when a new_asynctrigger record is created and process the indexes between start and end in one chunk, the same way the console app above did – run the same fetch query, create a record with an incremental index. A separate console app would be needed to create these new_asynctrigger records with the correct start and end index, so that the Async service can be triggered. This is definitely an overhead, compared to the pure console app approach. Furthermore, we need to keep the chunks small enough that each can be processed in under 2min, plus a generous buffer for safety. In this case I used a chunk size of 1000.

Note that the plugin does not use ExecuteMultiple, like the console app does. Since the Async service executes multiple jobs in parallel, we could trigger the CRM ExecuteMultiple throttling (2 concurrent threads max) and cause our Async jobs to error out.

Here is a snippet of how the console app creates new_asynctriggers.

And here is the async plugin code that processes each chunk.


To summarize, we have a console app going up against the Async Service in the slightly unfair race to query CRM and create records. It’s like one of those timed cooking challenges, except one cook is in the kitchen and the other one starts five blocks away.

Let’s summarize the pros and cons, only as related to speed and efficiency, of the two approaches.

Console App


  • Needs to only connect to CRM one time, and can reuse that same connection.
  • Can create all the records in one loop, does not incur overhead to chunk records.
  • Can use ExecuteMultiple.


  • Communicates with CRM over the internet, which involves network latency as well as the performance overhead of accessing the external API.
  • Cannot run more than 2 threads in parallel. By default, CRM Online allows 2 concurrent ExecuteMultiple requests. In this test, I did not implement any concurrency.

Async Service


  • Has an internal connection to CRM that does not require the usual OAuth handshake.
  • Presumably communicates with CRM over an internal network with much lower latency and higher bandwidth.


  • Requires breaking up records into chunks, as it can only process 2min at a time.
  • Requires overhead of creating records in CRM to trigger the async plugins, because of CRM’s infinite loop detection.
  • Does not use ExecuteMultiple, creates records one at a time.


As I stated in the summary, this test strongly favors the Async service. All of the “work” is accessing CRM, not external systems or databases and the requests to CRM are small and numerous, which is bad for the overhead incurred by a console app. Either way, I was a bit surprised by the results.

Console App

On average, 20k iterations completed in 74min.

Async Service

On average, 20k iterations completed in 52sec.

That seems like a very large difference. The two main inequalities I think, are the level of parallelism and the speed of CRM access. The console app runs one thread, while the async approach quickly creates 20 jobs (20k records / 1k chunk size) that are queued to execute together. I can’t say for sure how many of those run in parallel inside the Async service, but likely quite a few, if not all of them. The rest can be attributed to much faster access to CRM from the Async service.

Overall, I wouldn’t recommend using the CRM Async service to process large migration data, as that is not its function. For smaller integrations or recurring calculations, it seems to be clearly the faster choice, but because it is not fully under our control, I would still tend towards the console app/Azure job approach, unless there is a specific performance limitation that needs to be addressed.

Thanks for reading!

Topics: Microsoft Dynamics 365

Unable to Login to Dynamics using the SDK?

Today's blog post was written by William "Dibbs" Dibbern, Development Principal at Sonoma Partners.

We recently noticed that we were unable to login to a couple Dynamics 365 Online instances using any of our WPF or Powershell-based tooling that leverages the Microsoft.Xrm.Tooling.Connector NuGet package . We received the error "Unable to Login", which if you've used the Xrm Tooling Connector lib before, you could mean anything. Since nothing had changed recently, we tried it in LINQPad and it worked, mysteriously. You know what that means: let the debugging games begin!

If you'd like to follow our process for solving this then keep reading, otherwise if you just want to know the resolution, skip on down to the end.


After inspecting the network traffic during connection using Fiddler, we noticed the failure was occurring during the CONNECT request to the API, and it was failing multiple times. Upon inspecting each request we found that our code was sending out a CONNECT for TLSv1 then failing back to try SSLv3 as you can see in the screenshot below.


Neither TLSv1 nor SSLv3 are supported online now according to this bulletin from the D365 blog: Updates coming to Dynamics 365 Customer Engagement connection securityThat blog post notes two options to resolve any potential issues stemming from the upgraded security, both of which have their pitfalls:

  1. Update your code to leverage .NET 4.6.2+: The update in .NET 4.6 that this alludes to is to try more secure protocols before trying older, less secure, protocols (TLSv1.2 would be tried before TLSv1.1). However, our code was already on .NET 4.6.2 so this suggestion was ultimately unhelpful for us.
  2. Update your registry settings: Potentially a good resolution for some, but we prefer to make as few changes to systems we deploy our apps to as possible, and we were sure there had to be another way around this that we could control from code.

Based on those hurdles, we went back to the drawing board. After a few quick searches, we stumbled upon a couple of very helpful StackOverflow posts.

This question .Net Framework 4.6.1 not defaulting to TLS 1.2 pretty much cut straight to the heart of our predicament. We're on .NET 4.6+, why is it still not working? The most upvoted answer gives the reason. .NET 4.6.2 doesn't have a default set of enabled security protocols it seems, so the default could be different per environment our code could run on.

This led us to making sure that the ServicePointManager.SecurityProtocol setting was set such that TLSv1.2 was in the list of available protocol options, regardless of any default environment settings. We found several posts suggesting we set the value explicitly such that ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;. However, the other StackOverflow post we found had a better answer.


In the end, we agreed with the most upvoted answer in the last StackOverflow post we found which recommended only enabling the protocols we actually care about instead of explicitly restricting ourselves to TLSv1.2. This ensures the least potential side effects. System defaults are minimally modified for our execution context, and any future protocols that are added would still be available to use (in theory). As our two troublesome environments in which we originally experience the error had only TLSv1.1 and TLSv1.2 left off of the defaults, we decided to turn them both on. This combined with the update to .NET 4.6.2 ensures that TLSv1.2 is tried before any less secure protocols, but that all are available if needed.

How this is implemented is by adjusting the ServicePointManager.SecurityProtocol setting as needed. As described, we wanted to turn on TLSv1.1 and v1.2, so we added the below line once per application. We inserted it generally right before we initialize our CrmServiceClient object, unless of course we're instantiating multiple. The point is, you only need to do this once if no other code in your execution context is changing this value.

ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

The same principal can be applied in PowerShell, as needed.

Final Thoughts

A couple of fellow devs noted during our research that this doesn't seem to be a problem with Console Applications, and we also noted at the start this wasn't an issue for LINQPad scripts. What's up with that, right? For whatever reason, in those environments, TLS 1.2 is in fact included in the list of available security protocols by default. That said, the point here is that it isn't always enabled by default. So if you cannot be sure where your code is being run, the safest bet is to turn on the protocols you know you need before trying to use them.

Topics: Microsoft Dynamics 365

Dynamic Forms (Community Edition): Now Available in AppSource

Today's blog post was co-authored by Ross Talbot, Development Principal at Sonoma Partners.

We are excited to have released our popular Dynamic Forms (Community Edition) to Microsoft's Dynamics 365 AppSource!


As a reminder, Dynamic Forms is a useful tool that bridges a gap between the evolving Dynamics Business Rules and custom form JavaScript by giving customizers a way to configure complex rules.

In addition to being generally available on AppSource, we have also updated the solution with the following enhancements:

  • Dynamic Forms now supports Customer lookup types
  • Some minor cosmetic improvements
  • Resolved issues with rules filtering values on an option set
  • Resolved issues with rule behavior when deployed to mobile devices

If you are new to Dynamic Forms, please read the article from our colleague, Justin, about the differences between Dynamic Forms and Dynamics 365 Business Rules. Also, a walkthrough can be found on our website here or a video is embedded on the download page on our website. Here you will find information on creating both simple and complex rules, as well as a list of features so you can see what options are available to you.

Still use Dynamics CRM 2016 on premise? Don't worry, we have you covered. Simply download the 2016 version and download from our website and enjoy!

Topics: ISV for CRM Microsoft Dynamics 365

D365 V9 - A Tale of Two Interfaces

Today's blog post was written by Mike Dearing, Development Principal at Sonoma Partners.

Since its release in early October, we’ve been busy digging into all that Dynamics 9.0 update has to offer. Aaand it’s a lot. Luckily there have been a lot of great posts in the Dynamics community about what to expect with some of the new functionality. Rather than rehash all of that, this post will be a bit different.

In this post, I'll share my experience with the two new interfaces available: Web Refresh and Unified Client Interface (UCI).

Let’s first start with the Web Refresh UI, since it is the most familiar and what you’ll see the moment you upgrade or create a new sandbox.

Web Refresh UI 

Click the image to expand.

The first thing you’ll probably notice is that IT’S HUGE, especially if you haven’t been lucky enough to procure a device with at least a 1080p resolution by now. You’ll also notice that theming has changed a bit, and, if you open the theme itself, you’ll see that there are new options at your disposal to adjust these stylistic changes.

Click the image to expand.

If you drill into a record’s form, you’ll also see field labels that wrap again (configurable in settings, if you liked the fade away better), dashed lines that fill a section’s width, and generally just less white space overall. The refreshed UI was built to take advantage of the white space to make your form look fuller and for sections to stand out a bit more. At first I wasn’t a huge fan, but it has grown on me when taking a not-so-nostalgic trip back to 8.2.

Aesthetics aside, there isn’t much difference behind the scenes with the Web Refresh UI. When upgrading an existing organization, I’d expect things to work as is, barring any of the usual upgrade kinks or unsupported code. If you have any custom UIs, you’ll want to spend a bit of time on them to update their fonts and such, but otherwise your supported Javascript, plugins, and other customizations should behave as expected. There are several deprecation notices that came along with the 9.0 release that you’ll want to familiarize yourself with, but that is a bit tangential for this post and not particular to either of the two new interfaces.

Unified Client Interface (UCI)

Click the image to expand.

UCI, on the other hand, is quite a bit different than the Web Refresh UI or prior UIs. If you thought the Web Refresh UI was huge, well UCI is EVEN HUGER. The sitemap is now on the left-hand side of the page, with the top simply behaving more as breadcrumbs to backtrack your navigation. You’ll also need to specify UCI icons for any of your custom entities or ribbon buttons to make sure they don’t get set to the dreaded default puzzle piece of UCI (Blake Scarlavai wrote a helpful post to show how to do this here.).

Click the image to expand.

The overall design objective of trying to make forms a bit fuller is seen here as well, but accomplished in a different manner. Forms segment sections by adding some of your theming to the top of each and an off-white background to contrast instead of using the long dashed line. You’ll also notice that we are now back to a tabbed form layout, after being subjected to years of vertical scrolling. Form headers are also quite a bit taller, to show off the latest in SUPER LARGE FONT TECHNOLOGY. All kidding aside though, UCI is beautiful. It also lends itself nicely to native mobile, which requires UCI now.

However, upgrading to UCI isn’t quite as simple as upgrading to the Web Refresh UI. The first thing to note, is that UCI is currently only supported for mobile and tablets, not your desktop browser experiences. This doesn’t mean that you can’t use browsers to access it, just that it is under a ‘user beware’ sort of situation at the moment. Fortunately, I’ve heard from Microsoft that browser support could come as soon as the first update rollup (9.0.1.x), possibly around the end of January, but as with all dates these are subject to change.

Despite not currently being supported yet, I have spent the majority of my time in browser mode (i.e., not via a tablet or mobile app). It is definitely buggy, as one may expect for something so new. There are also several big features, entities, and admin-level areas missing entirely (advanced find, campaigns, marketing lists, audit history, workflows, etc.). The good news is that Microsoft has been rolling out new minor builds each weekend to address these issues, already resolving 10 or so of the ones that we’ve reported, including all of the critical ones we’ve stumbled across.


The remaining list of issues range from high priority to low aesthetic ones for what we’ve identified so far.

Another thing to note is that if your environment is heavily customized, especially in terms of custom javascript (or Silverlight, which is officially deprecated now by the way), be prepared for a bit of a rework. Xrm.Page deprecation notices aside, if you haven’t properly been referencing the correct Xrm.Page context from dialogs or iframes, you’ll start to receive errors. These are generally as simple as replacing an Xrm.Page with a parent.Xrm.Page reference, but still something that popped up on occasion for us.

With the tabbed UI redesign, you’ll need to defer any Javascript accessing web resources on those various tabs until those tabs have loaded. I’ve also run into a few issues with custom ribbon buttons no longer appearing, which forced me to revise my display rules to leverage selection rules more frequently. Also in regard to ribbons, for any native buttons that I had overridden from previous versions, I updated my snapshotted javascript actions to their counterpart in an uncustomized 9.0 ribbon where appropriate – pretty common for any upgrade, but I had missed a few buttons which still worked fine in the web refresh UI but weren’t so forgiving in UCI.

Although UCI is by far the winner when it comes to looks, and seems to be the way of the future for Dynamics, the Web Refresh UI is a nice safe stop gap for now. Your users won’t notice too large of a difference with the web refresh, and you won’t be tasked with as many immediate code overhauls. Unless you’ll be leveraging native mobile capabilities and therefore forced to jump straight to UCI, I’d suggest starting with the Web Refresh UI and slowly dipping your toes into the UCI waters, while Microsoft continues to fix bugs and roll out new entity and feature support.

Topics: Microsoft Dynamics 365

Multi-Tenant Server to Server Auth and Granting Access

Today's blog post was written by Matt Dearing, Principal Developer at Sonoma Partners.

Server to Server (S2S) authentication has been a very useful addition to Dynamics CRM online, especially in multi-tenant scenarios. S2S authentication allows an external application to authenticate to Dynamics CRM without consuming a user license and without referencing a user's password. The application leverages the Azure app registration's application id and private key (which do not differ across tenants even in multi-tenant scenarios) to authenticate to any Dynamics CRM Online organization that is in a tenant who has granted it access.

When an Azure AD app registration is configured as multi-tenant, an Azure AD admin from the target tenant must grant access to the app.

If the app is a public facing web application (like an MVC application hosted in Azure), it is very easy to configure multi-tenant authentication and have a place for the admin to browse and grant access, but what if the application doesn't have a public web based UI (e.g. on premises app, Azure function, Azure web job, etc.)? The following URL can be used for target admins to grant access to the app:<CLIENTID>&response_mode=form_post&response_type=code+id_token&scope=openid+profile&prompt=admin_consent

In the URL, replace <CLIENTID> with the Azure AD app registration's application id. This will prompt the target admin to grant access to the app in their tenant. Once they grant access, the Dynamics CRM Application User can be setup in their organization. Then the app can start to authenticate to the target org and make API calls against it. For an ISV this URL could be added as a link in their Dynamics CRM solution's configuration page or added as a link in AppSource that they point their users to when installing the solution. The ISV could also setup a single page that redirects to this link for the sole purpose of granting access, allowing more control if the URL ever changes.


S2S Authentication has made it possible to build multi-tenant apps outside of Dynamics CRM that can connect without a unique username and password per organization. It's great to be able to use this authentication scheme even from non-public, web-facing applications.


Questions? Let us know!

Topics: Microsoft Dynamics 365

More Than One Way to Skin a Dupe

Today's blog post was written by Jeff Meister, Principal Consultant at Sonoma Partners.

Recently, a colleague of mine was looking for potential solutions for an issue his customer was facing within Dynamics 365. These types of questions are a favorite part of my job, as they showcase our ability to creatively problem solve, allows us to collaborate and discuss options as a team, and demonstrates the flexibility of the solutions we work with.

Typically, within any CRM platform, there is more than one way to solve a problem.

Picture1And based on your area of expertise, you might come at issues from many different angles. Below is a recap of the issue at hand, as well as the suggested solutions that surfaced from the team.

My Client is uploading Accounts to D365 using native imports. Upon import, 50 records are failing due to being flagged as duplicates. Is there a way to quickly find out which existing records are the duplicates?

Seems like a simple question, right? Unfortunately, there is no way to do this natively in D365, hence the ask for proposed solutions.

Here are the various responses from the different disciplines within Sonoma...

Data Integration Developer Response:

  1. Pull the error file from the D365 import.
  2. Export a list of all Account records.
  3. Create a PowerBI model to do the comparison.

Developer Response:

  1. Pull the error file from the D365 import.
  2. Export a list of Account Records.
  3. Bring both files into Excel.
  4. Execute a Vlookup to determine the overlap between the two files.

The Simpleton Response (my response):

  1. Run a duplicate detection on Account to ensure there are no existing dupes.
  2. Run the D365 import, leaving 'Allow Duplicates' set to Yes.
  3. Run data import (creating the 50 dupes).
  4. Run a Duplicate Detection job to identify your dupes and merge appropriately.

There is a long list of Pros and Cons with each of the above options, and depending on your situation (skillset, timeline, budget, resources, User skill-set, etc.), one will likely be more attractive than the rest. So remember, as you face common challenges within your deployment, think creatively, collaboratively and understand that there is more than one way to solve most problems.

Do you have a CRM problem that needs solving? Let us know.

Topics: Microsoft Dynamics 365

Get Connected: LinkedIn Sales Navigator meets Dynamics 365

Today’s blog post was written by Kayla Silverstein, Marketing Specialist at Sonoma Partners

LinkedIn Sales Navigator is the premiere business tool for targeting buyers, tracking lead changes, and engaging with prospective customers. Many organizations leverage this solution to be smarter sellers and better target their prospecting efforts.

If your sales team is already using this tool, you don’t need me to remind you that LinkedIn Sales Navigator makes a tremendous difference to your organization. If you’d like more information, you can learn more here.

Microsoft continues to improve and build upon the Dynamics 365 platform, and integrating with LinkedIn Sales Navigator is a critical next step towards further empowering organizations to connect and build relationships.

Within Dynamics 365, you can embed and view LinkedIn profiles in-context with Contact records in CRM.

The widget is broken into the following categories, and covers these actions:

  • Icebreakers: shows the Contact’s highlights and activities
  • Get introduced: shows the mutual connections and allows for an introduction to the Contact from within the widget
  • Related leads: shows the potential Leads similar to the Contact record you’re currently viewing
  • Account connections: surfaces the best LinkedIn connections at your prospect’s company
  • Recommended lead: shows the recommended potential Leads of this company
  • Account news: covers any recent news of the company
Click the image to expand.

With the new Dynamics 365 to LinkedIn Sales Navigator connection, you can automatically synchronize Dynamics Accounts and Contacts to LinkedIn as saved Leads and Accounts. Dynamic Leads are synchronized as “suggested Leads.” All Leads are indicated as synchronized between systems with a Dynamics 365 badge.


You can also track activities within Dynamics 365 as well by clicking “Sync to CRM” on your comments, LinkedIn messages, and notes.


Click the image to expand.

If you’re looking to get more out of your existing Dynamics 365 platform by taking advantage of this new integration, let us know! We’d be happy to discuss what might be possible to help your sellers build greater relationships with their prospects.

Topics: Microsoft Dynamics 365

Using Q & A to Create Reports in Power BI

Today's blog post was written by Brendan Landers, VP of Consulting at Sonoma Partners.

Power BI Q&A enables users to ask natural language questions and get answers in the form of visuals or reports automatically created with the data that best answers their question.  Q & A has been available in Power BI for some time now, but it was only available for datasets with visualizations that had been pinned to dashboards in the Power BI Service.  The end user could leverage Q & A within those dashboards, but someone had to design the dataset and visualizations with Q & A in mind for it to be useful.  This video published by the Power BI team showcases how the functionality works through Dashboards.

With the December release of Power BI, you can now use Q & A to create your reports.

In this blog post, I will show you how to do so in the latest version of the Power BI Desktop.

To illustrate, I have a simple excel file with four tabs which I am using as the data set.  The tabs are:

  • Customer – a sample customer list
  • Opportunities – a sample list of opportunities
  • Orders – a sample list of orders
  • Users – a sample list of AEs

We could easily connect this to Dynamics or Salesforce to get those objects for your data set, but I am using excel for the sake of simplicity.  Additionally, I have setup simple relationships between the objects using the autodetect feature. 

Brelanders 1

Once I have my data setup, I can start using Q & A to create reports. 

*Please note Q&A for creation is a Preview feature, and you may need to enable it through options (Click on Start > Options and Settings > Options > Preview Features).

Next, to use the new feature you will first click the Ask a Question button in the ribbon. 

Brelanders 3

Once you do so, you will see a blank visualization appear with the Q & A box available for input.

Brelanders 4

Now we are ready to build a chart.  First, let’s look at the Weighted Revenue by Year for each of our AEs.  The fields I need in my data set for this report are the following:

  • Weighted Revenue (from Opportunity)
  • Expected Close Date (from Opportunity)
  • AE (from User)

In the Q & A input box, I will start typing.  I first start with Weighted Revenue.  As soon as I begin typing you will notice intellisense auto-showing the fields.  In this case, by just typing the letter "W" I can see the field I need.

Brelanders 5

I select Weighted Revenue, and Power BI provides a Card visualization with the sum of weighted revenue in my Opportunity table.  Pretty cool.  Next, I want to see the data by AE.  To do so, I type the word "by," the field I need, and voila!  After that selection, Power BI shows me a bar chart of Weighted Revenue by AE.  Even cooler.

Brelanders 6

While that is interesting, I’d like to take it a step further to make this more meaningful.  To do so, I am going to add Expected Close Date into the mix to see Weighted Revenue by AE by Year.  I’m guessing at this point you get how I might do so, but for those who jumped to the end, I will add the words "By Expected Close Date" to my Q&A.  As I type in Expected Close Date, I notice that Power BI starts to show off a bit and, since it’s a date field, it serves me some options from a date hierarchy. 

Brelanders 7

I am going to select the Expected Close Year option which will show the data by rep by year.

Brelanders 8

And we are done!  In literally seconds any user can create meaningful charts with simply typing what they want.  The coolest.

If you have questions about this post or anything Power BI related, feel free to reach out.

Topics: Analytics Microsoft Dynamics 365

Dynamics 365 Defect: Cannot Create Emails in Unified Interface

Today's blog post was written by Angel Shishkov, Principal Developer at Sonoma Partners.

Version 9 of Dynamics 365 is out and available for new customers. One of the new features released is a completely new interface called the “Unified Interface” with the goal of standardizing the look and feel between different clients – web, phone, tablet, etc. This interface is brand new and obviously will have some issues to work through, however there is a particularly serious problem on Mobile clients.

One of the most obvious (and strange) problems in the Unified Interface is that it does not allow the user to create emails in CRM. The email activity is conspicuously missing from the quick create plus button in the top nav bar, the Activities ribbon, and the new Notes Pane (previous Activities Pane). Just to make sure that we hadn’t somehow hidden or lost the email activity create buttons, I constructed a URL that would normally open a new email form. A blank page opens with this message.


It looks like the email activity has been deliberately made read-only in the Unified Interface. We opened a support case with Microsoft, and they confirmed this is a defect and will be scheduled for a fix in the future. As of now, there is no ETA on the fix.

Script Errors

Another common issue we have seen in the Unified Interface is a lot of script errors, especially when a custom script web resource is attached to the form. The errors usually come from native script libraries, such as uclient/scripts/app.js, however some errors come directly from the XRM methods as well, such as Xrm.WebApi.retrieveRecord. These are reproducible from multiple clients – browser, phone and outlook, so it seems to be a problem specific to the Unified Interface. Microsoft support has noted that the product team is working through those as they find them.

Mobile Clients are forced into Unified Interface in v9

These errors will be fixed in time, so they are not a big concern. The problem is that with v9, the “Dynamics 365 for phones” mobile client forces the use of the Unified Interface. The previous version of the mobile client worked based on CRM “apps”, where an app was created in CRM that defined the sitemap, and entities, forms, dashboards available. It was a way to create a subset of CRM that was available to select users. The mobile client then used the Web interfaces and forms built for those apps to display its content. With v9, the mobile client will only display apps created for the Unified Interface. It is no longer an option to use Web Interface apps on the mobile client and they are not visible there. For one, this means you will need to re-create any CRM apps you are using on mobile currently, as your old apps will disappear from the mobile client. More importantly, this means that any bugs and limitations of the Unified Interface are automatically carried over into the current “Dynamics 365 for phones” mobile client and there is no choice or workaround to turn that off. This was reproduced and confirmed by Microsoft Premier Support working with the product team and confirmed as a feature in v9.

Normally when a feature is removed from Dynamics, there is a depreciation notice and a grace period during which customers can make adjustments before the feature is completely removed, however there was no deprecation notice for the Web interface being removed from mobile. Hopefully the issues with the Unified Interface are fixed quickly, so that there is less of an impact as customers begin upgrading to the latest version.

Topics: Microsoft Dynamics 365