Sonoma Partners Microsoft CRM and Salesforce Blog

Understanding Office 365 User Account Management for Dynamics CRM Online

Today's post is written by Aaron Robinson, an Engagement Manager at Sonoma Partners.

Microsoft Dynamics CRM has long offered customers the option of choice when it comes to deployment as a differentiation of their product relative to other customer relationship management solution offerings.

But there are some differences in administration and capabilities depending on the deployment option chosen.  Let’s take a look at user administrator as it relates specifically to Dynamics CRM 2016 in Office 365.

Account Types

One benefit of the online or “cloud” offering of Dynamics CRM is how users are created and managed.  But before we get into how administration works, we need to understand the ways user accounts are created for Office 365.

Cloud Accounts

If you created an Office 365 tenant and use the Administration portal to create users, you are more than likely creating “cloud accounts”.  What does this mean?  Office 365 authentication is supported by a version of Microsoft’s authentication engine Active Directory.  More specifically, it is Azure Active Directory, meaning it is also a cloud service, just hosted on the Azure platform.  So how do I know if they are cloud accounts?  Easy!

First login to (I’m going to assume that you are a global (tenant) admin and have permission to the admin tab, otherwise you will not be able to do this).  Once logged in, browse to Users>Active Users and look for the Status Column shown below:


The important piece to understand about this method is that the accounts are stored in an instance of Azure Active Directory. You can view this directory by navigating to Admin>Azure AD in the same Admin Portal as shown below.


If you do, it will redirect you to the Windows Azure management website, and ask for you to create an account to manage this Azure tenant. Note this is not a requirement.  You can continue to manage users in the Admin portal without ever visiting the Azure AD page. Since this azure portal is a whole other beast, its better left for another time.

Local Accounts

Another method is more common in enterprise scenarios, where Active Directory domains have already existed for years and single sign-on (SSO) is preferred for on premises and cloud services in an organization. These accounts must either be sync’d with a cloud Active Directory, or redirected to federation service for authentication. For users this means they will continue to use same email address and password they currently use, and password changes will sync automatically.

DirSync or Azure AD Connect

Directory Sync is one method for enabling single sign-on.  One aspect I like about this method is that it is a single page authentication, rather than redirection, meaning less clicks for a user. However, administration of this method can be more demanding, as you need to make sure the service is always running.  Microsoft does aide in this process as they will notify the tenant admin if the sync goes down for a predetermined period of time, letting you know that someone should look into it.


The requirement for directory sync is to set up a synchronization service on a server behind the corporate firewall which can connect to the local Active Directory.  This was previously done with a tool called DirSync, but has since been replaced by a newer version called Azure AD Connect.  There is plenty of information on the deployment of DirSync and Azure AD Connect, so we won’t cover that here.

Active Directory Federation Services

ADFS is another way to go for enabling SSO.  Many enterprises will already have this in place for other SSO applications they manage, and as such may be more desirable.  The downside of this method in my opinion is the user experience.  From the Office 365 sign-in page, a user will enter their email address, and Office 365 will redirect them to the ADFS sign-in page for the organization, where they will have to enter their credentials, possible for a second time (the experience can be a bit inconsistent here depending on the device, operating system and browser).


Once again, there is plenty of good information on the setup here.

User Management

Now that we have covered where the user accounts can exist, let’s examine how they become users of Dynamics CRM.  This is a two step process that is fairly straight forward. Let’s start with license assignment.  Back to our trusty Admin Portal for Office 365 where our users now exist, you will want to expand the Active Users.  Select a user, which will give you the user admin panel to the right side as pictured below.


Click Edit on the Assigned license section and add a Dynamics CRM license to this user (this assumes you have purchased the licenses in advance, otherwise you may not have them available). The nice part here is that Microsoft has automated the user creation in Dynamics for you.  Once you have assigned the license, an automated routine will run to create the user record in Dynamics.  Keep in mind that this automation is not instantaneous, and it may take a few minutes for the user to appear.  But in most cases I see it appear in under a minute.

