Sonoma Partners Microsoft CRM and Salesforce Blog

Exploring the Nuances of the Outlook Add-In: A Review of Merging Contacts and Sync Filters

Today's post is written by Melanie Waldman, a Consultant at Sonoma Partners.

The Microsoft Dynamics CRM add-in for Outlook is a convenient tool that allows users to view, create, and edit records in CRM without ever having to leave the comfort of Outlook. The add-in also allows users to sync contact records from CRM directly into their Outlook contacts.

But what happens when you’re syncing contacts between CRM and Outlook? What happens when you merge duplicate records when contacts are stored in two places? In this post we will examine the way that CRM and Outlook manage contact records throughout the merge process.

When you use the CRM add-in for Outlook, contacts can be synced between Outlook and CRM in two ways:

  1. Users manually track a contact from their local contact list in Outlook
  2. Contacts created/managed in CRM match the sync filters set in Outlook

Once a contact has been manually tracked or has met the sync filter criteria, any updates or modifications to the contact record are passed back and forth between CRM and Outlook.

Over time, users may manually track local Outlook contacts that already exist in CRM and even with duplicate checking in place, users may carelessly create another record in CRM for a contact that already exists; no matter how clean the data started, your CRM system can quickly become bogged down with duplicate records.

With the sync between CRM and Outlook, users may be updating certain fields on one record and not the other, without knowing another record for the same contact exists.

However, once duplicate records have been identified, if users have adequate security permissions, they can clean up the data and merge the duplicate records. Through CRM’s native merge functionality a user can select which record will be the ‘winning’ record and which record will be the ‘losing’ record; the losing record will be deactivated at the end of the merge process.

Users can also select what data should be included on the winning record and what fields should carry the value from the losing record, instead of the winning record.

Image 1

After the merge is complete, if you return to your active contacts view in CRM you will only see the winning record listed. If you toggle to the inactive contacts view, you will see the losing record. You can also navigate to records related to the losing contact and you will see that the winning contact record has taken its place.

Seems simple enough, your data in CRM just got a little cleaner, but once you open Outlook things get interesting.

Depending on a user’s Outlook sync filters, when duplicate contact records are merged in CRM, the losing record will be removed from the owner’s Outlook contact list without being replaced with the winning record.

The default Outlook sync settings are set to “sync active contacts that are owned by the current user”. If you remember, earlier we stated at the end of the merge process the losing record is deactivated. With this filter criteria, the losing record no longer meets the requirements causing the link between CRM and Outlook to break and the losing record will be removed from the user’s contact list. The winning record, while still active, will not meet the Outlook filter criteria because it’s owned by another user. Therefore the current user will lose all trace of the contact in Outlook.

Obviously this is a red flag, losing or misplacing contact data will kill user adoption. The good news is there are ways to avoid the loss of data.

Outlook sync filters are configurable at an organizational and user level. You can change the default sync filter to include inactive contacts. When a contact is deactivated in CRM, the link between CRM and Outlook won’t break, the contact will be visible in the user’s Outlook contacts, but under categories it will show that the contact is inactive. If the user chooses to view the contact in CRM it will bring them to the deactivated record. It’s important to note that changing the sync filters to include inactive contacts only solves half of the problem, the winning record will not sync to Outlook and the user will not receive any updates made to the contact going forward.

Image 2

To solve for both problems, we recommend using connections or a custom entity.

Users would create a record through connections or the custom entity for each of the contacts they want to sync to their Outlook. They would also change their Outlook sync filters to look for connections or related records on the custom entity. Since connections and related records are passed to the winning record in the merge process, users won’t have to worry about their contacts changing ownership or falling out of the sync filter.

At the end of the day, duplicate data will exist in your system and the CRM add-in for Outlook will still have its limitations.

But the fight against bad data entry is an easier fight than the fight for user adoption.

And despite its limitations the CRM add-in for Outlook offers users an alternative way to interact with the system; flexibility is key in today’s fast-pace work environment.

We here at Sonoma Partners have taken a lot of interest in how the CRM add-in for Outlook works and how data is exchanged. As our investigations dig up new findings we will be sure to post them on our blog. 

Data shows no emotion


Dynamics CRM 2016 – New Keypress Events

Just a few weeks ago Microsoft announced the official release of Dynamics CRM 2016 for both Online and on-premise.  With this release comes exciting new features for developers.  The new feature that I will cover in this post is the ability to add keypress events to number or text controls.  The new keypress event allows developers to trigger a function when the user presses keys in a number or text control.  This will allow developers to provide more rich data validation in a supported manner which is especially useful if auto-save is used in your organization. 

For example, if you want to ensure the user enters valid data into the native phone number field, we can register on the keypress event and automatically remove invalid characters as the user presses them.

First we will setup a function on the new addOnKeyPress event for the main telephone field.

