Reporting capabilities and limitations in both Dynamics CRM / 365 and Salesforce(PART 1)

In my previous experiences as a consultant, I’ve had the chance to help many of my clients address their reporting needs and requirements in the Dynamics CRM platform. More recently, I’ve also helped clients with the same need, this time, within the Salesforce.com platform. This allowed me to have a good understanding of both platforms reporting capabilities and limitations. Ultimately, I’ve built some nice dashboards that helped and allowed my clients better run their business.

Let’s start at the beginning and ask the question:. What does a Dashboard mean in this context? Like the dashboard in a car, which provides the driver with all necessary information, a dashboard in the business world is meant to provide a quick overview of the business in order to help with decision making.

Both Dynamics 365 and Salesforce.com provide the possibility to create some nice looking dashboards.

This is what a Dynamics 365 Dashboard might look like:

Dynamics 365 Dashboard

And this one is an example of a Salesforce dashboard:

Salesforce Dashboard

They look pretty nice….and similar, don’t they?

This might definitely help in a sales speech but you need to be careful and not look at the tip of the iceberg. Reporting is such an important piece of a business solution. You might need to dig a bit more (still at a higher level)  into your reporting needs before even choosing the platform. Typically both the client and the solution implementer (Service Provider) allocate a block of hours to the reports requirement, gathering activity and only build the reports and dashboards at the end of an implementation; often to realize that the platform does not really fit the client needs. As a client, you should be as clear as possible about your reporting requirements as well as the ones you are willing to sacrifice in case the platform does not support them.

In the Dynamics 365 platform, you can build OOB reports and dashboards. In addition, you can build custom SSRS reports, Power BI reports or also use Excel as a reporting tool. I personally never had the need to use the latter. Why would you want to still report in Excel if your platform  allows you to do it natively?

As a CRM consultant, I’ve always pushed my clients to use OOB reporting when possible. Some clients have requested really advanced and complex reporting needs (I usually smile when I remember some of them :D). Honestly, I was always able to build whatever my clients wanted within the Microsoft ecosystem. The capabilities are impressive, and sometimes amazes me of what is possible.

In Salesforce.com, you can also build OOB reports and dashboards. However, when I started using the platform for reporting, I was surprised with some of the platform limitations. I honestly expected better from the platform. I’ll talk in details about some of the limitations in PART 2 of this post and probably more in future posts!

One can argue that Salesforce.com is not a reporting platform. I am sorry, but remember the Dashboard definition above? Ultimately every organization’s goal when, for example, implementing a CRM, is to build some executive dashboards for displaying key performance indicators (KPIs) and effectively run their business. I’ve implemented reports and dashboards for almost every organization I dealt with.

So far, I find the Salesforce.com platform very limited when it comes to reporting. On the other side, Dynamics 365 reporting capabilities are not only impressive but also quite promising. Just think of the possibilities with having a built-in Office 365 (e.g. Power BI, etc…) and Dynamics for Operations (Microsoft’s ERP, previously AX) integrations and the promising CDS (Common Data Service) for building a solution with advanced reporting while having a 360° view of the customer!

Stay tuned for PART 2 when I talk in more detail about Salesforce reporting limitations…

Why doesn’t Microsoft Host World Tour Events like Salesforce?

A few days ago, I attended for the second time the Salesforce World Tour here in Toronto where the number of attendees exceeded three thousands (3k) people. While the food sucked and many people were  attending afternoon sessions with empty stomachs, I still asked the same question I asked myself one year ago: Why doesn’t Microsoft host large-scale worldwide events like these? I’m sure they would at least do a better job feeding their guests 😉

I was struck by how many people attended this event, initially thinking that they were all consultants, admins, developers, partners, etc.  However, after talking to few people, I realized that most of the attendees are either current users/clients, prospect customers interested in the platform or… Salesforce employees. Still, the Salesforce community is big and this kind of event is a great opportunity to bring everybody together (consultants, developers, etc. with users/clients) .