The last step is to sign into Dynamics as a CRM Administrator, and add a security role to the new user account. Unsure how to do that?  Refer to this TechNet article.

And one more thing…

Would you like to see a list of all Dynamics CRM Licensed users in the Admin portal? On the Active Users page, there is a view filter dropdown for seeing users by different attributes, such as Active Users, SignIn Allowed or Blocked, Unlicensed Users, etc.  A really helpful view is Dynamics CRM Licensed Users, but it doesn’t exist by default.  Here’s how you would add one.  Click the dropdown for Select a View, and select New View.


Name your view (“Dynamics CRM Licensed Users” works for me), and then under the Assigned License dropdown, select Microsoft Dynamics CRM Online Professional, and then click save.


Now pop into the Active Users, select your new view, and there you go!


Looking for help with your Dynamics CRM deployment?  You came to the right place! We can help you better understand Office 365 user account management and so much more. 



Topics: Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Programmatically Editing Searchability of Fields

Today's post is written by Matt Dearing, Development Principal at Sonoma Partners.

We recently had a request from a customer to flip the “searchable” function on a number of fields from on to off; preventing users from searching on these fields in advanced find.

When you only want to modify a handful of fields, the easiest way to do this is through native customizations by editing the attribute’s configuration to flip its searchable value to “No.” If there are several fields to update, a great option is using the XrmToolBox’s Attribute Bulk Updater which, as the name suggests, lets you update specific attribute metadata in bulk.

However, in this case, the customer had a list of 1000+ fields across 20+ entities they wanted to have disabled to reduce clutter in advanced find. This would have taken a significant amount of time if we used the native customization editor or even the Attribute Bulk Updater, and both methods would have been prone to error. We decided to convert their list (which was originally the field and entity Display Names) to schema names and update programmatically.

The customer gave us a CSV file with a column for entity display names and another for attribute display names. Then to retrieve the schema names we used MetaBlast to export the metadata of the customer’s org. We planned on using VLOOKUPS to match the display names to the schema names but because a number of fields repeated across entities we needed to create a unique identifier for the lookup. We added an additional column to the customer-provided CSV file and the MetaBlast file and filled it with a concatenation of the entity and attribute name. With a unique identifier in place we used the VLOOKUP function to retrieve the schema names.


 var attribute = entity.Attributes.Where(x=> x.LogicalName == csvFieldName).First()
