Microsoft Dynamics CRM 2013

If you are maintaining this today

CRM 2013 is out of support. Mainstream support ended on 8 January 2019 and extended support on 9 January 2024. Microsoft’s lifecycle page starts the product on 12 January 2014.

The two releases in this family ended at different times:

Release	Version	Support ended
CRM 2013	6.0	12 July 2016
CRM 2013 Service Pack 1	6.1	9 January 2024

So a system still on 6.0 lost support in 2016, not 2024.

The other trap is solution compatibility. From this release on, a solution exported from a newer version cannot be installed into an older one, and that includes minor versions. Service Pack 1 added the option to export a solution targeted at 6.0, which leaves out any components 6.0 cannot use.

Upgrading into CRM 2013

The whole chain from CRM 3.0 to 9.x, with interim upgrades and supported SQL Server versions, is on on-premises upgrade paths.

Source: Microsoft’s archived CRM 2013 implementation guide, “Upgrading from Microsoft Dynamics CRM 2011 and 2013”.

• Only CRM 2011 can be upgraded. CRM 4.0 has to go to CRM 2011 first, which Microsoft allowed with a trial product key.
• The 2011 server must be on Update Rollup 14 or later. Update Rollup 6 was also accepted but not recommended. Any other rollup fails with an error saying the installed version cannot be upgraded. Outlook clients needed Update Rollup 12 or later to connect to a 2013 server.
• Base and extension tables are merged. Every entitynameBase and entitynameExtensionBase pair becomes a single table. On a large, heavily customized database this can take hours, and it can be run as a separate operation to shorten the outage.
• An entity with more than 1023 attributes blocks the upgrade. Extra attributes must be deleted first, otherwise the upgrade fails with CREATE VIEW failed because column 'column_name' in view 'view_name' exceeds the maximum of 1024 columns.
• Custom database objects should come out first. Triggers, statistics, stored procedures and some indexes are all affected, because the database design changes between major releases.
• Some 2011 components are not upgraded: Reporting Extensions, the E-mail Router, the List Component for SharePoint Server and the Connector for Microsoft Dynamics. Microsoft recommended removing them before upgrading.
• Other 2011 servers are disabled once the first server is upgraded, until each of them is upgraded too. An in-place upgrade upgrades only the organization you name. The others are disabled until upgraded with Deployment Manager.
• Free space: Microsoft recommended at least three times the size of each organization’s database file and four times its log file, and noted that the files do not shrink back afterwards.

What changed for customizers

Source: Microsoft’s archived CRM 2013 “What’s new for developers”.

Area	CRM 2013	What came before	Modern equivalent
Automation	Real-time (synchronous) workflows alongside asynchronous ones	Asynchronous workflows only	Classic real-time workflows, with Power Automate recommended
Custom messages	Custom actions	Plug-ins on existing messages only	Custom APIs and custom process actions
Guided process	Business process flows	None built in	Business process flows
Sharing	Access teams, which have access to records but do not own them	Owner teams and sharing	Access teams
Compatibility	CRM 4.0 plug-ins, scripts, workflow activities and the 2007 endpoint no longer supported	2011 still ran much 4.0-style code	Not applicable

CRM 4.0 compatibility ends here

Sources: Microsoft’s archived CRM 2013 topics “Prepare your solutions for the update”, “Upgrade scripts to Microsoft Dynamics CRM 2013” and “Upgrade plug-ins and custom workflow activities”.

CRM 2011 kept a lot of CRM 4.0 code running. CRM 2013 officially dropped support for:

• CRM 4.0 plug-ins
• CRM 4.0 client-side scripting
• CRM 4.0 custom workflow activities
• the CRM 4.0 web service API, also called the 2007 web service endpoint
• ISV folder support for custom web applications

This is the upgrade that breaks old code, so it is worth knowing what changed. Microsoft recommended bringing the code up to CRM 2011 standards before upgrading an on-premises or IFD organization.

Form scripts. Anything that uses the 4.0 object model, including crmForm, must move to Xrm.Page. Xrm.Page.context.getServerUrl gave way to getClientUrl. Xrm.Page.context.AuthenticationHeader existed only to call the 2007 endpoint and went with it. Microsoft published a Custom Code Validation Tool to flag these, with the warning that it cannot find every problem and raises some false positives. The longer history of form scripting is on crmForm to Xrm.Page to formContext.

Plug-ins. The compiler shows most of the changes once the old SDK assemblies are swapped for Microsoft.Xrm.Sdk.dll and Microsoft.Crm.Sdk.Proxy.dll:

• The IPlugin.Execute signature changed, and so did the way you get the execution context and organization service.
• CallerOrigin was removed from the execution context and replaced by IsExecutingOffline and IsOfflinePlayback. IsInTransaction tells you whether the plug-in is running inside the database transaction.
• Plug-ins should catch FaultException<OrganizationServiceFault>.
• Some messages were replaced. For example, AssociateRequest replaces AssociateEntitiesRequest.
• Assemblies must be signed or delay signed.

Custom workflow activities now inherit from CodeActivity and take a CodeActivityContext. They use Microsoft.Xrm.Sdk.Workflow in place of Microsoft.Crm.Workflow, so InputAttribute replaces CrmInputAttribute. Their name and group name are set when the assembly is registered, not when it is compiled.

Microsoft’s pages disagree about the 2007 endpoint

