Three Approaches to Migrating Communication Preferences for Subscribers/opt-outs in CRM

Are you planning to migrate from an old-fashioned marketing platform to CRM? Are you facing the difficulty of updating communication preferences for existing contacts in CRM? Do you need to update thousands of records? This blog will cover several ways to update your communication preferences in CRM.


Making the updates in Excel and reimporting

The first option you have is to export your CRM contacts, use vLookup formulas in Excel to combine the communications preferences from your marketing system, and then reimport your CRM contacts. This scenario is suitable if you are comfortable working with Microsoft Excel formulas. This approach does not require any coding or development knowledge.

Since you have a spreadsheet of subscribers and opt-outs with the most current communication preferences from your Marketing platform, you then need to export your existing contacts from CRM. To achieve this, please complete the following steps:

  1. Navigate to Contacts
  2. Select the View you want to export (eg. All Active Contacts)

Note: It is helpful if your view contains the columns for the communication preferences you need to update. In general, you would include "Do not Allow Emails", "Do not Allow Bulk Emails", ''Do not Allow Phone Calls", "Do not Allow Faxes" and "Do not Allow Mails". Do not forget to include additional communication preferences which are custom for your organization. The screenshot of general communication preferences is provided below.

  1. Click on Export to Excel button to begin the export process. CRM pops up a dialog box.
  2. Select a Static Worksheet option
  3. Enable the checkbox for "Making this data available for re-importing by including required column heading"
  4. Click Export.

Once you have the CRM data exported, you will use Vlookup formulas to update the communication preferences. In order to do this, you would also need to define matching criteria between two spreadsheets. In the example below we are using three email addresses as a matching criteria for opt-outs with an email address and Full name for opt-outs without email addresses.

Note: You may need to "Unprotect" the spreadsheet to insert new columns before applying the formula.

Add the necessary vLookups to the spreadsheet with the columns needed. A good way to structure the spreadsheet is to add the following columns:

After opt-outs are defined, you can remove rows that do not require Communication Preferences Updates via filtering. Select Subscribers only and then remove filtered rows keeping opt-outs in the file. Please note that you should remove complete rows, not just values in these rows.

After this is complete, simply update Communication preferences in the spreadsheet for all opt-outs, remove extra columns (Match Email1, Match Email2, Match Email3 and Concatenate column)

Updates via Custom Entity

Another way to update communication preferences is to create a custom Update entity with Communication preferences fields and develop a custom workflow to apply its values for Communication preferences updates.

This method is very helpful for anyone preferring working with CRM Customizations and workflows instead of using Microsoft Excel formulas. It was described in details here:

The summary steps are provided below:

  1. Import data from your subscribers and opt-outs spreadsheet as CRM Contacts making sure duplicate detection is set on email
  2. Records that fail during data import would be the ones that match existing contacts and require an update in Communication preferences.
  3. Export the failures in Microsoft Excel
  4. Manually set the preferences for each exported contact and import them back in a custom entity. When importing data, you will need to link updates to existing contacts in CRM via Data Import Mapping Rules. Once data are imported, the workflow should trigger and update communication preferences of associated contacts.

The only limitation is that you need to properly link an update record with a contact record via Data Import Mapping rules. If Contact entity contains duplicates, you may need to reimport records failing on data import and manually link them.

Updates via PowerShell Scripts

The PowerShell approach is very convenient for anyone comfortable with development expertise.

Sample code is provided below:

If you want more information about how CRM can be used as a marketing platform, please visit our Marketing Solutions page.

Happy CRM'ing!

Error When Activating/Deactivating Accounts or Contacts in CRM 2013

If you recently upgraded to Microsoft Dynamics CRM 2013 from CRM 4.0 and are getting an error when attempting to activate or deactivate a contact or account record, we may have the solution for you!

So what does this particular error look like? When attempting to activate or deactivate the record, you may receive a Generic SQL Error message alert box, and when you download the log file from the user interface, you may find the following output:

Deactivating Accounts or Contacts in CRM 2013

