Sonoma Partners Microsoft CRM and Salesforce Blog

What if Power BI could help you forecast better?

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

A new feature in the August release of Power BI is the What If parameter. This allows you to define values for a slicer that can be used in DAX formulas allowing you to look at data differently, based on what if scenarios. From my perspective, this is applicable when looking at opportunities.

Traditionally, we look at weighted revenue in forecasting opportunities with varying levels of success. Probability is typically self-reported by the sales representative or based on an opportunity status that is self-reported by the representative. While we are working on predicting opportunity outcomes using Azure Machine Learning, I still believe past performance is the best indicator of future results. I know with certainty what percentage of opportunity revenue we’ve closed in the past, so we can apply that to future opportunities to obtain forecast.

Below I hope to highlight how you can use the What If parameter in Power BI to look at a forecast.

The example will be rather basic to illustrate the capability of the feature, but you could get quite complex with this type of analysis.

First, in the Power BI Desktop I’ll start with a simple data model that includes Customers, Opportunities, and Users. I’ll create two charts. First, using a Clustered Bar Chart I’ll show the Expected Revenue by Sales Rep. Next, using a Clustered Column Chart we’ll show the Expected Revenue by Year and Quarter.

Blanders 1
Click the image to expand.

Next I am going to add in a What If Parameter.  To do so, under Modeling in the What If section, select New Parameter. 

Blanders 2
Click the image to expand.


The What-if parameter dialog is launched.  Here I will Name my parameter What If Percentage.  I will leave the Data Type as a whole Number, and set the Minimum to 25 and Maximum to 125.  This will allow me to see what if scenarios between 25% and 125% of the current pipeline, which I will show in a minute.  Leave the Add slicer to this page box checked and click OK

You will now see a new table on the right-hand side for What If Percentage.  Under the table, you will see two options.  The top option is the slicer values.  To add this to the page, create a new slicer chart and select the field.

Blanders 3
Click the image to expand.

We can now toggle the slicer between the values of 25 and 125, but we need to apply this to the expected revenue field to see the data in motion.  To do so, I’ll create a new measure in the Opportunity table called What If Revenue.  The formula is as follows:

What If Revenue = sum(Opportunities[Expected Revenue]) * ('What If Percentage'[Parameter Value]/100)

You can see we are multiplying the Opportunity Expected Revenue with the What If Parameter (after converting it to a percentage by dividing by 100).  We now have a dynamic value in our Opportunity table.  Next, we will add the new measure as values in our bar and column charts to view the Expected Revenue side by side with the What If Revenue.

Blanders 4
Click the image to expand.

So, now you can see with an Achieve Percent of 100, the values are equal, but as I slide the slicer I see the what if value change in real-time.  For example, if I slide the slicer to 60, I can see what the numbers would look like if we hit 60% of the expected revenue.

Blanders 5
Click the image to expand.

I hope this illustrates how you can apply the new what if parameter to your Dynamics 365 for Sales data to help forecast your pipeline. Let us know if you have any questions by commenting below.

Topics: Analytics Microsoft Dynamics 365

D365 Edition: Dynamic Forms vs. Business Rules

Today's blog post was written by Justin Concepcion, Developer at Sonoma Partners.

First released in 2013 as a feature of Dynamics CRM 2013, Microsoft created Business Rules as a way to automate an entity form without requiring the use or knowledge of JavaScript. At that time, we released a blog post comparing Business Rules to our own entity form automation solution, Dynamic Forms. Since then, however, many updates have been added to Business Rules, and we wanted to come back to this comparison and review it with an updated view.

In the initial blog post, we found that Dynamic Forms provided a lot of functionality that Business Rules do not. In 2017, there are still gaps in Business Rules that can be filled using Dynamic Forms. For example, both Business Rules and Dynamic Forms have the capability to manipulate fields on a form; including setting field values, disabling fields, or requiring them. However, only Dynamic Forms is able to manipulate sections, tabs, and even the forms themselves. With regards to conditions, Dynamic Forms is also able to check many more things that Business Rules cannot. For example, while both can check field values when deciding whether to run a rule or not, only Dynamic Forms can check the form type, related entity field values, and even the current user’s security role.