Let’s agree that Microsoft’s vision and roadmap under Satya’s new leadership is better focused, coherent and… promising. From my perspective as a CRM specialist, a good example is Office 365 and that from a relatively new and average Dynamics CRM 2011 product, Microsoft was able to build, in a relatively short timeframe, a best in class product/platform that beautifully integrates with a group of related services going beyond CRM.

Also, Microsoft is more and more perceived as a company that listens and cares, which was not the case just 5 years ago. Satya projects an image of a leader that is genuinely involved and cares about the community. Microsoft is also a more open ecosystem than ever before. Microsoft is turning into an open source company and the Microsoft community is growing faster than ever. Microsoft is creating partnerships like the one with Adobe and setting a great model for acquisitions. Think of what they’ve done when acquiring LinkedIn and having LinkedIn co-founder join the Microsoft board.

Hosting such events where community members (e.g. Azure/Cloud community, Office365 Community or CRM etc…) can meet and network, learn about new exciting products/best practices/partnerships/etc… is beneficial for all. It’s also an opportunity for non-community members to come and discover and learn about Microsoft’s products. Think of partners encouraging interested employees to attend even if their focus is elsewhere (Microsoft or non-Microsoft).  This is also beneficial for Microsoft as it’s a way to market its products and, most importantly, help strengthen that image they are trying to build (or at least I think they should build) of a company that cares.

Simply put, I think that Microsoft is missing these opportunities. Unfortunately, their events (conferences, trainings, etc…) are either too specialized, partners focused, long, or expensive. “Convergence”, the only Dynamics customer focused conference has been…discontinued! In my opinion, Microsoft needs to seriously start offering blitz learning and networking opportunities for its communities and customer base not only in the US but also the rest of the world like Salesforce has been doing for years. It’s okay if these events are short (bonus if they are free!).

Oh, and Microsoft; it wouldn’t hurt to serve some delicious food, too!

Who is better at protecting your cloud data: Dynamics 365 or Salesforce?

Encryption is needed to secure your data in the following two cases:

  1. When data is At-Rest (i.e. data that exist statically on physical media)
  2. When data is In-Transit or In-Motion (i.e. data that is being transferred between components, locations or programs, such as over the Internet)

In my previous post, I stated the fact that both Dynamics CRM and Salesforce use a secure channel for securing in-transit data. I also provided a description of the at-rest encryption approaches used by Dynamics 365 and Salesforce. Based on that analysis, I will discuss the approach and limitations of each platform and then, to summarize, provide a comparison of both approaches.

Salesforce approach, limitations and alternatives

In Salesforce, at-rest encryption is available within the platform. If you decide to go with the native Classic Encryption, then you will be limited and unable to encrypt OOB fields or existing custom fields. You will also not be able to perform the following on encrypted fields:

  • Search
  • Workflow Rules
  • Workflow Field Updates
  • Approval Process Entry Criteria
  • Approval Step Criteria

These limitations do not exist with the Shield Platform Encryption but this solution is not free!

Not to mention that both Classic and Shield Platform encryptions occurs at the platform’s application layer. This is also called Software-based encryption which achieves poor performance as it takes longer to encrypt/decrypt data at the application level.

Dynamics 365 approach

Actually, the answer for Dynamics 365 Online case is simple and straightforward! At-rest encryption is built-in with Office 365/Dynamics 365 which means that encryption is enabled by default with every new Office 365 deployment/implementation!! (see Built-in Security from Office365)

However, in Dynamics 365 On-premise, other than some entity attributes that are encrypted by default, the platform does not support encrypting other kind of data at the application level. In the On-premise cases you will need to make sure that at-rest encryption is enabled at the hardware level.

In fact, in both Dynamics 365 Online and On-premise cases, at-rest encryption is based on what we call hardware-based encryption. It’s important to know that this kind of encryption achieves increased performance compared to software-based encryption. This will also have the advantage of decoupling the encryption functionality from the application. It is also more flexible as there are multiple techniques that you might want to implement at the hardware level (e.g. see  Azure Data Security and Encryption Best Practices).