"Unexpected Error. An error has occurred."

This is a pretty standard error and doesn't tell us much by itself. So what should you do?

1. Try running a trace on the CRM server. You may find the following error message in the stack trace, with the relevant parts are highlighted below. (NOTE: You can find steps on how to enable tracing on the CRM server here.)

[Date/Timestamp] Process: w3wp |Organization: CRMOrganizationID |Thread: TreadID |Category: Platform.Sdk |User: UserGUID |Level: Error |ReqId: GUID | VersionedPluginProxyStepBase.Execute ilOffset = 0x65

    at VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context) ilOffset = 0x65

    at Pipeline.Execute(PipelineExecutionContext context) ilOffset = 0x65

    at MessageProcessor.Execute(PipelineExecutionContext context) ilOffset = 0x1C5

    at InternalMessageDispatcher.Execute(PipelineExecutionContext context) ilOffset = 0xE4

    at ExtensiblePlatformMessageDispatcher.Execute(PipelineExecutionContext pluginContext) ilOffset = 0x0

    at ExtensiblePlatformMessageDispatcher.UpdateWithInvocationSource(BusinessEntity entity, FilterExpression filter, Int32 invocationSource, ExecutionContext context) ilOffset = 0xCE

    at ExtensiblePlatformMessageDispatcher.Update(BusinessEntity entity, FilterExpression filter, ExecutionContext context) ilOffset = 0x5

    at BusinessProcessObject.UpdateWithPipelineAndExtensions(IBusinessEntity entity, ExecutionContext context) ilOffset = 0x78

    at AccountService.Update(IBusinessEntity entity, ExecutionContext context) ilOffset = 0x37


>Web Service Plug-in failed in SdkMessageProcessingStepId: {32750CB3-CFDC-DB11-8341-0019B9204DA9}; EntityName: account; Stage: 30; MessageName: Update; AssemblyName: Microsoft.Crm.Extensibility.InternalOperationPlugin, Microsoft.Crm.ObjectModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35; ClassName: Microsoft.Crm.Extensibility.InternalOperationPlugin; Exception: Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.

Inner Exception: System.InvalidCastException: Specified cast is not valid.

at Microsoft.Crm.BusinessEntities.AddressTrigger.Update(Guid id)

at Microsoft.Crm.BusinessEntities.TriggersExtension.ExecuteTriggers(BusinessEntity entity, ArrayList triggers, OperationType operationType)

at Microsoft.Crm.BusinessEntities.BusinessProcessObject.DoUpdate(IBusinessEntity entity, FilterExpression filter, ExecutionContext context)

In this case, you can see that the user is attempting to perform the action against the account entity using the out-of-the-box plugin (Microsoft.Crm.Extensibility.InternalOperationPlugin).

2. If you look at the "Inner Exception" message, you will want to pay close attention to the top line. This indicates the last thing CRM was attempting to do when the error occurred (at Microsoft.Crm.BusinessEntities.AddressTrigger.Update(Guid id)). This last method in the error message tells us that there is an issue with the addresses assigned to the account in question. This information is stored in the CustomerAddressBase table in the organization database.

3. Upon further investigation, you might that there's a record missing from the CustomerAddressBase relating to the account record in the ParentId field in the table. By default, there should be at least two records for each ParentId entry differentiated by CusomterAddressId. This is then further differentiated by AddressNumber 1 and 2. As you might have figured out, 1 is for the Address 1 fields and 2 is for the Address 2 fields relating to the ParentId record.

4. So now to answer the question: "How do I fix this?" Well, the easiest way is to create a new record and merge the needed data over to a new record except for the address information. For the address portion, we suggest manually entering it into the new record's address information section or the merge will not work. You can take this same process one step further to identify any further records that may be affected by this particular issue by running the following query within SQL Server Management Studio.

select Name as
'Account Name',
from CustomerAddressBase where ParentId = AB.AccountId)

from AccountBase AB

where (select
from CustomerAddressBase where ParentId = AB.AccountId)
< 2

