Before you get started, here are a few things to keep in mind.
Dynamics CRM is a basic web user interface fronting a SQL Server database that manages relational data. However, it is flanked by a built-in array of basic analytical tools and extensive administrative features, such as auditing, which give it enterprise-level credentials. Throw in a customizable user interface (UI), and you have a tool that is capable of supporting both small businesses and multinational corporations. So it would be logical to assume that Dynamics CRM has a developer-friendly, structured architecture to support customizations.
However, the reality is a little more complicated and brings up some curious paradoxes about Dynamics CRM. Read More…
There are three basic versions of Microsoft Dynamics CRM 2013, and each has its own particular licensing requirements:
- Microsoft Dynamics CRM 2013 On-Premises: Most useful for organizations that do their deployments in-house. You must purchase a license for each server that will run the CRM Server software. You must also purchase Client Access License (CAL) for each user or device that will access the software.
- Microsoft Dynamics CRM 2013 Online: Used for solutions that will be hosted in the cloud. You must purchase a User Subscription License (USL) for each user that will access the solution. USLs are assigned to a named user, which means that USLs cannot be shared. A single USL licenses the user to access any instance of Microsoft Dynamics CRM 2013 or earlier associated with the same tenant. (USLs do not include use rights for Yammer or Skype.)
- Microsoft Dynamics CRM 2013 SPLA: Used by service providers and independent software vendors who license CRM to provide solutions to customers. You must purchase a Subscriber Access License (SAL) for each unique individual user who is authorized to access or otherwise use the licensed products. SALs are assigned to a named user, which means that SALs cannot be shared. A SAL will authorize a user to access any number of instances of CRM 2013 or earlier running on the organization’s servers. Read More…
First off, let’s clear up a misconception that everyone generally has the first time they hear about Dynamics CRM: it’s not “Dynamics versus SharePoint,” it’s “Dynamics AND SharePoint.” Dynamics CRM offers some pretty significant benefits that are not available when using the SharePoint platform alone. Likewise, SharePoint has capabilities that Dynamics CRM simply wasn’t designed to even begin to replicate. The trick is knowing when and how to best leverage the benefits of each tool. Simply put, both tools need each other to offer a truly complete platform that offers you the best of everything: a collaboration tool, an intranet and content management tool, a repository for unstructured data, an application platform, and a quick and easy way to rapidly and efficiently build applications to manage structured data. Read More…
I just finished working on a proof of concept using Microsoft Dynamics CRM 2011. The application needed to support the activities of a crime investigation unit in the government.
As a devoted Lennie Briscoe fan, I felt I knew my way around a crime scene…but what I didn’t know was CRM. As it turned out, it didn’t matter! Microsoft Dynamics CRM 2011 was fairly easy to get up and running. I put together a cloud-based implementation that included:
- CRM Online w/Office 365
- Azure VM for the installation of the e-mail router
- SMTP Server: SendGrid
- POP3 server: Gmail
All were “free” (free as in “trial”). All were in the cloud. All played nicely together.
That said, there were several confusing bits to sort out regarding the e-mail configuration. I’ll share what worked (and what didn’t work) for me. Maybe it can be a timesaver for you. Read More…
With more and more companies adopting both Dynamics CRM and SharePoint into their corporate technology stacks, I’ve found myself integrating the two technologies more often than ever before. It’s quite cool. These are two extremely powerful systems and they both do what they are designed to do very well. I’m not going to go in-depth about what the differences are between these products…they are in totally different software “genres.” Apples and oranges. However, I want to point out one thing SharePoint gives you that many clients ask for again and again: Subsites.
Subsites are SharePoint sites that belong to a root SharePoint Site Collection. An example of this would be a corporate intranet SharePoint Site Collection (https://intranet) with SharePoint Subsites for each division in the corporation, e.g. Marketing (https://intranet/sites/marketing), Accounting (https://intranet/sites/accounting), etc. There are pros and cons to breaking these Subsites out into their own Site Collections (so they can have their own content database), but quite often you see this hierarchical approach.
Another very common use of SharePoint Subsites is for things like item level management, for instance a project. You may have a SharePoint Site Collection named Projects (https://projects), and you may require a new SharePoint Team Site for any new projects that come online so as to provide an environment where a team can collaborate on said project, and maintain any data or documents about the project in a central location. This can best be described with URLs —https://projects/sites/Project1, https://projects/sites/Project2 and so on.
So how does Dynamics CRM play into my scenario? What if you’d like to leverage this same functionality for things like Accounts, Contacts or Leads? Pick an Entity from CRM — for the purposes of this blog the Entity is somewhat arbitrary, but we’ll use the Account Entity so we have something to focus on. Every new Account I create may or may not require an environment where teams can collaborate and store data and documents for this new Account. Dynamics CRM gives us SharePoint Document Management out of the box. But what if I need more? What if my company maintains a site ‘template’ that can be used to create a new, standardized website (SharePoint Subsite) for any new Accounts that come online? A place where a team can collaborate and have the freedom to deal with unstructured data and content in a central location?
In this blog I’ll show you how to leverage the SharePoint Client Object Model in a Dynamics CRM Plugin to create a SharePoint Team Site for new Accounts that come online.
We recently deployed a five-node CRM 2011 topology using Windows Azure IaaS with the following objectives:
- Understand how a multiple node CRM setup can be provisioned using Windows Azure IaaS. Specifically, how the networking capabilities offered by the Windows Azure platform (i.e. stateless load balancing) map to the CRM requirements.
- Develop an automated way to provision and de-provision a CRM setup. This is not only useful for dev and test scenarios, but also for production scenarios where it is notoriously difficult to conduct capacity planning before acquiring the necessary hardware. For example, it is hard to know upfront what CRM functional building blocks (aka CRM roles) the business stakeholders will want to focus on, such as async processes, sandbox, reports, etc. By dynamically scaling out the “needed” features on demand, we can enhance the business agility of the CRM.
- Offer our customers an educated choice between CRM Online (no setup costs but less control) and CRM On-Premises (extensive setup costs but complete control).
- Take advantage of hybrid apps that combine CRM capabilities with Windows Azure services, such as Windows Azure Active Directory, mobile services, etc.
This functionality is apparent in a couple of different places in the CRM 2011 web interface. First, there is a page under the Settings section for Document Management. Second, some entities will have a Documents area available on their forms. Please see the screen shot in Figure 1 below. (Click on any image to see full-size.)
For this write-up, I’ll be focusing on the Document Management page and the required steps for configuring access to SharePoint 2010 as well as installing the SharePoint List Component.