Sonoma Partners Microsoft CRM and Salesforce Blog

9 Wins for Manufacturers Using Mobile CRM – Part 4: Day Management

Today’s blog post was co-authored by Kayla Silverstein, Marketing Specialist at Sonoma Partners.

Our mobile manufacturing blog post series outlines the ways in which manufacturing firms can benefit from using CRM on devices. So far we’ve covered how mobile surfaces the information that matters, and we’ve looked at examples of companies using mobile CRM to manage data on-the-go. Most recently, we discussed how CRM mobility can increase revenue for your organization. Today’s post covers how CRM mobility can monitor and manage the day-to-day activities for your field sellers.

4. Day Management

The tools you invest in as an organization reflect how you plan to enable growth and increase revenue. With mobile CRM, sellers can order samples and close purchase orders the moment they happen, ensuring that your customers receive their orders in a timely manner. Getting orders to your CRM and ERP systems as soon as possible also enables a better service experience for your customer. They can complete report logs, optimize their day’s schedule, or quickly access marketing and product collateral.

Increase Productivity

Whether configuring the native CRM mobile solutions or developing your own custom mobile applications, these solutions empower sellers to be more productive with their day and interactions with CRM. For instance, your on-the-go reps can log notes, store product or service case images directly to Account records, capture competitive intel, and view nearby Accounts right from their phone or tablet. Users can quickly create activities that are fully integrated with the native email and phone apps on the device. By leveraging both user and design experience, you create simple and elegant interfaces that meet the needs of your sellers, while allowing them to work faster. Ultimately, this translates to more sales for your organization.

Mobile CRM_img4 (002)

Streamline Efforts

Build your custom mobile application in a way that’s specific to your sellers’ use cases. For instance, if your sellers conduct surveys in the field or evaluate potential opportunities, a mobile CRM solution can make a big difference. Mobile CRM solutions can prompt next activities or provide meeting agendas, and then follow-up automatically with employees at your organization headquarters to move opportunities along quickly and efficiently.

Customer Example: Hisco

Hisco is a specialty distribution company serving a large number of industrial markets, including aerospace/defense, medical, and electronics. Hisco’s previous CRM integration was not well implemented or adopted due to inefficient custom development and slow load times. By investing in Salesforce and Salesforce1 mobile application, Hisco provided their sellers a value-add system that enhanced their sales efforts. The new system fully integrates with ERP data and surfaces that information in the mobile application, providing additional value for those traveling sellers.

Stay tuned for more wins for manufacturers who invest in a CRM mobile application. If you’re interested in learning what might be possible at your organization, contact us.

Day in the Life: Meet Tom

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

No two days are alike for a Sonoma Partners Project Manager (PM). We interviewed Tom Demana to get a “snapshot” of what it’s really like to be a PM at Sonoma. In this post, Tom shares his thoughts on his favorite aspects of Sonoma Life and what he thinks it takes to be successful on the Sonoma Partners project management team.


How would you describe a typical day in the life of a Sonoma PM?

Tom-sonomapartners-3Tom:  Every day is different. I try and schedule as many of my client team meetings as I can early in the week. I find this gives the project team more time later in the week to go heads-down and pump out our work. My personal work could be anything from making a project document to planning future work with a customer, or getting hands-on and doing CRM customizations. It’s hard to describe a typical day just because there really isn’t one as a PM at Sonoma Partners – and for me, that’s the best part! Each client is different, each CRM use case has its own unique spin – there isn’t anything repetitive in my day-to-day, and I love that about project management at Sonoma Partners.

What is your favorite part of working at Sonoma Partners?

Tom: I know it’s said again and again in these “day in the life” blog posts, but I’d be lying if I didn’t say the people.  Sonoma truly does have a wonderful culture and even what I would call a community about it. I really feel like I get along with everyone, and they’re fun. It’s not just tolerable people here – they’re interesting people with unique lives and hobbies that make traveling for projects amusing and not just mundane travel for work. These are very smart people but with the openness to want to teach and learn from you as well. It makes even the more challenging of projects enjoyable when the team that has your back are people you respect, trust, and enjoy. Tom-sonomapartners-10

I would also say our “SWEET” policy. Being a PM can sometimes feel a bit like being a doctor on call for patients. If it’s late but a client needs something desperately, I’m up and on my computer. With “SWEET,” I can work extra one day, and if it’s a bit slow on a Friday afternoon, I can flex my hours and call it an early weekend. I love that Sonoma Partners respects the time of its employees and understands that this is not a regular 9 to 5 position all of the time.

Tom-sonomapartners-7What is your favorite part of being a project manager at Sonoma Partners?

Tom: I really like the structure and methodology in place on our project management team. We have a methodology that we use as a framework, but we don’t pigeon-hole ourselves into doing the same thing for each client. Every customer you meet has a different business model. I can tap into what I know has worked in the past and modify from there. I like that Sonoma Partners encourages and respects that method.

What is your favorite Sonoma perk?

Tom: Taco Tuesday (free tacos on the first Tuesday of the month) is one of my favorite perks. Everyone gathers in the lunchroom for make-your-own tacos, and you get to catch up with people you may not have seen for a bit.

What advice do you have for future Sonoma PMs?

Tom: Be flexible. We try and do things in an organized manner, but no customer is totally like another. Be comfortable thinking on your feet. Be honest and transparent with your clients. They’ll appreciate your sincerity and trust you all the more for it. Also, remember that you have a really strong team that has your back. If you’re feeling confused or struggling to answer a question, connect with your tech lead. Don’t just shoot off an email; pick up the phone or visit someone if they are in the office. Talking through the issue usually resolves it the most quickly. We have amazing people here, and not all of the weight of the project falls on your shoulders.

What do you think it takes to be a successful PM?

Tom: Strong communication skills. It’s important to know when and what to communicate and to be mindful of how you involve your client and your team. It also takes a strong attention to detail and the ability to juggle multiple priorities. A project manager can have several clients at once, and they’ll need to know how to best manage all of them in a manner that makes them all feel like they’re your only client.

Are you interested in joining our project management team? We’re hiring!

Topics: Careers at Sonoma

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