Summary

First, I personally think that, unless your organization has additional compliance and security considerations associated with planning for a Microsoft Dynamics 365 Online or SFDC deployment, there is no real need to rely on at-rest encryption for storing your data. Cloud data is stored in data centers (e.g. Azue, AWS) that usually implement advanced data protection and security practices. Check this page for some details about how Salesforce is protecting customer data in the cloud.

Now, for the Dynamics 365 case, it does not really matter whether you have compliance or security considerations or you don’t: The at-rest encryption in Dynamics 365 is enabled by default, achieves high performance and it’s free of charge!

Encryption approach in Dynamics CRM vs Salesforce

Encryption is the process of converting information or data into a code before it’s sent or stored.  This is especially performed to secure your data and prevent unauthorized access such as:

  • A DB Administrator trying to access the stored data
  • A sniffer trying to read the data being sent over the Internet

In fact, encrypting data before it’s stored is different from sending/receiving encrypted data over the network (e.g. Internet) through a secure channel (e.g. HTTPS).

Generally speaking, encryption is needed to secure your data on the following two cases:

  1. When data is At-Rest (i.e. data that exist statically on physical media)
  2. When data is In-Transit or In-Motion (i.e. data that is being transferred between components, locations or programs, such as over the Internet)

For the first case, both Dynamics365 (Online) and SFDC enforce a secure data transfer over the Internet.

Great!

Now that you know that your data is always secured (i.e. encrypted) when sent over the Internet, do you still require Dynamics365 or SFDC to encrypt your data when they store it locally (i.e. within their data centers)?

Let’s first have an overview of each product’s approach for handling the so called At-rest Encryption!

Dynamics 365:

For both Microsoft Dynamics 365 (online & on-premises), all new and upgraded organizations have data encryption activated. An encryption key is provided and can be easily changed by the administrator (The administrator should store this key in a safe location).

Microsoft Dynamics 365 uses standard Microsoft SQL Server cell level encryption for a set of default entity attributes that contain sensitive information (See details here), such as user names and email passwords. For more details about Encryption in Dynamics CRM you can watch this video or refer to this detailed post by my fellow CRM colleague Ben Hosking.

Salesforce:

In SFDC, fields are not encrypted by default, unlike Dynamics 365 which, OOB, encrypts a bunch of default entity attributes. However, you have the ability to pick which field to encrypt, with some limitations!

SFDC have two solutions for encryption: Classic Encryption and the Shield Platform Encryption. Below you can find a table that summarizes the main differences between both solutions. You can find the full list of differences here.

Feature

Classic Encryption

Shield Platform Encryption

Pricing

Included in base user license

Additional fee applies

Native Solution (No Hardware or Software Required) X  X
Encrypted Standard Fields  X
Encrypted Attachments, Files, and Content  X
Encrypted Custom Fields

Dedicated custom field type, limited to 175 characters

 X
Encrypt Existing Fields for Supported Custom Field Types  X
Search (UI, Partial Search, Lookups, Certain SOSL Queries)  X
Available in Workflow Rules and Workflow Field Updates  X
Available in Approval Process Entry Criteria and Approval Step Criteria  X

Check the following links for further details about Encryption in SFDC: Security Guide, Shield Platform, Encryption 101.

So, from a business perspective, the main limitations in the classic solution is the inability to encrypt OOB fields or existing custom fields. You also cannot perform search on encrypted fields. These are limitations that the Shield Platform Encryption solution address but with a price!

Oh well, this post is already getting too long!! I’ll stop here for now.

In my next post, and based on this preliminary analysis, I’ll provide a comparison of at-rest encryption approaches for both Dynamics CRM and SFDC. I’ll also discuss the alternatives to each approach’s limitations.

Happy CRMing!

 

 

 

 

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!