The CRM 2013 script upgrade topic says the 2007 endpoint “is removed in this release”. The CRM 2013 topic on what is changing in the next release says it “was deprecated in CRM 2013 and will be removed in the next release”. Both are Microsoft’s archived documentation, and this page does not pick between them. Either way, code that calls the 2007 endpoint was unsupported on CRM 2013 and needed rewriting against the organization service or the OData endpoint.

Real-time workflows

Source: Microsoft’s archived CRM 2013 “Create real-time workflows”.

Real-time workflows let business users build something close to a synchronous plug-in without writing .NET code.

• They run in an event pipeline stage, like synchronous plug-ins: before the core operation (pre-operation), after it (post-operation), or during it. One that runs during the core operation is how a custom action is implemented. Within a stage, plug-ins and real-time workflows are ordered together by rank.
• They run immediately rather than being queued, whether started on demand or by an event.
• They run inside the current transaction. An activity that throws an exception cancels the core operation and rolls it back if it has already happened. Asynchronous workflows triggered by the same event do not run.
• They cannot contain wait or delay activities, and cannot run on retrieves. Every other supported message maps to create, update or delete: an assign or a set-state is an update.
• They run as the calling user or the workflow owner. A real-time workflow started on demand always runs as the calling user.
• Errors are logged only when you ask. With SyncWorkflowLogOnError set, errors are written to ProcessSession records. Real-time executions are not logged as system jobs.
• They convert to asynchronous and back while in draft, as long as they contain no wait or delay activities.

Activating one needs the Activate Real-time Processes privilege (prvActivateSynchronousWorkflow). Microsoft recommended granting it only to a small, experienced group, because these workflows affect core operations. CRM Online supported real-time workflows, but only when built in the web application: XAML workflows were for on-premises and IFD servers only.

What a real-time workflow should become today is on What should my classic workflow become?

Custom actions

Sources: Microsoft’s archived CRM 2013 “What’s new for developers” and “Create real-time workflows”.

Actions are custom messages with their own request and response classes, callable through the web services. The intended uses were adding new operations to the organization service, and combining several requests into one. An action’s core processing is a real-time workflow that runs during the core operation.

Business process flows

Source: Microsoft’s archived CRM 2013 “Model business process flows”.

A business process flow puts stage-and-step controls at the top of a form to guide users through a process, and can span several entities, for example opportunity to quote to order.

• They are a workflow category, alongside action, workflow and dialog. One must be activated before use, which needs prvActivateBusinessProcessFlow.
• Enabling an entity is one-way. An entity takes part only when IsBusinessProcessEnabled is set, and that cannot be undone. Custom entities and entities with the updated forms can take part.
• Participating records carry ProcessId and StageId.
• The limits: 10 activated flows per entity by default, adjustable through Organization.MaximumActiveBusinessProcessFlowsAllowedPerEntity, though Microsoft warned that performance may suffer above 10. Also 30 stages, 30 steps per stage, and 5 participating entities, none of which can be changed.
• Required steps cannot be set in code. A step is made required in the designer.
• Switching process starts from the beginning.

Also in CRM 2013 (6.0)

Source: Microsoft’s archived CRM 2013 “What’s new for developers”.

• Entity images on certain system entities and all custom entities.
• Field-level data encryption for sensitive values.
• Asynchronous solution import through ExecuteAsyncRequest, which at the time supported only ImportSolutionRequest.
• Authentication for mobile and rich clients on the OData endpoint, which had previously accepted only script running in web resources.
• AttributeMetadata.AttributeType deprecated in favour of AttributeTypeName, because the new image attribute type has no value in the old enumeration and reports Virtual.
• Read-optimized forms removed.
• Duplicate detection on create and update was not available in the updated forms. Bulk detection still worked. Service Pack 1 restored it.

Service Pack 1 (6.1)

Source: Microsoft’s archived CRM 2013 “What’s new for developers”.

CRM 2013 Service Pack 1 shipped alongside CRM Online Spring ’14.

• Export a solution for 6.0, as described above.
• Custom state model transitions for cases and custom entities: extra conditions on top of the default mapping between State and Status.
• Cases could be merged with MergeRequest, joining account, contact and lead, and could be linked in hierarchies.
• The Package Deployer, to deploy several solutions and data files as one package.
• XRM Tooling, new APIs and a common sign-in control for Windows client applications.
• An updated Plug-in Registration tool, moved out of SDK\Bin into SDK\Tools\PluginRegistration along with the Plug-in Profiler.
• Discovering the OAuth endpoint at run time instead of hard-coding it.
• Public and private queues, the recommended way to control access to queues.

Changes Microsoft announced for the next release

Source: Microsoft’s archived CRM 2013 “What’s changing in the next release”.

These were plans published during CRM 2013’s life. Check them against the CRM 2015 page rather than assuming they all happened.

• Support for Internet Explorer 8 and 9 was being dropped.
• getServerUrl, isOutlookClient and IsOutlookClientOnline were to be removed, in favour of getClientUrl, client.getClient and client.getClientState.
• Xrm.Page.ui.getFormType would stop returning 5 (Quick Create) and 11 (Read Optimized).
• Forms upgraded from CRM 2011 would be removed on upgrade, but only if deactivated. The upgrade would be blocked while any old form was active.
• The Kit product type would be deprecated.

What this page still needs

Written from Microsoft’s archived CRM 2013 developer and implementation documentation and its lifecycle pages. Not yet covered, and not guessed at: the new form scripting methods in detail, the security model beyond access teams, and on-premises infrastructure requirements.