One of our most popular blog pieces to date is our robust 4-part comparison of Salesforce vs. Dynamics CRM. Today, we’re going to take a slightly different slant. We will be comparing Salesforce development to development in Dynamics CRM.

Both Salesforce and Microsoft Dynamics are big players in the CRM market, and as a certified partner of both, we’re lucky enough to have a wealth of experience with both powerful systems. While working through different projects, it’s not always easy to see the differences between Salesforce and Dynamics CRM without significant effort, so we’re planning a series of posts that compare Dynamics CRM with Salesforce development; using the same project.

Our  development team has really strong experience in both Dynamics CRM and Salesforce development; as we have implemented, customized, integrated, and mapped a lot of different systems over the past several months. We see popularity rising in both systems, and are often asked by customers at the beginning of their selection process what the difference is in development of these systems.

Comparison – Dynamics CRM & Salesforce Development Project

The project in today’s example is fairly simple. Create a Kanban board allowing tasks to be dragged and dropped in another person’s queue or in another status. Since there isn’t a Kanban board object in either system, this will be a good comparison for creating custom objects. It will also be a good way to see how difficult it is to perform CRUD operations using JavaScript.

Salesforce Release – Summer ’15 Patch 15 – Developer Edition

From the home screen, click Setup.

In the Search Setup textbox, type package. Click the link for Create Packages.

Click New.

Fill in package info.

Click Save.

Now your package has been created. What do you think? Not overly difficult, right? A lot of Salesforce development operates this way. Not, let’s take a look at Dynamics CRM.

Dynamics CRM Online 2015 – Sandbox

From the main menu, click Settings.

In the settings sub-menu, click Solutions.

In the Solution List, click New.

This is the new solution screen before any info has been filled out. Click the magnifying glass next to Publisher.

If you haven’t set up a publisher, click Look Up More Records.

Click New to start creating a publisher.

Fill in the publisher info you’d like to use. The prefix will be the first characters before new entities in the solution, so choose something meaningful.

When you’re finished, click Save and Close.

Your new publisher should show up and be selected by default. click Add to use your new publisher. Now fill in the remaining solution fields.

Click Save and Close to create the solution.

Your solution should show up in the list of all solutions.

The differences in solutions in Dynamics CRM and Salesforce Development

In Salesforce, it’s called a package. In Dynamics CRM, it’s called a solution. Either way, they both aim to provide a way to bundle together a set of customizations and functionality. While conceptually similar, there are some significant differences to pay attention to.

Salesforce Package

Overall, the Salesforce Package experience seems a little lighter weight than its Dynamics counterpart. It’s not a big deal if you didn’t think about your package until after you’re done coding your app. It’s easy to add existing items, and there doesn’t seem to be a big difference which part of the process you’re wanting to group content into the package.

Dynamics Solution

In Dynamics, it’s more important to think through whether you’re going to be creating custom entities as system entities or if you’d rather have them included in a Dynamics Solution. While Dynamics does allow adding existing entities to a solution, the naming prefix that gets pre-pended when using a solution with a publisher doesn’t change. Also, when creating new entities or columns, I find myself navigating into the solution first before making any changes because the default behavior for customizations in Dynamics CRM is system-wide.

Mostly The Same

Both systems provide a similar end result when it comes down to it with Microsoft causing developers to think about whether they plan to publish earlier on. The next step is creating custom objects where we’ll see even more differences between how Salesforce and Dynamics approach the custom dev process. We’ll do this in our next installment.

If you’re interested in help selecting, implementing, customizing, or integrating either these powerful systems, let us help. We have a wealth of knowledge regarding how these systems work technically, but also understand the business processes that these technologies must support in the real-world to work the way businesses need them to. Reach out today, and let’s get started!