attribute.IsValidForAdvancedFind.Value = false;
orgService.Execute(new UpdateAttributeRequest()
	Attribute = attribute,
	EntityName = key
*The above code was in a try catch to print out those csv fields that could not be found or not be updated.

Next we wrote a simple LinqPad script that would: loop through the rows of the CSV, leveraging the CsvHelper NuGet package to bring the entities and attributes into memory; query each entities metadata; match the csv row attribute to the entity attribute metadata; then set the attribute metadata’s “IsValidForAdvancedFind” property to false and update the attribute.

Finally we published all customizations and voila the fields were updated. There were a handful of fields whose “IsValidForAdvancedFind” property was not updatable, and this could have been checked for in the LinqPad script, but with this being a quick one time run we just printed those fields out to the console window and let the customer know which fields could not be updated.

In the end this saved a ton of time from updating each field manually, and reduced the number of errors that manually clicking would have introduced. The customer was excited that we were able to clean up their searchable fields. It’s always good to look for existing tools to help speed up customization work, but sometimes a quick script is the best way to go especially if updating a very large number of customizations.

Topics: Microsoft Dynamics CRM

CRM - Where to start? What to do next?

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

Is your organization just starting your CRM adventure?

Have you already deployed CRM but have no idea what to do next? May we suggest a CRM roadmap? A well thought out and widely communicated CRM roadmap helps organizations in a number of ways:

  • Aligns your CRM program with the goals of the company to promote user adoption.
  • Gathers executive buy-in to your CRM initiative.
  • Reminds users of the capabilities that CRM has to offer and that the tool should continue to evolve with your business.

But how do you even start to put this roadmap together?

Here at Sonoma Partners, we gain insight and consensus from key business stakeholders of the CRM program through a series of workshops, each designed with a specific goal in mind. We call this process Envision. Whatever you call it, or however you structure these discussions, there are some key outcomes that you must achieve:

  • The ability to measure whether or not the capabilities enabled within CRM meet your overall company objectives, not just a requirement provided by a user.
  • How ready your organization is to embrace the change that comes along with a CRM initiative.
  • A series of projects identified and scheduled to avoid conflicts with other key milestones, cyclical fluctuations that affect the teams involved in this projects, and agreement on that roadmap.

Keep in mind, your roadmap will continue to change and should be re-evaluated on a monthly or quarterly basis. The goal is to use this roadmap as a guideline and motivation to keep moving forward.

Contact us today to find out more about the Envision process and how it can help you keep your CRM initiative alive and well.

How to get executives to pay attention to CRM

Topics: CRM Best Practices

Bringing Your Service Organization into the Internet of Things with Field Service Lightning

Today's post is written by Caitlin Pfeiffer, Principal Consultant at Sonoma Partners.

Salesforce recently announced a new product offering called Field Service Lightning that connects your field service team with your back office customer service team. 

This new solution is built upon the Service Cloud and is comprised of the following 3 main features:

Smart Scheduling

This feature allows to quickly and easily identify and schedule appointments for your field technicians based on your company's scheduling policy.  Your policy can be based on technician availability, skills, location, or other rules that you can define.  The scheduling engine provides you with a lot of flexibility, but below are a list of capabilities that we're most excited about:

  • Define grading criteria that will be used to recommend the best field technician and time slots for booking an appointment
  • Allow you to auto schedule multiple appointments at once based on your scheduling policy
  • Filter available technicians based on their skills ensuring only qualified technicians are scheduled
  • Account for travel time between appointments
  • Use one of the predefined scheduling policies to get your team up and running quickly


Dispatcher Console

The Dispatcher Console is a user interface built for your dispatchers to quickly manage field technicians and service appointments.  The console allows your dispatcher to view and manage services in a list view, a Gantt chart, and a map view.  This will allow your dispatched to:

  • See technicians with their scheduled appointments and estimated travel time on a Gantt chart
  • Drag and drop services onto the Gantt chart for easy scheduling and adjustments
  • See service appointments color coded by status
  • View the location of service appointments on a map with the location of your technicians (home base or last know position)
  • View of map of the scheduled route for a specific technician
  • Highlights appointments that violate your defined scheduling rules or are in jeopardy of potential problems
  • View key KPIs (total workload, average travel time, # of completed services, # of violating services, and # of services in jeopardy) for your field technician team or a specific resource


Field Technician Mobility (Salesforce1)

The technicians that are in the field will be able to remain connected through Salesforce1.  The Smart Scheduler is available in SF1, but what we're most interested in are the features that allow field technicians to manage their service appointments from the field:

  • Easily update appointment status through mobile quick actions
  • Capture a customer signature within Salesforce1 (this will be saved as an image attached to the appointment)
  • Send chatter reminders to the technician before a service appointment


Our Take

It's great that Salesforce now has a native solution for common requirements for customers utilizing a field service team for installation, support, repair, or product maintenance. 

  • It's part of the Salesforce product offering. Previously, we have implemented similar requirements for our customers; however, it required a lot of customization and custom development to provide this functionality.  
  • This is just the initial product release. Field Service Lightning is currently generally available and includes a core set of features, but Salesforce has a road map to add additional capabilities in future releases.
  • Field Service data can now be reported on within Salesforce.  By managing your service appointments and field technicians in Salesforce, you will have the ability to report on all of this information through standard Salesforce reporting or the Wave Analytics Cloud.

If your company has a field service team and you are interested in implementing Field Service Lightning, there are a few other things you should consider:

  • Field Service Lightning is currently made available as managed package.  It is built upon the core Salesforce objects and the managed package will install the Dispatcher Console, Smart Scheduler, and several custom objects needed to support this functionality.
  • You must have a least 1 full Service Cloud license within you Salesforce Org in order to use Field Service Lightning. 
  • This functionality is made available through 2 new license types (Dispatcher License, Technician License).  The Dispatcher License will give users access to the Dispatcher Console and Smart Scheduling.  At least 1 Dispatcher user will be required to complete scheduling your service appointments.  The Technician license will be needed for any user you would like to assign service appointments to.  
  • Currently Community Users are not able to use the Dispatcher or Technician licenses and, therefore, will not be able to use Field Service Lightning.

Wrap Up

If you have any questions about Field Service Lightning or need help implementing a field service solution within Salesforce, please contact us.

Topics: Salesforce

Salesforce Territory Assignments vs. Custom Object/Code

 Today's post is written by Emily Matthews, Principal Consultant at Sonoma Partners.

A scenario we’ve run into recently with several clients is whether or not to use native Salesforce Territory Rules vs. Custom Object/Code, when assigning a team to an Account.

For example, our client has Account Teams made up of a Sales Reps, Account Managers, and Account Specialists. The client uses Zip Codes to assign Accounts to Account Team, however, each role has different assignments and territory.

Territory Rules can be created and used, however, because Sales Reps, Account Managers, and Account Specialists each follow different assignment rules, separate Territory Models would need to be created for every Zip Code assignment. Initial setup and ongoing maintenance would be a time consuming effort and is not a scalable solution as the company grows.

To allow for a more flexible assignment model, Sonoma created a custom object called “Account Team Assignment”, which stores the Zip Codes, Roles, and Users assignments. Based on the Account > Billing Address Zip Code, custom code was utilized to find a Zip Code match in the Account Team Assignment object and assign user(s) to Account Team related list.

Additional custom code was created if there are changes made to the Account Team Assignment object, that need to be reflected in the Account Team. Finally, a custom metadata type was used to default the correct access for each Role in the Account Team. Although this solution does require a bit of custom code to match and assign, this solution is flexible and scalable for the future and easy for defined users to maintain.

Are you interested in learning more about this custom object? Contact us to discuss your Salesforce project today.

Topics: Salesforce

Firing events in JavaScript when status changes in Dynamics CRM 2013/ 2015/ 2016

Today's post is written by Rob Montague, a Developer at Sonoma Partners.

I needed to show a specific section based on the status of the entity.  I was trying to use onload only, but unfortunately, this doesn’t trigger when the status changes even though the page pseudo-refreshes.

You can, however, add an on-change event to the statecode field and whenever the state changes, it will fire your event.

Sample Code:

function opportunityExecuteOnLoad() {

function attachEvents() {
	var statecode = Xrm.Page.getAttribute("statecode");
	if (statecode) {

function hideShowSectionsBasedOnState() {
    // Make Sure statecode exists and you can read value
    var stateCodeAttribute = Xrm.Page.getAttribute('statecode');
    if (!stateCodeAttribute || !stateCodeAttribute.getSelectedOption()) {

    var stateCode = stateCodeAttribute.getSelectedOption(),
	// You can change "open" to whatever status you need
	isStatusOpen = stateCode.text.toLowerCase() === "open",
	generalTab = Xrm.Page.ui.tabs.get("general");

    // If general tab doesn’t exist, exit
    if (!generalTab) {

    // Get the first section.  If it doesn’t exist, do nothing, otherwise 
    // If state is open, show it, otherwise hide it.
    var sectionToShowIfOpen = generalTab.sections.get("sectionToShowIfOpen");
    if (sectionToShowIfOpen) {
    // Get the second section. If it doesn’t exist, do nothing, otherwise 
    // If the state is open, hide it, otherwise show it.
    var sectionToHideIfOpen = generalTab.sections.get("SectionToHideIfOpen");
    if (sectionToHideIfOpen) {

You are now able to harness the status change event and customize your page whenever the state changes.

Topics: Microsoft Dynamics CRM 2013 Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM 2016

Establishing a Value Proposition & Its Importance to Your CRM Success

Today's post is written by David Wojtonik, Principal Consultant at Sonoma Partners.


Establishing a value proposition for your CRM initiative seems like common sense, but all too often this critical step is missed or done at too high of a level and the implementation suffers because of it. 

A strong value proposition clearly explains how CRM will solve the end user's problem(s) and ideally quantify the value delivered.  Additionally, a value proposition is not "one size fits all" and needs to be tailored to the specific impacted group.  Below I have detailed the key steps you will need to take to craft the right messaging to ensure your CRM implementation is well received and highly adopted.

  • Identify who will be impacted.
  • Determine how each group will benefit from participating.
  • Quantify the impact if possible for each impacted group.
  • Communicate the value proposition clearly in words everybody understands, concisely and avoid turning it into "hype."
  • Clarify (and be honest) about what they are not getting as you are with what they are getting.

You must be careful, as your value proposition sets the expectation and you are responsible for meeting or exceeding that expectation.

Are you interested in learning more about value propositions and how they play into your larger CRM program? Contact us to learn more about CRM Engage.

Topics: CRM Best Practices

Cats and Dogs getting along in PowerBI Desktop

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

I have always found PowerBI to be interesting, but recently PowerBI has become incredibly powerful with the introduction of PowerBI Desktop last summer.

Last week I attended the inaugural Microsoft Data Insights Summit in Redmond and 75% of the sessions at the Summit contained demos around PowerBI Desktop. It’s clear that Microsoft is investing a lot of time and energy in the space and finally have a winner.

I’d like to showcase an example of using PowerBI desktop to pull data from a Salesforce environment.  Many of our customers own PowerBI but don’t know how to get started. Many don't know that connecting to a Salesforce environment is even possible.  Not only is it possible, but it’s very simple.  Also, you can just as easily connect your Salesforce data with data from other applications (even Microsoft CRM). 

From PowerBI Desktop, select Get Data, select Other and select Salesforce Objects.  Note that you can also connect directly to Salesforce Reports.  This would help if you want to only bring in a subset of the data, but for this example I will bring in everything for Account and Opportunity.


Next, you indicate where you want to connect to.  If you select Production you will login to your production SFDC org.  In this case, I am connecting to a test org so I enter the URL of the test org and click OK.


Next, you will select the objects you’d like to bring in.  For my purposes I will bring in Accounts and Opportunities and click OK.


This will pull in all the Account and Opportunity fields, and relate the two data sets.  Now we can start building our PowerBI reports.  To illustrate, I will select Amount field from the Opportunity.  You will notice PowerBI understands the datatype of the field and shows the Sigma () character indicating the field can be summarized.  I will then select the Close Date field.  PowerBI automatically puts the Date field on the axis and provides a date hierarchy for your chart.  Note that you can change the date hierarchy if the standard hierarchy doesn’t work for you.  Next I will remove Year from the date hierarchy by simply clicking the X next to it.  With just a few clicks I now have a Pipeline bar chart by quarter. 


Now that I have that report, I realize I’d like to see the pipeline by account owner.  While I can get to the OwnerID field on the Account object, I realize I’d like the name of the owner, so I’d like to bring this in from the User table.  Unfortunately, I only brought in Accounts and Opportunities, but I can simply bring in the User table without losing any of my work by following the same steps as before only choosing the User table this time.  Now I have three objects, and again, PowerBI has created the relationships for me so I don’t need to tell the tool how the tables are related.  You can view the relationships by clicking on the Manage Relationships button.  This is also where you can create relationships if PowerBI doesn’t catch on for you.


One of my favorite parts of PowerBI is how the datasets are linked in a way when you drill into one the other reports will drill down also.  There are several ways to view a Pipeline by Account Owner, but for this example I am going to add a slicer.  To do so, I’ll click on the slicer Visualization, and then add Last Name from the user table to the slicer.  I now can slice this report (and any other I add to this PowerBI file) by the Account Owner. 


When I have the reports how I like them, I simply publish out to PowerBI and they are available to those that can see PowerBI content from my company.  This is a very basic example of PowerBI working with SFDC, but hopefully it demonstrates the ease with which you can create valuable reports using PowerBI Desktop.



Topics: Salesforce