Since 2013, however, a few new features have been added to Business Rules that Dynamic Forms currently does not provide. For example, Business Rules in Dynamics 365 can now show Field Recommendations, which displays a tool tip next to fields suggesting certain values. This allows you to recommend certain values for fields without actually setting the fields themselves. Another large change with Business Rules is the fact that they now run server-side instead of client-side on a user’s computer. Since Dynamic Forms only runs client-side, this means that Business Rules will be at an advantage for performance and easier maintenance when JavaScript would be paired with a plugin.

Overall, in 2017, Dynamic Forms continues to provide a lot of functionality that the Business Rules do not. However, since 2013, new features have been added to Business Rules that currently are not provided as well in Dynamic Forms. When deciding to use one or the other, we recommended reviewing your business requirements and making sure that you choose the one that best suits your needs as well as ensuring the rules interact correctly. Potential issues to watch out for include plugins and workflows getting triggered by server-side business rules and client-side scripts (such as Dynamic Forms) behaving unexpectedly with server-side with business rules.

Please use the table below as a guide to see which features are included in Dynamic Forms, Business Rules, or both: Ross and j tableIf you wish to try out Dynamic Forms, the Dynamic Forms Community Edition is free to download but limited to a max of 10 rules you can create.  If you need more or have any questions, please contact us.

To learn more about Dynamic Forms and download the free Community Edition here.

Topics: Microsoft Dynamics 365

Dynamics 365 Multi-Select Fields

One of the most asked for features from our customers is “does Microsoft Dynamics CRM have multi-select fields?”  Well, now we can safely answer “Yes” to that question, as the new version of D365 version 9.0 will have this in the product.

Note that I’m calling this D365 version 9.0, as this was originally the Spring release of D365, then July 2017 release of D365, and now since July has come and gone, it’s not clear when the release will drop.  However, we do know that it’ll be the next major version v9.0.

Multi Select Pre D365 v9.0

Before the release of D365 v9.0, there were many ways to get around the fact that Microsoft CRM did not have multi-select fields built in:

  • Custom 1:N entities where each child record represented a selected value
  • Custom N:N relationship where linking records in each entity together represented a selected value
  • Multiple custom fields on the entity where making selections in each field represented a selected value
  • Custom 3rd party solution such as Sonoma Partners multi select tool for D365

These solutions came with their own pros and cons, and neither was 100% the way our customers wanted the solution to work.  Some came with a heavier investment, some came with a less than ideal user experience for either adding values in CRM or importing data in bulk, etc.

However, all that changes with the v9.0 release of D365.

How Does It Work?

To use multi-select fields in D365, users will configure them just as you would configure any field.  Microsoft has introduced a new field type called “MultiSelect Option Set” that you can select when creating a new field.


All properties of fields that exist for the current field types, also exist for this new multi-select field type (e.g., enabling auditing).

Note that you can also make a multi-select option leverage a global option set and therefore you can have multiple multi-select option sets using the same list of values.  There isn’t a difference between global option sets that can be used for single-select or multi-select option set fields – it’s the same list of available global option sets to use for both.

System Administrators and System Configurators can add the multi-select field to forms and views, just as you would any other field.

How Does It Look?

When you have a multi-select option set on a form, and click into the field, you’ll initially see a slim dropdown appear with no values with the text “enter text here” which will allow you to start typing and then will display values that match the text you entered.

image image

Alternatively, if you don’t want to start typing to see values that match your text, you can click on the dropdown arrow on the right side of the field to display all values.  This is someone of a pain as it requires two clicks to see all values in a multi-select option set, whereas for a single-select option set still requires a single click to see all values.



As users start selecting values by a clicking the checkbox, the values appear above the drop down with a little “x” on each value where a user can click on it to remove that value (or just uncheck the checkbox).  The value you select first drives what value appears first in the list above (it’s not in alphabetical order).


When done selecting values, simply click somewhere else on the form, and you’ll see your values selected semi-colon delimited.  The values, once select, now appear in alphabetical order in the field.


