How Complex is the Mapping of Field Data Types from Salesforce to Dynamics CRM (Part 2)

In Part 1 of this post, I enumerated all the SFDC field data types and how they map to Dynamics CRM field data types. I also provided the level of complexity for each type of mapping and some hints about how to implement the SFDC concepts/features into Dynamics CRM so a data migration can take place.

In the table below, I will go a little deeper and provide further details about the implementation workaround that will be necessary in order to migrate some of the SFDC field data types:

SFDC Data Type Dynamics CRM Implementation Workaround
Auto Number Dynamics CRM auto-numbering feature is only available for some OOB entities (Contracts, Cases, Articles, Quotes, Orders, Invoices, Campaigns, Categories and Knowledge Articles). In case you want to migrate Cases from SFDC to Dynamics CRM, you will not be able map the SFDC auto number field to the Dynamics CRM Case number (auto-number) field one and keep the SFDC value. The platform will not let this happen and will always create its own auto number.
What if you are required to migrate objects which the Dynamics CRM counterpart does not support auto-numbering?
What if you are required keeping the SFDC number?
Well, there are many options here:
1)        Create a custom auto-numbering solution leveraging a new sequence/auto-number entity as well as synchronous/real-time workflows.
2)        Create a custom auto-numbering solution using transactional plugins.
3)        Create a custom solution that leverages Auto-numbering web services
4)        Use a 3rd party tool
My fellow CRM colleague Salim Adamon provided here a list of some of the available resources for each of these options.
Once you chose and implemented the Dynamics CRM solution that best fits your needs, you can now proceed with the data migration and bring over your SFDC auto-numbering values for the different entities.
External Lookup Relationship There is no equivalent feature in Dynamics CRM. In order to display the external data, you need to implement an Integration with the external system.
Geolocation Geolocation data type in SFDC is a compound field that counts toward the org’s limits as three custom fields: one for latitude, one for longitude, and one for internal use.
You can think of creating two fields of Decimal data type in Dynamics CRM corresponding to the SFDC Longitude and Latitude fields so you can eventually migrate this kind of data.
Indirect Lookup Relationship There is no equivalent feature in Dynamics CRM. In order to display the external data, you need to implement an Integration with the external system.
Picklist (Multi-select) There is no equivalent to this feature in Dynamics CRM and you will need to design and implement a custom solution in Dynamics CRM.
Note that the Salesforce Picklist fields displays each value separated by a semicolon.
Let us discuss how you can possibly implement multi-select picklists.
You can design your solution around the concept of N:N Relationships in Dynamics CRM:
1)        Using a grid of associated records that represent the picklist values. Note that by configuring security, you need to make sure that users other than admins will not have the right to add/update/remove values in the grid.
2)        A custom solution where each picklist value from SFDC will correspond to a Dynamics CRM custom field of type Two Options with the Checkbox format.
You will need to implement some custom code that will maintain the relationships between the parent record and the associated records.
3)        A custom solution where you have a custom web resource designed so you can check different values.
You will need to implement some custom code (similar to what I described in the 2nd option) that will maintain the relationships between the parent record and the associated records.
Once you chose and implemented the Dynamics CRM solution that best fits your needs, you can now proceed with the data migration procedure.
Text (Encrypted) In this post, I talk about the encryption approach in both Dynamics CRM and SFDC platforms
Now, in order to migrate encrypted SFDC data corresponding to the Dynamics CRM default entity attributes containing sensitive information (e.g. Email, Password), you will need to:
1)        Decrypt the data
2)        Migrate the data into the Dynamics CRM platform which will take care of encrypting/decrypting that data whenever it’s saved or retrieved.
For other encrypted SFDC fields, you will have to:
1)        Decrypt the data
2)        Take a decision on either keep the data in clear text or implement a mechanism (through a custom solution) to encryption/decryption of specific data in Dynamics CRM
3)        Migrate the data into the target Dynamics CRM organization
Text Area (Rich) An SFDC rich text area presents the user with a WYSIWYG editing area. The aim is to reduce the effort for users trying to express their formatting directly as valid HTML markup. Creating rich text fields is not a native capability in Dynamics CRM but there are few free ISV solutions you can leverage to easily and quickly enable it such as TinyMCE or CKEditor.

This is probably not an exhaustive list of solutions/workarounds. There are tons of other resources that are just few clicks away so remember that Google is  your best friend 😉

Happy CRMing!

How Complex is the Mapping of Field Data Types from Salesforce to Dynamics CRM (Part 1)

During a data migration activity from Dynamics CRM to Salesforce (or vice versa), one can assume that the field data types in Dynamics CRM and the ones in Salesforce are somewhat similar and that the mapping will somehow be straightforward.