Xrm.Page.getControl('telephone1').addOnKeyPress(function() { });

Then we will retrieve the value from the main telephone field to get the keys that the user inputted.

var userInput = Xrm.Page.getControl('telephone1').getValue();

Then we will build a regex to replace any of the inputted keys that are not “(“, “)”, “-“, or a number.

userInput = userInput.replace(/[^\d-()]+/g, '');

Lastly, we will replace the main telephone value with the new clean version of the user’s input


It’s just that easy!  Now if a user presses an invalid character in the main telephone field, it will automatically delete the character so the field will not be saved with invalid data.

Below is the full snippet of code:

Head here for the full SDK documentation on the new keypress methods.

Topics: Microsoft Dynamics CRM 2016 Microsoft Dynamics CRM Online

Salesforce Lightning – The Lightning Experience for Admins

In our previous post about Lightning Experience (LE), we looked at the impacts from an end user’s point of view. In today’s post, we’ll continue the discussion by exploring what features of Lightning Experience an admin will care about most.

LE for Admins

For Admins, the Lightning Experience will provide both new opportunities and challenges when it comes to managing their organization.

Enabling LE

To start, Admins need to be aware that users do not have access to the Lightning Experience by default. To give users access to see it, they need to follow two steps:

  1. Enable Lightning Experience in their organization.
    This activates Lightning Experience as a feature available to their organization. It also adds a new permission to the organization which will be used in the next step.

  2. Grant users access to view the Lightning Experience.
    Even if Lightning Experience is enabled, users still cannot access it. To do that, they will need to be given an extra permission (either through permission sets or profiles) that allows them to switch between the two UIs. In this manner, Admins can control which users have access and slowly roll out the UI to test users.

Configuration in LE

One of the major improvements in LE is the setup menu. The menu has been reworked to make things easier to find, and in many ways is easier to use. Objects are now combined in to one menu that contains all objects in the system, instead of splitting them between native and custom objects:


This makes it much easier to find the object you’re looking for, and reduces the training time needed for new Admins. Similarly, creating workflows, processes, flows, etc. has been made easier by grouping them all under a Process Automation header instead of in the Create category:


Lastly, on the Setup Home there is a quick menu that lets you perform the most common administration actions without having to dig through the menus at all:


All of these improvements are intended to make managing your organization a quicker, easier process with less digging through menus.


The Lightning Experience is a complete overhaul of the UI, including the forms that the user interacts with. The forms and fields have been restyled to look modern and similar to SF1. Thankfully, Salesforce has taken care of most of the hard work for us and any form customizations (field positions, required fields, related lists, etc) will continue to work with the new styling applied.

Custom Buttons

There is one big caveat to the forms working as is in LE: custom buttons. Custom javascript and url buttons are not supported in LE, and will not appear on the form. Salesforce recommends using other parts of the platform, such as processes and VF pages, to accomplish what had been done through the custom buttons. This can become very tricky so we highly recommend an implementation partner be engaged during this process to ensure everything will work as expected.

Lightning App Builder and Lightning Components

One new feature available with Lightning Experience is the Lightning App Builder. With the app builder, admins can now build full pages using Lightning Components (available from the App Exchange) for their end users. Because this is based on lightning, these pages have the ability to scale down to mobile forms and are Salesforce1 ready. Using this new features, administrators can build out custom pages for their users to meet their business needs without having to involve developers, reducing time and cost.


Wrap Up

The LE feature is a large one, with lots of potential impacts. We’ve covered what we think are likely to be the most useful for administrators, but as always the feature should be tested in a sandbox environment before being deployed to production. If you have any questions about LE from an Admin point of view, or would like help in determining if LE is right for your organization, please contact us.

Salesforce Lightning


Topics: Salesforce

Access Teams: One developer’s journey of hunting down his white whale and living to tell the tale

Today's post is written by Mike Dearing, a development principal here at Sonoma Partners.

Since the introduction of Access Teams in CRM 2013, I’ve had several opportunities to implement creative ways of leveraging this leaner form of record sharing to address our client’s more advanced security needs.  For those unfamiliar with this feature, it is a simplified and higher performing alternative to the days of sharing records to individual users with no relation to one another other than for the purposes of accessing a particular record. 

MSDN has a great write up if you want to learn more about when to use access teams versus owner teams.  Though implementing and using access teams is fairly straight forward, I recently ran into some snags when programmatically adding members to these teams that’d I’d like to share with my fellow CRM developers to hopefully save you the headache of troubleshooting these should you be as unfortunate as I once was.

The user id is invalid

What user id, you ask?  After some sleuthing, I determined it to be the team administrator being added as CRM programmatically created my access team.  If you find yourself programmatically adding members to access teams, make sure that you are not instantiating the organization service, or that a prior plugin that kicks off your code isn't instantiating your organization service, as SYSTEM. 