When viewing the data in a view, you’ll see the values selected semi-colon delimited as well.  Also note that view filtering is supported.  Therefore, users can select values to filter the records with as you would with a traditional single-select option set.  However, with a multi-select option set, when filtering, records are returned if any value selected to filter with, matches at least one value selected for the multi-value option set.  In other words, if you select a value to filter records with that is contained in a record, and select a value that is not contained in that same record, the record will still return after filtering because it met the criteria that at least one value existed in its field.


And what about editable grids (recently released in December 2016)?  Yup, multi-select option set supports those as well!


A new “Contain Values” operator was also added to Advanced Find.  When this is selected, records are returned where ANY of the values selected are contained in the field for those records (think of this as an OR statement).  The “Equals” operator only returns records where there’s an exact match to the values selected in Advanced Find (think of this as an AND statement).


Technical Details

There are a few additional details to note about the new multi-select field that will be released with v9.0 of D365.

  • You cannot convert a regular existing single-select option set field to a multi-select option set field at this time.
  • Multi-select option set fields cannot be a calculated or rollup field (single-select option set fields can be a calculated field).
  • Multi-select option sets support the web client, unified interface, advanced find, FetchXML, Platform SDK, and Client SDK
  • There is full platform support to use SDK messages for retrieve

Additional Resources

As mentioned earlier, this is one of the most sought-after features that is finally making its way to the product, and we’re excited for its release.  For additional information on this feature, along with what else is coming with v9.0, check out Microsoft’s documentation.

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

Leading CRM for Leader Dogs

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

Bogged down by an inflexible custom CRM solution (Quilogy), Leader Dogs for the Blind wanted a more efficient way to track operations and client records in Microsoft Dynamics CRM (now Dynamics 365).

Who is Leader Dogs for the Blind?

Leader Dogs for the Blind is a nonprofit organization based in Rochester Hills, Michigan. Founded in 1939, they provide guide dogs to the blind and visually impaired. Through their programs, Leader Dogs helps clients find and work with guide dogs for greater mobility, independence, and quality of life.

Leader Dogs Project Fast Facts:

  • Industry: Nonprofit
  • Workload type: Customer Service
  • # of employees: 65
  • # of users in deployment: 65
  • Platform: Dynamics 365
  • Fun fact: Leader Dogs operates as the only facility in the Western Hemisphere to teach deaf-blind students how to work with a guide dog.


The Challenge:

  • Previously, Leader Dogs used a customer solution called Quilogy to manage operations, client services, puppy breeding, and training. While functional, Quilogy was an old system with limitations in both capability and scalability. For example, the outdated solution was not built to track puppy production schedules or many of the other unique operational components Leader Dogs required.
  • An outside consulting firm developed Leader Dogs’ custom solution several years ago and their relationship with the firm had since dissolved, making any opportunity to further customize or update the system impossible.

The Solution:

  • Replace Quilogy with Dynamics 365 to maintain all department records within the organization.

The Result:

  • Automation in CRM manages daily tasks with the dogs (such as flea checks, baths, etc.). Based on different triggers in the system, CRM creates Task records and assigns them automatically. When dogs are handed off between different teams, Leader Dogs can see which Tasks have and haven’t been completed.
  • The Breeding department uses CRM to trace dogs and their performance over their lifetime. A lot of analysis and science goes into picking the right dogs to breed for key traits that are essential parts of a strong guide dog. With CRM, they’re able to see how the dogs perform both in training and on the job, creating a strong feedback loop.
  • Their portal now meets accessibility standards for use by the visually-impaired.
Topics: CRM Best Practices Microsoft Dynamics 365

The Evolving Expectation on Customer Experience

Today's blog post was written by Adam Barr, Principal Consultant at Sonoma Partners.

What if I told you your ability to differentiate yourself from the competition will be dictated more by your Customer Service team than any Product Development or Innovation Office? Many organizations, several of them in your industry, have already experienced the impact of delivering a superior (or inferior) customer experience.

Various market studies forecast the increasing role of the customer experience in influencing buying behaviors and customer loyalty.

Gartner research predicts by the end of 2017, nearly 90% of marketers expect customer experience to be their primary differentiator. Aberdeen Group studies show companies that provide a consistent service quality across multiple channels retain 89% of their customers, whereas companies that do not provide a consistent quality are only able to retain 33%. Complicating matters, Google research highlights that 98% of Americans switch between devices every day.