Is it really that easy? And how difficult are the transformations if any are required in order to move the data to Dynamics CRM?

In order to import Salesforce data, you need to eventually define Data Maps.

It’s true that you can leverage the Data Maps for Salesforce provided in Dynamics 365 or some other predefined Data Maps that you can find in the market for mapping your data from Salesforce to Dynamics CRM. However, these Data Maps are only available, obviously, for some Salesforce OOB objects (entities are called objects in Salesforce) such as Account, Contact, Opportunity, Lead, etc…

Now what will you do in case your client extended those OOB objects by adding custom fields?

What will you also do if your client created new objects that you will also need to migrate?

If this is the case, how difficult and complex will the data migration activity be?

In the table below, I am attempting to address the way data types should be mapped between both platforms and I describe any required transformation (if any) is needed.

You can find the list of Salesforce Data Types as per the Spring 2017 Release (v39) here.

You can find the list of Dynamics CRM Data Types as per the Dynamics 365 (Dec 2016) Release here.

SFDC Data Type Dynamics CRM Mapping Dynamics CRM Workaround Workaround Complexity
Auto Number Data Type: Whole Number
Field Type: Simple Field
Format Type: N/A
You need to implement a custom solution in order to have the equivalent of this feature. Complex
Checkbox Data Type: Two Options
Field Type: Simple Field
Format Type: N/A
N/A Simple
Currency Data Type: Currency
Field Type: Simple Field
Format Type: N/A
N/A Simple
Date Data Type: Date & Time
Field Type: Simple Field
Format Type: Date Only
N/A Simple
Date/Time Data Type: Date & Time
Field Type: Simple Field
Format Type: Date and Time
N/A Simple
Email Data Type: Single Line of Text
Field Type: Simple
Format Type: Email
N/A Simple
External Lookup Relationship N/A You need to implement a custom solution + integration with the external data source(s) in order to have the equivalent of this feature. Complex
Formula Data Type: Single Line of Text or Option Set or Two Options, Whole Number or Number or Decimal Currency or Date and Time
Field Type: Calculated Field
N/A Simple
Geolocation Data Type: Decimal Number
Field Type: Simple Field
Format Type: You can specify the level of precision and the maximum and minimum values
You need to implement a custom solution in order to have the equivalent of this feature. Moderate
Hierarchical Relationship Data Type: Lookup
Field Type: Simple Field
Format Type: N/A
Hierarchical: Yes
N/A Simple
Indirect Lookup Relationship N/A You need to implement a custom solution + integration with the external data source(s) in order to have the equivalent of this feature. Very Complex
Lookup Relationship Data Type: Lookup
Field Type: Simple Field
Hierarchical: No
N/A Simple
Master-Detail Relationship Data Type: Lookup
Field Type: Simple Field
Type of Behavior: Parental
N/A Simple
Number Data Type: Whole Number
Field Type: Simple Field
Format Type: N/A
N/A Simple
Percent Data Type: Decimal
Field Type: Simple Field
Format Type: You can specify the level of precision and the maximum and minimum values
N/A Simple
Phone Data Type: Single Line of Text
Field Type: Simple Field
Format Type: Phone
N/A Simple
Picklist Data Type: Option Set
Field Type: Simple Field
Format Type: N/A
N/A Simple
Picklist (Multi-select) N/A You need to implement a custom solution in order to have the equivalent of this feature. Moderate to Complex
Roll-Up Summary Data Type: Single Line of Text or Option Set or Two Options, Whole Number or Number or Decimal Currency or Date and Time
Field Type: Calculated Field
N/A Simple
Text Data Type: Single Line of Text
Field Type: Simple Field
Format Type: N/A
N/A Simple
Text (Encrypted) Data Type: Single Line of Text
Field Type: Simple Field
Format Type: N/A
See Part2 of this post Simple to Complex
Text Area Data Type: Multiple Lines of Text
Field Type: Simple Field
Format Type: N/A
N/A Simple
Text Area (Long) Data Type: Multiple Lines of Text
Field Type: Simple Field
Format Type: N/A
N/A Simple
Text Area (Rich) N/A You need to look into ISV solutions options in order to have the equivalent of this feature. Moderate
URL Data Type: Single Line of Text
Field Type: Simple Field
Format Type: URL
N/A Simple

Keep in mind that this can also be helpful when estimating the total migration effort. Both the number of custom fields to migrate and the data types of the custom fields that are involved will have a direct impact on the complexity of the data migration activity.

In the 2nd part of this post, I will provide some more detailed insights about the Dynamics CRM implementation workarounds that will be needed to migrate part of the SFDC field data types.

Hope you find this useful!

Happy CRM’ing!