The initial access team creation, which happens when the first member is added to it, needs to run as an actual CRM user.  Whether or not you leave that as the current user, or if you decide to elevate to a system administrator service account, is up to you.  That user then becomes the team administrator for the access team, which CRM prevents from being SYSTEM.  You will get an error of "the user id is invalid" otherwise.

The wrong way (UserId will be SYSTEM):


The right way (ensure UserId is not SYSTEM):


Everything the light touches is our kingdom

The cascading section of this post has been updated to include a leaner cascading configuration, thanks to clarifications from Adam Vero.

If you want child records to inherit their parent record’s access team privileges, you will need to set up the behavior for the child relationship to have, at a minimum, cascade share, cascade unshare, and cascade reparent. Cascade share and unshare ensures that any child records created before your access team has its first member added will inherit the parent's access team template's rights appropriately. Cascade reparent will ensure that any records created after the access team has been added (or switches parents from a different contact to the one with the access team) will also inherit these rights. 



That’s it for now, my friends.  May your future programmatic access team implementations be merry and bright!

Facing your own CRM white whale? Contact Sonoma Partners, we’d love to help out!

Dynabacus the Microsoft Dynamics CRM Record Count Tool


Topics: CRM Best Practices CRM for Professional Services Microsoft Dynamics CRM 2013

Resume Tips from the Recruiting Desk

This infographic has been created by Kelly Esquivel, Senior Talent Acquisition Specialist at Sonoma Partners.

Resume tips infographic11

Want to learn more about open opportunities at Sonoma Partners? Take a look at our current openings and bomb benefits.

Salesforce Lightning – The Lightning Experience for End Users

The 500 lb. gorilla, the big cheese, the whale in the room, the feature of lightning, Lightning Experience (LE) is what most people think of when they think of Lightning. Being a UI overhaul, Lightning Experience has major impacts on all users of the system, and has the potential to break existing functionality. In this post, we’ll explore what features of Lightning Experience come out of the box, and how they will impact your users.

LE for Users

The group most impacted by this change, users are going to have a learning curve to go through when first interacting with the new UI. This isn’t necessarily a bad thing – it provides the opportunity to reevaluate business processes and streamline processes while the user doesn’t have an expectation of workflow.

Looking at the new UI, the most noticeable feature is the navigation. Having moved from the top to the left, the navigation is brought in to line with SF1, reducing the number of interfaces the end users need to master.


Once a ‘tab’ is selected, most parts of the new UI stay fairly close to the old UI until a record is selected. The object forms have been reworked in an attempt to provide end users with the information they most likely need quickly. In the new UI, related records and activities are front and center on the forms, with the details of a given record and the chatter fields being hidden away in separate tabs:


Depending on how your end users use the system, this may be a boon or a step backwards. Unfortunately this is not customizable in the current (Winter ’16) release.

A special feature has been introduced with the intent of helping users follow sales and lead qualification processes: a process stage visualization to help users quickly see where a given record is at in the current process.


Currently this is only available on Opportunities and Leads, and depending on your process may be more or less useful to your end users.


With all of these updates focused on improving user productivity, most users are excited about the UI refresh. However, it should be noted that the new Lightning Experience is not a turnkey solution. For a full list of what works and what doesn’t see this trailhead lesson by Salesforce. Below we’ll cover a few of the major issues most of our client have/are running in to when migrating to LE.

Note: This information is current as of the current release (Winter ’16). Future releases will most likely change these issues. Always check the documentation for the latest release information.

Inline Editing

One of the biggest pain points we currently see with our customers is LE’s lack of support for inline editing. When using the new UI, users must click the edit button at the top of the page before making edits. For some users, this frustrating and causes a significant slowdown in adoption of the new UI.

Custom button support

Most of our clients use custom buttons at some point in the solution, either to pass extra parameters to a new page or to link out another page. Some of these buttons do not appear in LE, depending on their configuration. From the user’s point of view, this is one of the more painful areas to work through as it fundamentally breaks the users existing workflow. This is an area we highly recommend an implementation partner be involved with evaluating to ensure a workflow that makes sense in both UIs.



Unsupported Objects

The LE only supports some of the objects available in Salesforce. Notably, the various team objects are not supported. If a user clicks on one of these objects from a related list, the user will be returned back to the Aloha UI, resulting in a jarring experience.

Unsupported Areas

Currently, LE only supports the ‘core’ objects and area of Salesforce. Things that are not supported include any of the Consoles (Service Console, Sales Console), knowledge, and communities. If your users work in any of these areas, LE will revert them back to the Aloha view.


Today we started looking at LE and covered its implications and impacts for your end users. In future posts we’ll look at it from the point of view of admins and developers to give you the full picture on this features impact for your organization. If you have any questions, feel free to contact us.

Topics: Salesforce