What do all these statistics mean to you?

This means your customers have a voice; they want it to be heard; and they want it on a channel conveniently available to them. Customers realize the amplification of their voice in the social marketplace and now have a higher expectation to influence the terms of their engagement with your organization. Companies in turn have made greater investments in providing superior a customer experience.

Barr 1_cropped

In a 2017 Global Contact Center study, Deloitte identified that Customer Experience (88%, up from 71% in 2015) and Service Improvement (73%, up from 57% in 2015) are clear priorities for growth in the contact centers. More than 80% of organizations reported that customer feedback is “core to their DNA” or “a core input to business decision,” nearly doubling from 45% in 2013.

Omni-Channel vs. Multi-Channel

There is a distinct difference between multi-channel and omni-channel.  Multi-channel refers to organizations leveraging more than one channel (i.e. phone, web, email) to engage with customers, but it does not necessarily mean the experience is consistent or well-transitioned from channel to channel.  Multi-channel has become the table stakes for many customer support operations. Omni-channel also consists of organizations leveraging two or more channels to engage with their customers, however, with an omni-channel strategy, there is significant focus paid towards delivering a seamless and consistent experience regardless of channel or device.

Barr 2_cropped
The complexity of the interaction will still dictate the initial channel with which the customer engages your organization. Remember, from the customer perspective, the channel must be fluid and dynamic while still maintaining a consistent experience. Across the 450 global leaders surveyed in Deloitte’s Global Contact Center Survey, many indicate their organization invests less in voice solutions while focusing more effort in providing a variety of options. Voice is expected to remain the most prominent channel, but is predicted to fall from 64% of total interactions today to 47% in 2019. Web chat is expected to grow from 6% to 16%. SMS, video, and social are all expecting to double, although remaining under 10%.The channel preferences for customers are not only evolving; they are dynamic. An effective omni-channel solution needs to account for the fact that Customer A may phone you in the morning, follow up with a chat conversation, review an article attempting to resolve their issue, then email a support agent to close the day. All interactions must be captured in a centralized, logical, insightful fashion to appropriately meet the customers’ expectation for service. 89% of customer’s express frustration having to repeat their issue to multiple representatives. At its core, an omni-channel strategy is one in which all independent channels work cohesively as one unit to provide a superior customer experience.

Barr 3_cropped

Click on the image to expand.

Consumer interactions will only continue to increase in volume, due to additional channel access, and complexity, with the ever-increasing expectation of superior customer experience. These trends are not exactly new. Numerous market research firms have been forecasting the need for organizations to adopt a more customer-centric model for years. However, what has changed in the marketplace is the availability of tools for organizations to truly enable an omni-channel experience while minimizing internal business disruption.

In my next post, I will detail the technologies leaders are embracing to appropriately compete in a consumer-centric marketplace and explain how you can setup an omni-channel solution with CRM.  For more information on how we can help you build further upon – or develop a new – omni-channel solution, contact us!

Topics: CRM Best Practices

Lead Conversion Changes with Salesforce Lightning

Today's blog post was written by Rachel Sullivan, Principal Consultant at Sonoma Partners.

We recently came across an update in Lightning that makes the lead conversion process more flexible, but can also add a bit of confusion if not understood ahead of time. In this blog post, I’m going to show you what changed so you’re aware when you’re converting leads.

In Salesforce Classic

When you convert a lead for an owner who is different than the logged in user, the owner of the newly created Contact, Account, and Opportunity records defaults to the owner of the lead.

Click image to expand.

 Lead2Click image to expand.

The lead owner (in this case Aaron Robinson) owns all of the records you created, including Account, Opportunity, and Contact.

In Salesforce Lightning

With the update, a new dialog box appears when you convert a Lead. The box allows you to select an existing Account or create a new one.

Click image to expand.
Click image to expand.

If the person logged in and qualifying the lead is not the owner of the lead, and they created a new Account, they are now the owner (not the owner of the lead). This cannot be changed within this dialog box. The user must save first and then go back into the account later to change the owner.

Click image to expand.


Hopefully with this heads-up, you’ll be able to navigate this update with ease. If you get stuck or have any further questions, as always, let us know!

Topics: Salesforce

