More About This Website

All information is provided "AS IS" with no warranties, and confers no rights

Powered by Squarespace

Connecting Mobile Apps to Dynamics CRM 2013

Earlier this month Mahesh Hariharan and I presented to the XRM Virtual ( user group on connecting mobile applications to Microsoft Dynamics CRM 2013.  If you weren’t able to watch it live there is a recording here 

During the talk we discussed how oAuth makes it much easier to connect to CRM from Windows, Windows Phone, iOS, Android and other platforms as long as they can do the oAuth workflow.  I showed a library to make it easier to connect from Windows Phone as one of the demos.  I’ve just uploaded the source code for that library to github incase it might help others get going.

You can find the library here -


Upgrading CRM Orgs via PowerShell

I recently blogged about creating CRM Organizations using PowerShell (here) another thing I’ve been doing a lot lately is upgrading.  When you upgrade an on-premise install of CRM 2011 to CRM 2013 only one organization will be upgraded during the installation process.,  So if you have let’s say 10 other test orgs on there you would need to do them one at a time in Deployment Manager which would drive you crazy. 

A better way to handle that is to use the Update-CRMOrganization command and do a batch of them without handling it one by one.

Here’s the syntax

Update-CRMOrganization –Name Dave1 –Upgrade

If you want to get fancy, the command gives you a GUID that you can use to monitor the progress of the process.  


Activate your MSDN Azure Benefits

I'm often amazed how many people with MSDN waste away their free Azure benefits - activate them here  -

And if that wasn’t a good enough reason, the fact you could win an Aston Martin should help…wish mine wasn’t already activated now!


Create CRM 2013 Orgs with PowerShell

ok, so creating orgs with Powershell isn’t new but something that’s often forgotten.  The reason I think it’s useful with CRM 2013 is with a new version you always want to play around and try things and that requires a few orgs to do it right!  If you have ever tried to create more than a couple orgs with Deployment Manager you know it is a lengthy process.  The nice thing about PowerShell is that you can queue up creation and walk away and let the server do all the work.  When you come back all of them are created.

Here’s a very simple snippet of PowerShell code that will create multiple orgs – you can obviously make it a lot more fancy but this does the job!

Add-PSSnapin Microsoft.crm.powershell

$nextOrg = 1

  $orgName = "Dave"+$nextOrg
New-CrmOrganization -DisplayName $orgName -SqlServerName crmdev -SrsUrl http://crmdev/reportserver -Name $orgName
while ($nextORg -le 20)

After it runs you should see something like the following which is the ID of the create request that will run.  One create happens at a time – you can monitor the progress via PowerShell or via Deployment Manager. 



Extending Dynamics CRM via Acquisition

Couple days ago Microsoft announced they acquired MarketingPilot – while I don’t know a lot specifically about MarketingPilot as a product, from a strategic point of view this is a big deal.  I don’t think it’s a big deal just because of the company acquired but because it signals to me a desire to fill product gaps by acquiring.  In the past, this was done via complicated alliances / IP licensing that just made it confusing to everyone should they use the built-in or the partner directly.  Acquisition is clean, product is absorbed into the core product and no confusion exists.  It’s also a fast way to fill gaps and add innovation in a proven way.

You can read the announcement by Bob Stutz the new corporate vice president for Dynamics CRM here


Choosing Smart Defaults for New Entities

When creating a new entity some of the choices you make will stick with you for the life of the entity.  Prior to CRM 2011 the general advice used to be turn on things if you think you might ever need them.  For example, Notes and Activities – in the past if you didn’t enable them there was not a supported way to enable them.

CRM 2011 changes this, most of the options like these in the Communication and Collaboration section can be enabled later.  The defaults though that come up have them enabled as you can see below:


The + sign next to an item indicates that once enabled it cannot be disabled later.  So what I recommend is unchecking all of them and only enabling it WHEN you need it.  Ideally in the future maybe the new entity form will get updated to not have those defaulted but until then take a few seconds and be smart about what you need!


CRM Client Extension Data Access Strategies

The following are the three primary options for accessing CRM data/services from a client side extension that is implemented as a web resource:

  • REST endpoint that implements the OData protocol
  • SOAP endpoint for web resources
  • Commanding Pattern using either of the prior options

Each of these approaches can be used regardless of HTML (with scripting) or Silverlight client extensions. Keep in mind for standalone client applications there are other considerations not covered.

Synchronous vs. Asynchronous

Requests from the client extension to the CRM server requests can be made synchronous or asynchronously. The best practice is to use asynchronous requests to ensure the best user experience. Synchronous requests by nature can block the UI. Developers like Synchronous requests because it simplifies the programming model. Similar simplification of Async requests using C# async /await support or a similar library for scripting often times minimizes the programming challenges.

REST Endpoint using OData

The REST endpoint implements the OData protocol ( to allow flexible access to CRM data. This supports basic data access (Create, Retrieve, Update,Delete) but does not allow execution of CRM service requests like Start Workflow, or any Meta Data access.

Use When

  • Low volume data access
  • Client side control of transaction is not required. By client side control of transactions this means where you need deterministic control if all changes are made or rolled back.

Avoid Use When

  • Interactions that require large number (typically > 10-25 at a time) requests to server
  • Interactions that require all to work or all to fail – you need a client controlled transaction
  • You need aggregate values – the SOAP endpoint is preferred then because you can run a Fetch Query
  • You need formatted values that are returned from the SOAP service or Option Set labels – or at least understand you need to handle this yourself.

It’s worth noting that while OData provides a flexible query pattern but can be slightly bloated in the size of data it returns. This can be mitigated using $select or by qualifying the data being returned.

SOAP Endpoint

The SOAP endpoint extends to the client the CRM Organization service giving access to both data and service operations. This includes the ability to query and modify CRM metadata.

Use When

  • You need access to CRM Services or Metadata
  • For basic data access OData is not working
  • When you want control of setting Related entities which can simulate a client side transaction. For example you could insert an Account and related Activities in one server interaction. This is only available for related entities to the primary entity being created/updated.

Note: SDK documents Deep Insert for the REST endpoint that can accomplish similar actions but it is not documented if this is within the scope of a transaction

  • Low volume data and service access
  • Client side control of transaction is not required beyond related entities

Avoid Use When

  • Interactions that require large number (typically > 10-25 at a time) requests to server, this is similar to the REST endpoint
  • Interactions that require all to work or all to fail – you need a client controlled transaction
  • For basic data access unless OData is not meeting needs

Commanding Pattern

The commanding pattern allows a client side requests to be communicated to the server and processed by a plug-in. The plug-in can run in a transaction and can perform one or more CRM service operations all of which would be included in the transaction. This pattern is best used when client extensions need to perform many server interactions or need support for client controlled transactions. This pattern also moves the chatty requests from client side with high latency to server side with low latency improving the total time to perform multiple operations. Additionally, if you have existing server code performing business logic, this pattern allows easy reuse.

The mechanics of this approach is a custom entity is created. Let’s call it “ServerCommand”. It contains at a minimum a RequestData attribute and a ResponseData attribute. The client extension using either OData or SOAP creates a ServerCommand entity instance populating the RequestData attribute. Server side a plug-in is created and registered against the Pre-Operation Create on ServerCommand. The plug-in looks at the RequestData does whatever work it needs to do and places the results in ResponseData. That work could be one or more service calls or data operations. Because this is done in the Pre-Operation stage of the event pipeline the response is written to the database during the create operation requiring no extra updates. Back client side, using the ID returned from Create the client extension would perform a read operation to get the ResponseData that was created by the plug-in. Server side you do need to bulk delete the completed ServerCommand records at some point.

Use When

  • You need client controlled transactions
  • You need to perform several operations
  • You need to server side logic
  • You want to shift processing to the server

Avoid Use When

  • You don’t need client controlled transactions
  • You are only making a few calls

Mix and Match

While it would be nice to suggest one single approach for working with CRM data / services, however as client extensions become more complex a single approach is likely not optimal. By using a mixed approach you can take the best of each of the patterns above as needed to provide the best user experience and meet the demands of the client extension.

Using a manager style class or other client side code pattern that hides the details of the implementation for each interaction with the CRM server client side developers can isolate the code and choices and giving flexibility for future changes. This technique is also helpful in larger client extension developed by multiple developers or where many client side extensions need the same interactions with the CRM server.

Wow, you made it to the end Smile  If you made it this far and have opinions drop me an e-mail.


Using Early Types across assemblies in plugins

It’s not uncommon for us to have are generated types in one assembly and have a plugin that uses the code that in another assembly.  When doing that CRM doesn’t do well with resolving the classes. 

To work around this you can give CRM a hint by setting the ProxyTypeAssembly.  To do this you must first get a reference to the IProxyTypeAssemblyProvider – we typically do this by casting the IOrganizationServiceFactory instance we get to that type and go from there.  Here’s an example of a helper method to get the Organization Service and setup the ProxyTypeAssembly prior to creation of the service instance.

public IOrganizationService CreateService(Guid? userID) 

            var factory = ServiceProvider.GetService(typeof(IOrganizationServiceFactory))
                        as IOrganizationServiceFactory;            
            var proxyProvider = factory as IProxyTypesAssemblyProvider;          
            proxyProvider.ProxyTypesAssembly = ProxyTypeAssembly;     

           return  factory.CreateOrganizationService(userID);            

ProxyTypeAssembly in this example would need to be the assembly that contains your generated classes.  Clearly I’ve stripped out any error handling and other good stuff from this method but you get the general idea.