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

9 Wins for Manufacturers Using Mobile CRM - Part 3: Increase Revenue

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

Field sales teams at manufacturing organizations are doing the best they can to meet with prospective clients while pushing products at the ideal time and place.

Is your company providing your sales team with the best tools to work in the field?

An on-premise customer relationship management (CRM) system requires sellers to be in the office to access critical customer data. Why not invest in a tool that’s just as mobile as your sellers?

Over the next few weeks, we’ll share nine key wins for manufacturing companies using mobile CRM solutions. So far, we’ve covered the importance of surfacing information that matters and the advantages of data access on-the-go that mobile CRM provides. Now, it’s time to talk dollars and sense.

3. Increase Revenue

Mobile_CRM_blog_3_500x300At the end of the day, the tools you invest in as an organization reflect how you plan to enable growth and increase revenue. Manufacturers using mobile CRM can close orders on the spot, the moment they happen, ensuring that your team isn’t missing out on opportunities between sales calls.

Free Up Time

Custom mobile applications empower businesses to do incredible things with CRM. Free up time for your reps on-the-go when they can log notes, store images directly to Account records, and view nearby Accounts in CRM. Users can create Associated Activities quickly and fully integrated with the native email and phone apps on the device. By leveraging both user experience and design expertise, you can have a simple, elegant interface that meets the needs of your sellers, while allowing them to work faster. Ultimately, this translates to more sales for your organization.

Streamline Efforts

Build your custom mobile application in a way that’s specific to your sellers’ use cases. If you have sellers conducting surveys in the field or evaluating potential opportunities, a mobile CRM solution can make a big difference. CRM can prompt next activities and follow-up automatically with employees at your organization headquarters to move opportunities quickly and efficiently.

Customer Example: Brooklyn Brewery

Like most breweries, Brooklyn Brewery’s sales reps are not conducting “sales,” as much as they are monitoring product quality, building relationships with their buyers, conducting surveys, and assessing product placement. To enable their sellers to access customer data on-the-go, leadership invested in a mobile CRM solution.

CRM has brought a focus to Brooklyn Brewery’s sales organization. Their sellers can go onsite, research customer information onsite, and focus on the ultimate goal: helping Brooklyn Brewery grow their reach, sell strategically to their customers, and – of course – increase revenue.

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.

Topics: CRM for Manufacturing Enterprise Mobility

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

The 10 Benefits of User Acceptance Testing

Today's blog post was written by Brian Kasic, Principal Consultant at Sonoma Partners.

My project team recently had an in-person User Acceptance Testing (“UAT”). 25 team members from across the country gathered in Boston for testing. The teams were hesitant to start the official user testing of a custom-built CRM application for a banking real-estate investment and tax credit process but a decision was made that the benefits outweighed the risk of “not being ready” for this week-long event to test the CRM application that has in the works for over a year. Just like any tough project, the feeling of “not being ready” can flow through one’s psyche. But project leadership was determined to make it happen. The reward at the end of this week was confidence in the work that has been done, and it made the team realize we were ready to proceed with going live with the CRM system. It also showed other intangible benefits. As a motivating factor, Starbucks coffee was offered to anyone, whenever they wanted it. “Gotta get the coffee! And keep the team testing” kept going through my head as the program manager ultimately responsible for the success or failure of this very important week. Conveniently, we had a Starbucks store at the base of our elevator in our building. We even used their mobile app to get everyone’s orders just the way they wanted them. Thank goodness for technology and mobile apps (see Attendee in AppExchange for one by Sonoma Partners!).

But the main point of this blog is to emphasize the value of User Acceptance Testing and to encourage you to go for it!

Many benefits came out of the testing even though two weeks prior we had many team members saying that they weren’t ready.

Here is a list of the ultimate benefits:

UAT_testing_B.Kasic_blogOpportunity to Collaborate

The team from all over the country was able to ask questions about the project, in person with each other. Being a remotely located team this was valuable face-to-face time with each other.

Focus and Prioritize

We have had a long project and sometimes the little fixes get in the way of what is really most important. For us, we need a minimal viable product for the business team to operate on day 1.

Show the Vision

There is going to be support for our product, post go live, so the small nice to have updates will not be left behind once the project is complete. We will fix any defects right away but understand that most users are primarily engaged once they have to use a new system for their day to day activities. After go live, our team will continue to support the product with the most valuable feedback we receive from our business team.

Check the Data

Data is key and it has to be reliable. Even if the system is not perfect on day 1, we have to be able to trust our data. The legacy system will be “read only” and we will be able to compare and contrast historical reporting. This will be a great way to check that the data in the new system is complete and accurate.

Test Access

I’ve seen too many system go lives where security roles, profiles and access was not what was expected. The key here is to make the access plan transparent to the stakeholders and engage them in testing various profiles, groups and scenarios. Be prepared to have a role that can get anyone through a process on day 1. You don’t want to stop business operations because of an access mistake. Then make the necessary adjustments while always being cautious of granting too much access to sensitive information.

Teach and Train

For many testers, this is a great opportunity to teach them new areas and train them on the overall system. User testing should not be mistaken with training but it is the first step in making sure that the users of the system can assist their peers when questions arise.

Prepare for Go-Live

We talked about our plan at go live and the overall support model. How many team members would need to be “on call”. The process for users to get support. A hotline to ask questions. We discussed team schedules and availability. All important details to plan well in advance of the final weeks of the project. Doing this planning early allows the team to focus on the top priorities and not the logistics during a critical time in the project.

Motivate the Team that the Finish Line is Near

Projects can wear people out, so motivation is important to keep the team going. We continue to ask, “what is in this project for the company and for us as individuals?” We held a team dinner to make sure everyone is feeling appreciated for the efforts and hard work they have given.

Fix the Issues

With all the other benefits of user testing, the main one it to fix issues. At the end of each day the team would hold an hour issue triage call where we could highlight all the issues identified during the day’s testing. During this meeting, we determine who would be on point to fix the issue. Sometimes these were know issues and other times they were newly identified defects that needed immediate attention before continuing testing. Quick turnaround time and visibility to the issues is critical to staying efficient in UAT.

Drink the Coffee

Taking breaks to walk and talk helps lighten the load in a full week of conference room testing. Grabbing coffee shows the team you care and keeps the caffeine level up to keep going. These types of testing weeks can be intense so taking a break and motivating everyone with good treats sure helped!

So when your team is not feeling ready to user test, consider the positives and benefits. After the fact you will be glad that you made it happen. For more guidance on user testing of CRM application, please contact Sonoma Partners.

Topics: CRM Best Practices

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