Compare Fields Across D365 Orgs to help Debug Solution Import Failures

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

When working with a solution it is common to make changes to customizations. Scenarios like an incorrect attribute data type that needs to be recreated are very common, especially early in development. Although it is easy to recreate attributes in a development environment, it can be challenging to import that solution into a target with a previous version of the solution. The import process may fail in the target organization with a generic error message. When this occurs, it is generally related to attributes being recreated. The following is a simple LINQPad script you can use to compare attributes in two different environments. It will print out any differences in casing of schema name or data type which are two of the more common reasons recreated attributes will cause a solution import to fail.

The script itself connects to two different CRM environments: a source where customization changes are made and a target for deploying the updated solution. The script scans the target to get all of the custom entities with a given prefix where the prefix matches that of the publisher for the solution. If the entity is new in source, there is no reason to compare it to target as it will not fail the import.

Next the script loops through the custom entities for the target environment capturing each entities attributes. Schema Name and Data Type are the two most important metadata properties to compare, so those are returned. If an attribute is deleted and recreated and the casing of the Schema Name does not match exactly, the solution import will fail. This is because CRM does a case sensitive comparison of attributes on solution import to determine if any attributes are new and should be created. It will see two attributes with differently cased schema names as two unique attributes, the failure will occur in the SQL database as two columns cannot have the same name. Unfortunately this won't show up in the solution import UI as a helpful error. The second more common failure is that the data type has changed. Maybe the attribute was an integer/whole number and should have been of type money, or it was a picklist and should have been a string. In that case the solution import will also fail when Schema Names match but data type differs.

Next the source environment is queried for its attributes to do the comparison. If the entity no longer exists in the source environment, an exception will be thrown and caught and printed to the screen. This would mean the entire entity no longer exists in the source environment, so there is no comparison that can be made.

Finally the comparisons are done by Schema Name and Type and any discrepancies are printed out to the screen. If the source attribute no longer exists, there is no need to compare.

Knowing the discrepancies in attributes between environments can help tremendously when attempting to figure out why a solution import is failing. Here is the full source code:

Let us know if you need any help or have any questions by commenting below.

Topics: Microsoft Dynamics 365

QnA Maker: An Easy Way to Explore Chat Bots

Today's blog post was written by Bryson Engelen and Kevin Yamashita, Sales Engineers at Sonoma Partners.

Today we'd like to show you a nifty tool from Microsoft that we've been using to add some pizzazz to the end of our service demonstrations. There are already a number of nifty tie-ins between Dynamics 365 and Azure, including product recommendations, documentation recommendations, connected field service, and sentiment analysis (via Flow). We find that it's compelling to show the breadth of the Microsoft stack as much as we can, even if that means leaving the safe space of Dynamics 365 sometimes. One of the limitations of showing ancillary Azure functionality is that these services can be clunky to maintain. Well if you're lazy like us, you'll love QnA Maker.

With this service, you can easily provision and train a chat bot to answer FAQ-type queries.

With this tool, you can very quickly load a list of question/answer pairs; we recommend pulling realistic examples from a prospect's own website. QnA Maker actually includes functionality to automatically scrub FAQ pages to generate this content, but in our own experiences our mileage varied depending on the site itself. Regardless, it's quick and easy to show off a client's own knowledge content in a compelling way.

Click on the image to expand.

If you want to embed your bot in a Dynamics portal or to expose your bot via Skype for Business, you'll need to actually put the effort in to provision a service within Azure. However, QnA Maker does expose a web interface to interact with your bot directly from the web. Our prospects often find that this is compelling enough and they can easily visualize how this service could be embedded and surfaced in other ways.

Click on the image to expand.

This web interface has additional elements exposed to help train your bot, and talking about this underpinning functionality during the demonstration is actually useful for prospects so that they can better understand how this technology actually operates.

Click on the image to expand.

You'll certainly want to show this whenever Live Assist or Dynamics Portals are in play, as chat bots could represent an initial line of defense for portal users before being routed to a live chat agent. So we invite you to give this tool a try if you haven't already. It's quick to set up, easy to demonstrate, and offers another way to hook people on the power of Azure. Clearly we love showing Azure as it relates to Dynamics. If you have any interesting Azure-related tips or tricks to share, we'd love to hear from you to keep the conversation going.