select FullName as
'Contact Name',
from CustomerAddressBase where ParentId = CB.ContactId)

from ContactBase CB

where (select
from CustomerAddressBase where ParentId = CB.ContactId)
< 2

In instances where these steps do not resolve the issue, we would encourage you to reach out to our support team as there may be additional issues causing this issue.

Happy CRM'ing!

Synchronizing Shared CRM Contacts with Outlook

What do you do when more than one CRM user needs to synchronize their Outlook contacts with the same CRM contact record? By default, the CRM Outlook Client is set to synchronize CRM contacts to Outlook contacts based on the owner of the CRM contact record. For CRM users who share contact records, this isn't the ideal solution.

Using CRM marketing lists is one simple alternative. The idea is to replace the default contact synchronization rule for each user with a custom rule that references a marketing list. The user can manage the contacts in the marketing list, regardless of who owns the CRM contact record (depending on the user's security role access level). The marketing list is then used to determine which CRM contact records should be synchronized with Outlook for that user.

  1. First, create the user's marketing list in CRM. Make sure to choose Contacts as the Targeted At type and Static as the List Type. Be sure to give the marketing list a descriptive name, such as "JOECRM Outlook Synchronization List". Be sure NOT to create a dynamic marketing list for the purpose of synchronizing with Outlook.

    Synchronizing Shared CRM Contacts

  2. Now, add the desired CRM contacts to the marketing list. Just as an example, the following screenshots show how to use advanced find to search for contact records owned by JOECRM or contact records whose department equals Purchasing. Of course, use meaningful search criteria that will meet your requirements or use the lookup option to manually select the contact records you want.

  3. Now that the marketing list is set up in CRM, open Outlook and navigate to the CRM Synchronization Outlook Filters menu. The example below shows how to do this in Microsoft Outlook 2013.

  4. Click My Outlook Contacts in the User Filters list.

  5. Change the filter so that it is using the marketing list that was set up in CRM and save the changes.

Now, all the Contact records that are in the JOECRM Outlook Synchronization List will synchronize to Outlook contacts for this CRM Outlook Client!

This is just a simple example of using marketing lists to synchronize CRM contacts with Outlook Ccontacts. As always, if you need assistance the CRM Experts at PowerObjects are here to help!!

Happy CRM'ing!

Creating a Contact with a Basic CRM 2011 Dialog

Want to learn how to create a prompt and response dialog in Microsoft Dynamics CRM? Then you're in luck, because today we'll walk you through how to use a dialog to create contacts in CRM 2011. Creating a contact via a dialog is handy because a dialog allows you to enter data efficiently without having to scroll down the contact record to fill in the fields. In this example below, you will learn a few tips and tricks that are helpful in creating a dialog.

  1. In your settings, go to Processes and select New to begin creating your dialog process.

    Create a basic CRM 2011 dialog

  2. Create a page that will collect information that you want to capture in the contact record.

    CRM 2011 Dialog

  3. Choose the Prompt and Response option to put in the details for the page.

    CRM 2011 Dialog

  4. For fields that are just single line text fields, you'll need to fill in the statement label, the prompt text, and also set the response type to single line. The prompt text is the title of the field that shows up on the dialog page.

    CRM 2011 Dialog

  5. For fields that are part of an option set, you'll have to follow different steps. Set the response type to be option set (picklist) and the data type to integer. The most critical part about this step is to make sure to match the response values on the dialog's page to that of the field on the contact record.

    CRM 2011 Dialog

  6. For option set fields that have two radio buttons, you have to pick the response type to be option set (radio buttons) and match the response values to that of the contact record.

    CRM 2011 Dialog
    CRM 2011 Dialog

  7. After creating the page, you'll have to add a step to create the contact and set the properties for that step by matching the responses on the page with those on the contact record.

    CRM 2011 Dialog
    CRM 2011 Dialog

  8. As for the radio buttons, you'll have to add a few additional steps. You need a condition to see that the response values on the page matches the ones on the contact record as well as update the contact record. At the end of this step, you can save the dialog and activate it.

    CRM 2011 Dialog
    CRM 2011 Dialog

  9. To test the dialog, first check for contacts and select one of them. Then run the dialog.

    CRM 2011 Dialog
    CRM 2011 Dialog

  10. Once the dialog is done running, you will find the contact on the Active Contacts list.

    CRM 2011 Dialog

So there you have it—now you can create all your contacts with a dialog in CRM 2011!

If you want to learn more about dialogs, or about processes in general, a good blog to reference is Workflows and Dialogs: What's the Difference? And as always, if you get stuck or confused while working with Dialogs, contact PowerObjects.

Happy CRM'ing!

How to Stop Automatic CRM to Outlook Syncing for Contacts

The Outlook Client for Microsoft Dynamics CRM keeps your users' inboxes from becoming silos of information that are accessible only to the user. One of the features of the Outlook Client is that it automatically syncs all the CRM contacts that user owns and creates contacts in Outlook. This automatic CRM to Outlook syncing can be a problem if the user owns thousands of CRM contacts. It can cause duplication if those contacts already exist as contacts in their Outlook. Once you configure the Outlook Client, it starts pulling the contacts down. Yikes! Can this be stopped? Yes.

Here are the high level steps of how to stop the madness of 20,000 unwanted contacts in your Outlook once you've installed and configured the Outlook Client:

  1. Stop the Outlook Synchronization
  2. Disable the Contacts filter in Outlook
  3. Re-start the Outlook Synchronization to allow CRM Activities to synchronize

I'm going to assume you know how to install and configure the client. The important part of this blog are the final three steps.


Here are the details. You've just completed the Configuration Wizard and are ready to launch Outlook. WAIT! Go to Diagnostics first. Following the steps below disables the filters for all the activities and contacts the client is designed to bring into the user's Outlook. This allows you to access Outlook without triggering a synchronization, giving you time to stop the filter that dictates what contacts will be brought into Outlook. You'll have to return here to turn the synchronization back on once you've disabled the Contact filter.

**NOTE: Turning this off does not stop users from being able to use the track functionality!**

For Windows 8 and 7 you can find Diagnostics by:

  1. Click on the Windows key
  2. Type Diagnostics in the search box
  3. Diagnostics should appear on the top of the list

For Windows 7 it can also be found by traditional means

  1. Click on Start menu
  2. All Programs | Microsoft Dynamics CRM 2011 | Diagnostics

The Microsoft Dynamics CRM Diagnostics window should appear. This is where you disable the synchronization process before opening Outlook.

  1. Uncheck Outlook Synchronization
  2. Click on Save

stop automatic CRM to Outlook syncing


The next step is to disable the Outlook Contact Filter. This can be done for both Outlook 2010 and Outlook 2007. The filters are the same, but the path to them is different:

  1. Open Outlook
  2. If you have Outlook 2007 installed, click on the CRM menu | Options


    If you have Outlook 2010 installed, click File menu | CRM | Options

  3. In the Set Personal Options dialog box, click the Synchronization tab
  4. Click on the Outlook Filters link

    crm to outlook syncing

  5. In the Outlook Filter dialog box, stop the Contact synchronization by selecting My Outlook Contacts and clicking on the delete button in the toolbar. This can be recreated in the future if the users would like the CRM contacts to come down.
  6. Click on OK


In order to make sure the CRM activities synchronize with Outlook, you must enable the Outlook Synchronization in Diagnostics.

  1. Follow the instructions in Step 1, except check the box this time.

Keep in mind that not every user will want to stop their CRM Contacts from syncing with Outlook. This means they might like to understand the interaction better. Check out this timeless blog on knowing the rules of the Dynamics CRM and Outlook Contacts interaction.

Happy CRM'ing!

Options for Storing Employees in CRM 2011

There are many reasons why an organization would desire to store employees in a customer-focused implementation of Microsoft Dynamics CRM. The most common reason is that employees (some being non-users) are a part of a process such as assigning a record to employees, notifying employees, or inviting employees to a meeting. In this blog we will discuss different options for storing employees in CRM 2011, as well as the considerations when doing so.

Note: Sometimes an organization will use Microsoft Dynamics CRM as a platform (a.k.a. XRM) to develop an HR application; however, this blog will not discuss that use.

Why Use Contacts
Using Contact records in Microsoft Dynamics CRM to store employees is attractive because it allows you to use some of the most powerful capabilities of CRM--for example, the synchronization of contacts between CRM and Outlook. CRM acts as a single list of employees that everyone can share and keep up to date. With synchronization with Outlook, then the employee list is in Outlook AND potentially on mobile phones and other devices if they are being synchronized with Microsoft Exchange. Often times, this is not an organizational decision, but rather users start putting their fellow employees in CRM to get this benefit.

In addition, mass communications to employees is easy using the CRM tools, such as Marketing Lists, Email Templates, and Mail Merge. Since only leads, accounts, and contacts can be on a marketing list, using the Contact record seems like a natural fit when an organization is hoping to reach out to their employees.

Lastly, "testing" of customer communications and processes is a common reason that employees end up in CRM as contacts. Whether sales, service, marketing or other processes, users commonly want to test on themselves or other employees before sending communications off to the client!

Email Tracking
It may not be recommended to keep employees as contacts in a customer-focused implementation of Microsoft Dynamics CRM because of the perceived problem of email tracking from Outlook. When you track an email from Outlook, it will track the email against the CRM record of everyone on the email (either sender or recipients). When you have an employee as a contact in CRM, that contact record will show all the email the employee ever sent or received under Closed Activities. You can see from the example below that this employee has 1122 emails in the closed activities on her contact record—many of which she may not be aware.

storing employees in CRM 2011

How does this happen? The person sending the email may track the email (on purpose or inadvertently) and the recipient may not know it is tracked. Once a single Email is tracked, the response and the entire chain may be tracked in CRM (depending on individual's Outlook CRM settings). Therefore, anyone on an email chain may send something thinking it is "confidential," but really it is being tracked in CRM for others to potentially see.

In the example below, these employees emailed their boss or their team about their absence—probably not anticipating the details could be shared in CRM.

Why is this just a perceived problem? Interestingly, this exposure of "confidential" emails is always a risk regardless of whether employee records are stored in CRM because employees can always track email in CRM without the sender or recipient knowing it. All the employee contact record does is "catch" these tracked emails and aggregate them under closed activities, which can create an alarming feeling when the employee sees it!

Email Duplication

Now, database administrators might be looking at this kind of email tracking with concern about how often the same email is being duplicated. When an email is tracked in CRM, it is NOT duplicated for each contact it is tracked against. A single email is merely 'related' to each contact. However, there is increased potential for duplicate records when you have employees in CRM. That is because when an employee sends and email to another employee and tracks the email, it may be tracked again when the 2nd employee receives the email.

If You MUST Track Employees in CRM

If you must track employees, there are some options for you to avoid the email tracking conflicts described above.

Option 1 – Use Contacts but Create Email Aliases
Use the contact record for employees, but create an email alias for each employee that is used only for CRM. Since CRM uses an exact match on email address in order to identify which contact to track email against, an alias will fool it. The email will not be tracked against the employee UNLESS it is Set Regarding the employee contact directly.

Option 2 - Use Users
Some organizations are uncomfortable with a single person having two records (Contact and User). To resolve this, they enter all employees (even non-Users) into CRM as users and then deactivate the users who do not need licenses. If choosing this route, employee lookups would need to be modified in order to include inactive records. This may make some tasks difficult, such as updating the employee records, either with workflow or manually. Since they are inactive, then they would be read-only.

Option 3 – Creating a Custom Entity
By creating a custom entity for employees, it gives you the flexibility to edit the records easily, but also to NOT have to create an email alias. Custom entities can be email-enabled so that email notifications can be sent manually or via workflow.

Final Thoughts

In considering how best to store employees in Microsoft Dynamics CRM, don't forget to consider security. Determine who needs to access (view, edit, and delete) employee records, and who does not need to access. If you repurpose contacts or users for employees, you will have less control over security because your security model must support multiple uses of the same entity. By creating a custom entity for employees, you can control the rights separately.

Make every effort to build your knowledge of by checking out the latest Education and Training Events related to Microsoft Dynamics CRM.

Happy CRM'ing!

Microsoft Dynamics CRM Data Import – Setting Primary Contact Field #2

This is the second installment of a two part series on setting primary contact field in Microsoft Dynamics CRM. You may want to read the first installment before continuing on.

Another option to resolve this issue importing accounts and contacts is a new feature in CRM 2011. The Data Import has the ability to import Accounts and Contacts at the same time. We will walk through the steps of how to accomplish this task in CRM2011.

Step1: Create two .CSV files, one for your Accounts and one for your Contacts.

If possible have a unique id for each record in your spreadsheet. This will allow you to use this value to build the relationship between the Accounts and Contacts. The reason behind this is if you have any duplicate contacts or accounts within your spreadsheet the import will fail on these records.

You may also choose to download a template from the Data import. This will help you with mapping process.

Accounts Example:

Contact Example:

Step 2: Once you are ready to give your files a try, add them to a zip file.

Step 3: In CRM 2011, start the Data Import and browse to your zip file that you created above. Select Next and Next after you have reviewed the settings.

Step 4: Select the Default (Automatic Mapping) from the System Data Maps

Step 5: Now we get to select what entities we are going to import into. Select the Account and Contact entities from the drop downs.

Step 6: You now get the ability to map your fields. Start with your Accounts until you get a green check mark next to the Account label.

Step 7: When you get to the Primary Contact field, select the lookup icon. Here you can change the look up field. In this example will use the Contact name.

This is where you could use the unique id. This would allow you to map the contact to the correct account if you have duplicate records.

Step 8: Complete the same steps for the contacts. Once again you could change the lookup field but we will leave this as the Account name.

Note if you do want to use a unique id, you would need to map the unique field to the parent customer. Then select the id field from the account entity that you populated in the above step.

Step 9: The summary screen appears select Next and the Submit to start the import process.

Step 10: You can review the import process by browsing to the Workplace, then Imports.

From there you can look at what did import successfully, the partial failures and the failures may have occurred.

Here is an example error message that you could receive if you have duplicated accounts.

Hope this helps. Remember, you can always call in a dedicated Microsoft Dynamics CRM Partner if you find your import too complex to do on your own.

Happy CRM'ing!

Dear JoeCRM – Contacts are Crazy!

Dear JoeCRM,

I am Manager in charge of deploying our new Microsoft Dynamics CRM 2011 and moving our old contact data from previous systems. We have contacts in Outlook, legacy databases, Excel sheets and scribbled in post-it notes. How do we move the contacts to CRM without losing any data but without duplication? Please help me!

-Stressed Out

Dear Stressed Out,

Here is a 6 step program for you:

1.    Admit your data is a mess

2.    Realize there are capable CRM consultants that can help you

3.    Meet with the CRM consultants and present the problem

4.    Work with them to build a plan for data migration

5.    Learn Yoga while CRM consultants execute the plan

6.    Enjoy the clean migrated data and the new "relaxed" you.

Check back regularly for more 'Dear JoeCRM".

# CRM Expert, Microsoft Dynamics CRM

Microsoft Dynamics CRM Data Import – Setting the Primary Contact Field #1

In Microsoft Dynamics CRM 2011, the out of the box import tools have been greatly improved. We recently worked with a client to import their Accounts and Contacts from a spreadsheet. Best practice is to import your Accounts first, then import your Contacts. The reason behind this is to allow the import process to associate the Contact to the Account. But while reviewing the data the client noticed that the primary contact field was not populated on the Account form. Since the contacts don't exist yet, there was no way to populate this field while importing the Accounts. Below is a simple way to work around this issue for setting the primary contact field.

First create a new field in the contact entity, in my case I called it Primary Contact and set the field attribute to Two Options. You do not need to add this field to form, it simply needs to be available to update during the import.

After the field is created, create a new workflow that will use this new field to trigger the workflow. Make sure the workflow is set to be triggered when a "record is created".

The first step is to add a check condition to make sure the primary contact field equals "Yes"

CRM 2011 - setting the primary contact field

If that value equal yes, then the workflow will update the Parent Customer field in the Account entity. You can do this by selecting the contact has the Primary Contact field.

Microsoft Dynamics CRM Blog

The last step is to add a new column to your contact data spreadsheet. You can call this column "Primary Contact" and then you will need to set a value for each row.

Now when contacts are imported, the workflow will trigger and update the primary contact on the Account entity.

If you liked this, check out setting the primary contact field part 2!

Happy CRM'ing!

Toward a 360-Degree View of the Customer: Connections in CRM 2011

One common objective that businesses have when executing a CRM strategy is to attain that elusive "360 degree view" of its customer base. As such, Microsoft Dynamics CRM has been constructed behind the scenes as a complex web of related data: Accounts, Contacts, Activities, Opportunities, Marketing Campaigns, etc. To get the full picture of a customer, we need to see how each of these data elements relates to our customer's record.

Dynamics CRM has always allowed us to clarify such associations by creating relationships between records of different types: these relationships could provide answers to questions such as What is the nature of a contact's relationship with an account? or What was a contact's role in the landing of a particular opportunity? In CRM 4.0, relationships could only be created to associate Contact, Account and Opportunity records: no other record types were allowed. We could not, for example, indicate what a contact's relationship was to a competitor or to a Contract or to any custom entity.

CRM 2011 introduces the notion of Connections between data records. The notion of Connections takes the old 4.0 concept of relationships to a new level. No longer limited to creating associations to the three standard entities (Account, Contact and Opportunity), we can now create connections between any two record types. Here's an illustration of this process.

Below is the record for one of our contacts, Mr. Johannssen. We've used CRM 2011's new subgrids feature to display Mr. Johannssen's connections on his contact form.

As we can see, Mr Johannssen is a former employee of the "Seaward Enterprises" account, and was in some way involved with two of our business opportunities. Recently we learned that Mr. Johannssen is also a former employee of one of our competitors, "Vicious Company." In CRM 4.0, we would have been unable to capture this association, but in 2011 we can.

In the ribbon toolbar, click the Connection button, and select To Another:

This brings up the Connection: New window. In the "Connect To" section of the window, click the lookup button in the Name field as indicated:

You now see the Look Up Record window. At the top of the screen, you'll notice that clicking on the picklist arrow for the Look for: field gives you a list of all CRM entities, meaning we can connect Mr Johannssen's record to any type of record.

We want to associate Mr. Johannssen to a Competitor record, so select "Competitor" here and look for the record "Vicious Company." Select by clicking the checkbox next to this competitor and click the OK button as illustrated below:

Vicious Company now populates the Name field of your Connection window.

Next click the lookup button in the As this role field and you'll see a list of available connection roles that a competitor record may be assigned:

Select the "Former Employer" role by checking the box next to Former Employer, then click the OK button. The Connection: New window now shows that Vicious Company is one of Mr Johannssen's former employers:

You might have noticed that, in the "Details" section of the window, the role for Mr Johannssen himself was automatically populated with the value "Former Employee." How did that happen?

When an you define Connection Roles
(by going to Settings à Business Management àConnection Roles), you have the opportunity to specify not only which entities a role applies to, but also what offsetting (or matching) roles it should have. Below is the definition window of the "Former Employee" role: as you can see, this role may be applied to Contacts and its matching connection role is "Former Employer".

This is why, when we selected "Former Employer" to associate our competitor Vicous Company to Mr Johannssen, the latter was automatically assigned the matching connection role, in this case, "Former Employee."

Back in the Connection: New window, we can specify the dates that apply to this connection. We've learned that Mr Johannssen worked for our competitor from May 4, 2009, to September 20, 2010:

we click the Save & Close button in the ribbon toolbar. We'll see that the new connection is reflected in Mr Johannssen's contact record.

In summary, CRM 2011's powerful Connections feature allows us to create associations between any two record types in the system. We can tailor connection roles to one or more of these record types, and we can create automatic matching roles. This marked improvement of the old Relationships feature found in previous versions, takes us a huge step closer to realizing our objective of providing the CRM user a 360-degree view of our customers.

Hope this helps explain this new feature in CRM 2011 – if we can be of assistance please let us know! PowerObjects

Happy CRM'ing

Bulk Editing the Parent Customer Field in MSCRM 2011

We recently had an implementation where the client had hundreds of Contact's in an ACT database but few were linked to an Account. They wanted to import them into CRM and setup up with proper parental relationships to the Accounts so that they could get global view of what was happening with each of their customers.

In a perfect world, there would have been time to add the proper account associations to the import file. Instead, the client decided it would be easier to clean up the data in the new system where several people could work on it at once.

The Contacts had a Company Name field, but they names were inconsistent between Contacts. For example, they might three contacts for Exxon, but they would be labeled as Exxon, Exxon Mobile and Exxon Europe. They might have an Account called Exxon, but the import process would only connect the Contact with the company that was an exact match and orphan the other two.

What to do?

In the cases where we didn't find an exact match on the Account, we imported the company name data into a temporary field called "Legacy Company". This allowed us to search for all records that had data in the Legacy Company field and a null value in the Account field.

We sorted by Legacy Company in order to group all the Contacts with similar Company names together. Unfortunately, CRM will not allow the Parent Customer field to be updated via the bulk edit feature.

To get around this, we added a temporary relationship to the Account entity (which can be updated via Bulk Edit) and workflow that sets the Parent Customer field equal to the Account. This allowed the customer to group many of the Contacts together for update instead of opening each record and modifying them one by one - a huge time saver.

When the client finishes associating the Contacts to the proper Accounts in CRM, the workflow can be deactivated and the fields for Legacy Company and Account can be removed from the form.

Just an example of some of the great stuff the MSCRM Experts at PowerObjects run into on a daily basis! If we can be of assistance please let us know!

Happy CRM-ing!

CRM 2011 Address Validation with County Data

PowerObjects has been implementing address validation by integrating to various web services for long time. We have had a need to implement county data as well, but most of the free web services do not return county information. So if we have a FIPS-list, or county/zip code list in-house, how can we integrate that to existing address validation? Today we'll take a look at CRM 2011 address validation with county data.

Here is what we did in one implementation:

First we created a CRM entity for counties and used the out of the box CRM data import to import the counties in:

CRM 2011 Address Validation

Brief re-cap on how our address validation works. We trigger the web service call on address change, usually on street 1, city and zip. Naturally depending on data we may get various levels of returns.

In most implementations, we also keep latitude and longitude updated based on the address and can show locations in maps. In this particular implementation, latitude and longitude was not needed.

Since databases are at flux and many users have to accept partial addresses, we give users the power to ultimately decide whether the address is changed to validated address or not.

For example: Key just a zip code, address validation will find city, state and zip based on that.

After address has been accepted by user, we have OData retrieve against county data triggering asynchronously, and will look for any counties matching the zip code. If only one match found, it will be filled in to county lookup. Note, the county is set here as lookup in order to show county as county name, yet gain access to FIPS code which is stored in the county entity.

Obviously entering more information will give you better results, for example entering street number and partial street: Address validation will find correct spelling of the street in addition to the state/city/zip9.

Now, it is possible that some zip codes span 2 or more counties and we need to give user power to select from list of possible counties. If our OData query finds multiple matches, we automatically trigger pre-filtered lookup window prompting user to select which county they want to use.

End Result:

Easy data entry with correct and uniform address data and minimizing chances for user errors = Happy Customer!

We hope that by providing this information we can help someone a little farther down the path to greater business productivity with Microsoft Dynamics CRM. If you want to work with the team that is the Microsoft Dynamics CRM Experts – please contact us at PowerObjects.

Happy CRM'ing