Topics: Microsoft Dynamics 365

Hey Cortana, Say Hello to CRM

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

Cortana integration for CRM has been available for preview since the 2016 Update. Here are some commands you can ask it to do. This feature was geared towards mobile phones, but it also works on a Windows PC or laptop.

As the Cortana integration becomes more developed and users explore its possibilities, we expect to see some requests for custom Cortana integrations with CRM as well.

In this post, I will give a brief, high-level introduction to the steps necessary to set up a custom integration between Cortana and CRM and the possibilities it offers us. In this example, there will be no user authentication, and we will hardcode our CRM connection string. I will assume you have an Azure subscription, Visual Studio 2015+, and some knowledge of C#.


Here are the steps we will go through:

  1. Environment Setup
  2. Implementation
  3. Register the Bot
  4. Test the Bot
  5. Deploy the Bot to Azure
  6. Talk to Cortana

Environment Setup

First, let’s set up our development environment. Visual Studio is free, and Azure has a free trial.

  1. You should have access to Visual Studio IDE, as well as an Azure subscription to deploy the bot.

  2. Download and install the Azure SDK for Visual Studio here.

  3. Download and install Cortana Skill template here.


We will implement a Cortana bot in C# .NET and connect to CRM through the CRM SDK. Our bot will be very simple – it will only respond to a couple of phrases and will only perform one query into CRM. For the scenario, I have used an entity from our internal Sonoma CRM system. We use CRM to track our work in records called Items. The items are assigned to people and have Due Dates. The bot we are going to build will respond to two questions regarding Items in CRM: “How many items are due this week?” and “How many items are due next week?”

1. Create VS project with the “Bot Application – Cortana Skill” template we installed earlier. I called mine, HelloCRM.


2. Restore NuGet packages and run a build to make sure everything is good. The template creates a sample bot with a controller and dialog.

3. Add CRM SDK NuGet packages: Microsoft.CrmSdk.CoreAssemblies and Microsoft.CrmSdk.XrmTooling.CoreAssembly. These are necessary so we can connect our bot to CRM.


 4. Open RootDialog.cs and replace it with the code below. The code does the following:

  1. RootDialog is an implementation of a dialog between Cortana and our bot.

  2. The StartAsync method is called one when a new dialog starts.

  3. The MessageReceivedAsync method is called each time a message is received from Cortana. That is, whenever the user speaks a phrase.

  4. The spoken message passes in with the result parameter, as a text string.

  5. First, we create a connection to CRM. We are using the Xrm.Tooling.Connector library, which makes it as easy as passing a connection string to a constructor. You will need to modify this connection string to point to your instance of CRM, with your credentials.

  6. Next, we extract the spoken message into a text string.

  7. Then, we use Regex to match the spoken message to a question our bot can handle. Note that the text string is a representation of what Cortana thinks the user said, so we have built in some fuzzy matching of like-sounding terms. For example, the words “week” and “weak” sound the same, so we’re matching on both.

  8. We check for two questions; “how many items this week?” and “how many items next week?” They will both trigger the same query in CRM, but the filter will be different based on which week we are looking at.

  9. Within each match, we first call the CountCRMItemsDue method. This does a simple FetchXML and returns a count of the results. Then, we send back a response using the SayAsync method. This method takes a parameter for the text to display, the text to speak and whether to listen for further questions, or end the conversation. We are passing the AcceptingInput hint, so Cortana will expect further questions in the conversations, after speaking the answer.

5. Rebuild again to make sure everything is good.

Register the Bot

We haven’t deployed the bot to Azure yet, but we can already register it on our Microsoft account. This is necessary if we want to test It locally first. We are going to register a new bot and connect it to the Cortana channel, so it can receive messages from Cortana.

1. Log in to with your Microsoft account.

2. Go to My Bots and click Register.

3. Type in your bot display name, handle and description.

4. Click on Generate App ID and password and generate both. Copy and save both, we will need them later!


5. Agree to the terms at the bottom and click Register.

6. You should now be on the Hello CRM bot page, in the Channels tab. Under “Add a channel”, click the Cortana image.


7. Keep the defaults and click Save

Test the Bot

We can test our bot locally, before we deploy it to Azure. To do this, we need to complete the bot registration above and install the Bot Framework Emulator.

1. Install the Bot Framework Emulator here.

2. In Visual Studio, open the Web.config file for your bot and near the top, fill in the App ID and password we copied earlier.


3. Run the bot in Visual Studio with the green Run button. It should be set to open in your default browser.


4. Take note of the URL and port number in the address bar of the browser that popped up. Now, start the Bot Framework Emulator.

5. At the top, click the blue bar, update the URL and port to match what is in your browser and enter the App ID and password you configured in your Web.config.


6. If everything is good, on the bottom right the Log should show a POST 200 message.


7. Now you can use the textbox on the bottom to send test messages to your bot, or click the microphone icon to speak to it. It will reply by text message, as well as speech (although it is not Cortana speaking).

Deploy the Bot to Azure

Now that we’ve tested the bot, it is ready to deploy to the cloud. We will be deploying it as an Azure App Service.

  1. Make sure the App ID and password have been added to your Web.config file.

  2. If you have a WebApp already set up in Azure, you can publish directly into it. Otherwise you can create a new WebApp as part of the publish process:

    1. In Visual Studio, right-click the project and select Publish.

    2. Select “Microsoft Azure App Service” as the publish target.

    3. On the App Service page, you can either select an existing WebApp to deploy into, or click New to create a new one.

    4. On the Connection page, keep the defaults, but copy the Destination URL; we will need it later.

    5. Click Next through the rest of the dialog and click Publish at the end. Visual Studio will deploy the bot to the WebApp location and open a browser window to it.

  3. Log in to with your Microsoft account.

  4. Go to My Bots, open the “Hello CRM” bot and click Settings on the top right.

  5. In the Configuration section, fill in the “Messaging endpoint” with the URL of your bot copied earlier, with /api/messages appended to the end.


  6. Click Save Changes at the bottom. Now the bot is deployed to the Azure cloud, instead of the local machine, and its registration has been updated with the URL, so Cortana knows where to find it.

  7. By default, the bot is only registered on your Microsoft account, and will only be available to Cortana running on your account. It is possible to deploy it to groups of users, or to make it fully public. On the bot page under My Bots, you can click on the “Manage in Cortana dashboard" link next to the Cortana channel to explore these options.

Talk to Cortana

Now we’re all set to have Cortana use our bot. To invoke custom bots, you need to use the phrase “Hey Cortana, ask <botname> <question>”.

  1. You can activate Cortana by saying “Hey Cortana” (if you have that setting turned on), or clicking the Cortana circle icon in the taskbar.

  2. In our case, we can say “Hey Cortana, ask Hello CRM how many items are due next week?”

  3. The first time Cortana connects to the custom bot, it will ask your permission to send your request to the bot.

  4. Click Yes, and you can now converse with the bot.


  5. Yay, no items!

I am excited to see the interesting use cases our customers will come up with for custom Cortana integrations. While controlling a system with your voice might seem awkward at first, it will become easier and more natural as voice assistants become more popular in homes.

I hope this was useful, thanks for reading!

Topics: Microsoft Dynamics 365

Can Users Really Change?

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

How hard is it really to change the minds of who you hope will embrace your CRM system? Unfortunately, it depends on the user. You can implement the best CRM system in the world but without user adoption, the program will be considered a failure. And without a plan of attack for that user adoption, your chances of success are slim. In fact, studies show that slow user adoption is the biggest threat to CRM projects.

So…get a plan of attack! Unlike the technical solution of implementing a new CRM system, gaining consensus of users must take on a more individualized approach. Let’s consider the following three stakeholders in our “fictional” CRM implementation (even though these people are made up, I’m sure you will recognize them):

Kristie1b_750 white background

In our Change Management Methodology, we focus on 5 main areas to address individual plans for change:

  • Readiness
  • Strategy
  • Sponsorship
  • Communication
  • Learning

When thinking about a plan of attack for each individual personality that will need managed throughout a CRM program, we address these five key areas.

Let’s go back to our team and see how we can address these areas with those individuals:

Kristie2b_750 white background

Need help coming up with your plan of attack? Contact us!

Topics: CRM Best Practices