This is the second part of my 2-part series, continuing our evaluation of the new Word Templates feature versus the traditional CRM/SSRS Reports route. Word Templates were recently introduced as part of CRM 2016, and are one of the big new features that has got me really excited about the future of CRM. What I am keen to discover is if they can be utilised as effectively as .rdl CRM Reports to produce high quality and professional looking documents.

Last week we took a look at the process and steps involved in setting up a Report. So now, let’s make a start and go through the step-by-step process of setting up a Word Template document on a CRM 2016 instance:

  1. From a setup point of view, there is much less that is required in order to start working with Word Templates:
    • CRM Online 2016: If you don’t have access to a CRM Online 2016 instance, you can either reset a Sandbox Instance or start a free 30 day trial. My understanding is that Word Templates have been introduced as part of 2016 On-Premise CRM, but I’m unable to confirm this.
    • Microsoft Word 2013/2016
  2. Log into your CRM instance and navigate to a supported record type. For this example, we are going to use Lead:WordTemplate_2
  3. On the Form Ribbon, click on the ellipse to expand the button Options and select ‘Word Templates‘:WordTemplate_4
  4. You will then be greeted with the ‘Create template from CRM data‘ window, enabling you to specify the template type you want to create (Excel or Word), confirm the entity data you wish to use and choose whether to upload an existing template or create one from scratch. We’ll click on Word Template and then press ‘Select Entity‘ to proceed:WordTemplate_5
  5. Finally, CRM will display an informational window which gives the user a quick summary of the different related record types and, therefore, what additional fields can be displayed on your Word Template. This can be quite useful for novice CRM users or for those who are unfamiliar with how a particular CRM system has been customised. When you are ready to continue, press ‘Download Template‘ and then save the document to your local computer:WordTemplate_6
  6. Once downloaded, open the template. You’ll be greeted with a blank Word document, similar to the below:
    WordTemplate_8

Don’t panic though! The document has everything we need to make a start, but first we need to ensure that the Developer tab is visible. To switch this on, you will need to:

  • Go to File -> Options to open up the Word Options window:WordTemplate_10
  • Go to Customize Ribbon and make sure that the Developer Tab check-box is ticked. Once this is done, press OK:WordTemplate_11
  1. On the Developer Tab, you should see a button called ‘XML Mapping Pane‘. Click this button to open up a new pane to the right of the screen:

WordTemplate_12 WordTemplate_13

  1. Under the ‘Custom XML Part’ dropdown, you should see an option similar to this (may be different depending on the entity that you are building the template for):

urn:microsoft-crm/document-template/lead/4/

Once selected, you should see all of your entity fields appear below:

WordTemplate_15

  1. With the XML Mapping configured correctly, our CRM data fields can be moved onto our Word Document. To copy across each field onto the Word Document, all you need to do is right click the field, select ‘Insert Content Control‘ and then ‘Plain Text‘. Your field will be added onto your empty Word Document into the cursor area:WordTemplate_16

WordTemplate_17

  1. Now we can start to build our report! Here’s one I made earlier, with the help of some of the existing templates that Word provides for Letters:WordTemplate_18

With our document completed, we can now save it and upload it into CRM. To do this, we first need to navigate back to the ‘Create template from CRM data‘ from step 4) and, this time, select ‘Upload‘ instead of ‘Select Entity‘ to be greeted with the document upload window:

WordTemplate_20

  1. Once we have uploaded our document, we can then select our newly uploaded document from the Word Templates button on our Lead form to download the document, populated with our specific record information:WordTemplate_21 WordTemplate_22

Conclusions

So is it time to ditch .rdl Reports in favour of Word Templates then? I would certainly say so for instances where you just want to create documents which require very little data manipulation and where the key focus is around presentation of the document. Microsoft Word is certainly a much more accessible tool than SSRS when it comes to quickly creating documents that look visually appealing. That’s not to say that .rdl Reports will not still have a role moving forward, particularly when requirements are a little more complex. For example:

  • You need to use a customised FetchXML report to return data that is filtered a certain way or is, for example, returning multiple <link-entity> fields.
  • You are wanting to develop a report that a user needs to be able to filter at report run-time.
  • You need to leverage some of the advanced functionality made available via SSRS Expressions.

I therefore do not foresee a massive exodus towards Word Templates in the near future. It is more likely instead that Word/Excel Templates become the “preferred” report building tool, whereas .rdl Reports instead are used for “advanced” scenarios. I certainly am looking forward to using Word (and indeed Excel) templates moving forward and, as part of this, ensuring that some of our CRM Super Users receive training on how to use the feature as well. Giving users the power to create their own reports, using the tools they know and use every day, is very exciting!

One observation I had in regard to Word Templates is that Word would occasionally hang on my computer for approx. 15 seconds when moving some of the fields from CRM around the document. I am guessing this delay might be caused by the fact the document is attempting to connect back to your CRM instance on regular intervals. Apart from that, there were really no issues in terms of usability and setup – everything was really straightforward, quick and familiar. These are most certainly the key experiences that Microsoft are aiming for as part of this new feature, and I am reasonably confident that any teething problems will be addressed swiftly so as to encourage as many people as possible to start using this feature moving forward.

For those who have done a lot of work previously creating bespoke document templates within CRM, the only effective way in which you would traditionally do this within CRM was via a Report. For the uninitiated, reports are .rdl files that are created within CRM (for very basic reports) or via SQL Server Data Tools (for more complex/bespoke reports).

Dynamics CRM 2016 has potentially flipped this approach on its head with the introduction of Word Templates. Now, you can use Microsoft Word to develop and customise a template that can then be populated with the information you need from a CRM record. Given that Word is a far more accessible and familiar tool for many people, this new feature could be a game changer and major boon to CRM Administrators and Developers.

Having worked myself with SSRS a lot previously to create .rdl reports (and developed quite a fondness for it as a result), I am really interested in seeing whether it is more efficient and easier to use Word Templates compared to a .rdl report. So let’s find out by creating a very basic custom introduction letter that a business could use to generate for a Lead record. We’ll attempt both methods to see the steps, effort and ease of use involved for each, and then decide which tool is the winner. Given the number steps involved, this will be split across two separate posts, with the first post focusing on SSRS,

The steps below assume that you have not previously authored any custom SSRS reports on your system and that you have a FetchXML query ready to return data from CRM. We’ll be using the following basic query to return Lead data that should work with any CRM instance:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="lead">
    <attribute name="fullname" />
    <attribute name="companyname" />
    <attribute name="telephone1" />
    <attribute name="leadid" />
    <order attribute="fullname" descending="false" />
  </entity>
</fetch>

Please note the enableprefiltering=”1” option above, if you are using your own custom FetchXML query, then this line we will need to be added to the <entity> node. Otherwise, your report will not upload correctly later on:

  1. First things first, you will need to download all of the software you need in order to build the reports. Technet has a great article that goes over what you need, the salient bits of which are as follows:

Both downloads are fairly small and shouldn’t take long to install. During the Report Authoring Extension Setup, you may be prompted to install Microsoft Online Services Sign-in Assistant, press Yes if this the case:

SSRS_1

  1. Once installed, open up SSDT using Start -> Search or in Program Files -> Microsoft SQL Server 2012:

SSRS_2 SSRS_3

  1. Once open, go to ‘File’ -> ‘New’ -> ‘Project…’ You’ll see a Window similar to below:

SSRS_4

Select the ‘Report Services Project Template’, give your Project a name and then press ‘OK’. An empty solution file will be created, with the following folders visible on the right under Solution Explorer:

SSRS_5

  1. Typically, at this point you would create your Shared Data Sources/Datasets. Unfortunately, CRM reports do not support these so we need to create our report first. Right click the Reports folder and go to ‘Add’ -> ‘New Item…’. Select Report, give it a logical name, and press ‘Add’:

SSRS_6

The report will open for you within VS:

SSRS_7

Now we can start to create our data sources 🙂

  1. On the left hand side, under ‘Report Data’, right click on the Data Sources folder and select ‘Add Data Source…’ You’ll then need to enter your CRM instance settings:
    • Tick the box where it says Embedded Connection
    • On the dropdown list for Type, select ‘Microsoft Dynamics CRM Fetch’
    • Under Connection String, enter the URL for your CRM instance. There are also two additional parameters that can be specified, but only really useful if your URL points to multiple CRM organizations and/or if you have Active Directory Federation setup.
    • Under Credentials, if you are connecting to an On-Premise CRM instance, select ‘Use Windows Authentication (integrated security)’; if your are connecting to CRM Online, then select ‘Use this user name and password’ and enter your CRM Online login details.

    We’ll test these connection string settings in a few moments

  2. Now that we have our Data Sources, we can create our Datasets (too many Data’s, eh?). Right click on Datasets and select ‘Add Dataset…’:

SSRS_8

Enter the following settings:

  • Enter a name for your Dataset, ideally something descriptive in terms of what data the report is returning
  • Tick ‘Use a dataset embedded in my report.
  • Under Data Source, select your newly created CRM Data Source
  • Ensure that under Query Type, Text is selected
  • In Query, copy + paste or (for bonus points!) manually type your FetchXML query
  • Click Refresh Fields. After a few moments, you should then be able to click on ‘Fields’ on the left pane and see all of the fields from CRM. This means its working! If you get an error message, then double check your connection string details

SSRS_9

SSRS_10

  1. Now the fun part – time to build the report! I will probably do a future blog post on some of the cool things you can do with SSRS. Suffice it to say, for the purposes of this post, we are just going to create a very basic report that displays some field data in a tablix. The report will be run from an individual record, thereby pulling in its data fields. First of all, we will add a tablix to the report. This is as simple as right clicking on the report area, selecting Insert -> Table. The tablix will then appear with a dotted line on the report area:

SSRS_11 SSRS_12

  1. Because there is only one dataset configured for the report, the tablix will automatically associate itself with this. We can therefore start to add in the field by click on the top left a column (where the small table icon appears) and then selecting each individual data field we want to add. SSRS will also add on the appropriate header text for each field you put onto the tablix:

SSRS_13

SSRS_14

For this report, we will add on the fullname, companyname and telephone1 fields. After adding on some customised text to make the report look like a letter, the report should look something like this:

SSRS_15

Very basic I know! But the report will illustrate well what .rdl reports can do within CRM.

  1. Now that the report is finished, we can upload it onto CRM. To do this, we will need to locate the .rdl file for the report first. Press “Build” on your Visual Studio solution (in order to ensure that you have the most up to date version saved to disk) and then open up your Project solution folder in Windows Explorer to find your newly created report:

SSRS_16

SSRS_17

 

  1. Moving across now into CRM, we need to either go into our target Solution or alternatively customise the system via the Default Solution (not recommended for development/Production environments!). On the left-hand bar, we will see a section called Reports. Click on it, and then on New in the centre area to open a pop-up window, which lets us start adding a report into CRM:

SSRS_18 SSRS_19 SSRS_20

It’s useful at this stage to explain what some of the different fields/options mean:

  • Report Type: There are three options here. The first is Report Wizard Report, which takes you through a wizard in CRM to enable you to create a basic report utilising Advanced Find-like filter criteria. You can even make a copy of an existing report and modify it, though you will be limited in your customisation options. The second option is Link to Webpage and enables you to specify a URL to a report that exists outside of CRM (e.g. SAP Crystal Report). The final option, and the one we will be using today, is Existing File and lets you upload a .rdl file into CRM.
  • Parent Report: Similar to what you can do within SSRS Server, you can setup Parent/Child Reports to link together similar reports (e.g. you could have a Parent Account report, that then has a Child Report which shows all of the Contact Details for the Account)
  • Categories: These are grouping options to indicate the type of report you are adding.
  • Related Record Types: Here you need to specify which CRM entities the report can be run from.
  • Display In: Indicates where the report will be visible from. You can select one or many of the options. Reports Area will display the report from the Sitemap Report area, Forms for related record types will make the report available from the Form of the entities you have specified in Related Record Types and, finally, Lists for related record types will do the same, but from the Entity View page instead.
  1. Because we want our report to run on Lead forms only, we need to ensure that the Related Record Types contains Lead, and to ensure our Display In options are configured accordingly. Finally, we need to upload a report by selecting Choose File and then populate the other details accordingly. Your pop-up window should look similar to the below when you are ready to save:

SSRS_21

  1. Save and the Publish your changes. Assuming no problems, you should now see your Report on the Run Report button on your Lead form:

SSRS_22

As you can see, creating a CRM .rdl report for the first time can be quite time consuming and then, depending on the complexity of the report you are trying to create, could take even longer on top of that. I am therefore really interested in finding out as part of next week’s blog post what the process is like for Word Templates, and whether it is a quicker and more effective means of creating reports.

A slightly shorter blog post this week, as I have spent the majority of the weekend upgrading our CRM Online instance to 2016 🙂 Due to the size of our current deployment and, because some of the new features such as Word Templates and Solution Patches will help make a real difference for our end-users/CRM Administrators, we decided to take the plunge early on. As with any upgrade, these can be potentially fraught with many risks for larger deployments, so I very quickly caveat that you should ensure that your business & CRM team are ready to make the jump and that you have put a solid plan in place in order to ensure the upgrade proceeds smoothly.

Microsoft have already published detailed articles that go through the upgrade process in detail, so today’s post is going to provide a more practical description of what to expect, both during and after the deployment.

E-mail Notifications

As the TechNet article above states:

You’ll receive reminders 90, 30, 15, and 7 days before the update begins

These will be sent to all CRM Administrators for your instance from the e-mail address crmonl@microsoft.com, so make sure you check your spam filter settings. The e-mail will look something like this:

CRMEmail

What happens when the upgrade starts

You’ll get no e-mail notification at the exact moment when the upgrade starts, so you will need to ensure that your users have logged off your CRM instance at least 10-15 minutes before the upgrade states, just to be on the safe side. One observation on this point is that there is no (easy) way for CRM Online Administrators to ensure that all of their logged in users have left the application. I am really hoping that they make Administration Mode available to Production instances in the near future, as this will help greatly for scenarios like this or if you are, for example, planning on doing a Solution update during a specific time period.

If you attempt to login into your CRM instance, you’ll be greeted with a screen similar to the below:

CRMUpgrade

Whilst the upgrade was being carried out, I noticed that the Status moved from “Disabled” to “Pending” during the upgrade process. You can therefore refresh the page in order to gain a brief indicator of how the upgrade is going.

How Long the Upgrade Takes

In our case, it took a little over an hour for the upgrade to complete, which was great! In this instance, we were upgrading from CRM 2015 Update 1, so I assume this had a factor in ensuring the upgrade completed so quickly. I would assume that, if the update process is similar to how you would upgrade On-Premise CRM 2013 to CRM 2016, (as an example) then each version update is applied in sequential order (CRM 2013 -> CRM 2015 -> CRM 2016), therefore adding to the amount of time it takes to finish the upgrade

As soon as the upgrade is finished, all CRM Administrators will get the following e-mail:

CRMEmail_2

What to Expect after the upgrade

Again, this section is going to be more specific to scenarios where you are upgrading from CRM 2015 Update 1, though I would be interesting in finding out if these behaviours differ in any other upgrade scenario:

  • This is perhaps more applicable before the upgrade even begins, but if you are making the jump from a much earlier version of CRM, then you may encounter serious problems with any form level JScript. CRM has made some quite fundamental changes in recent versions in regards to the supported methods that should be used. Your CRM Administrators/Developers should have read and fully understood the What’s New for developers guide and, as part of any upgrade plan, some kind of test upgrade in a Sandbox/Trial CRM instance needs to be completed. This should be pretty obvious, but doing this ensures that you can identify and fix these kind of issues long before the upgrade begins.
  • This is a strange one, but the upgrade reverted back our CRM Theme to the system default one. Fixing this is literally just a case of re-publishing your desired Theme from Customizations, but it is rather curious that this even happens in the first place.
  • All Personal/System Settings remain as they were before the upgrade
  • Any Waiting or in progress workflows will remain processing in the background
  • If your organization is using the CRM for Client to Outlook, then you may be pleased to hear that the 2015 Client is compatible and works successfully with CRM 2016. Following the upgrade, when your users first open Outlook again, they will be greeted with the following screen:

CRMForOutlook_Message

Once this has completed, CRM for Outlook will then operate as normal.

In our upgrade however, we did encounter a few cases where this did not always work. For example, the pop-up box above did not appear at all and whenever we tried to navigate to an Entity list in Outlook, Outlook would hang like so:

CRMForOutlook_Hanging

I suspect though that the problems in our case were down to something to do with our organisations infrastructure, as opposed to solely the CRM Upgrade itself. We managed to resolve the above by simply re-creating the connection to the CRM Organization. After that, everything worked perfectly 🙂 I would recommend that you look at upgrading to the Client eventually though (like we are), as it is my understanding that it includes a number of performance tweaks.

Final Thoughts

I am really looking forward to working with CRM 2016 more closely in the weeks and months ahead. The release feels very familiar, but also comes packed with a number of small, but significant, improvements or new features. These are specifically designed to give end users more flexibility in how they use CRM, and in helping make CRM Administrators/Developers lives easier.

Is anyone else planning on or have already upgraded to CRM 2016? Let me know in the comments below.

When working with CRM extensively across multiple environments, you do start to get into a fairly regular rhythm when it comes to completing key tasks again…and again…and again. One of these tasks is the process of rolling out a Solution update. To briefly summarise, this is where you export an updated version of your solution from your development environment and then import the solution file on top of a previous version in a different instance. CRM will then go through the solution import file, detect and then apply any changes which have been made. The original solution will be overwritten as part of this and you will be informed at the end of the import on any warnings or errors that were encountered during import. Warnings will generally not cause the solution import to fail, whereas errors will stop the import completely.

Like with anything, Solution updates can sometimes fall-over for a whole host of different reasons. They can fail altogether, or sometimes just hang and become unresponsive. If you are running On-Premise CRM, then you can interrogate the SQL database on the instance to see how your solution import is (or is not) progressing. Ben Hosking (whose blog is mandatory reading for anyone who works closely with CRM) has written a really useful post which contains the SQL query you need to use on your organization database in order to identify any problematic job imports.  The good thing with this approach is, if the import has errored, the Data column contains the raw XML file that you are able to download via the CRM GUI using the ‘Download Log File’ button below when a solution import proceeds as you would expect normally:

SolutionUpdate_ExportLog

You can therefore very quickly drill-down to see if the solution import has failed due to a customisation issue. A common reason for failure may be due to duplicate logical name(s) for attributes, relationships etc.

If you are using CRM Online, then the first assumption (which I admittedly made) may be that there is no way in which to access the above information. Fortunately, there is an entity called ‘importjob’ that is made available for access via FetchXML

So, for example, to return all solution imports that have gone through your CRM, you would use the following FetchXML query:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
  <entity name="importjob" >
    <attribute name="completedon" />
    <attribute name="solutionname" />
    <attribute name="progress" />
    <attribute name="startedon" />
    <attribute name="completedon" />
    <attribute name="createdby" />
    <attribute name="data" />
    <attribute name="organizationid" />
    <attribute name="createdon" />
  </entity>
</fetch>

If you wanted to just return solution imports that are either stuck at 0% or have not yet successfully completed:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false" >
  <entity name="importjob" >
    <attribute name="completedon" />
    <attribute name="solutionname" />
    <attribute name="progress" />
    <attribute name="startedon" />
    <attribute name="completedon" />
    <attribute name="createdby" />
    <attribute name="data" />
    <attribute name="organizationid" />
    <attribute name="createdon" />
    <filter type="or" >
      <condition attribute="progress" operator="eq" value="0" />
      <condition attribute="completedon" operator="null" />
    </filter>
  </entity>
</fetch>

Sometimes your import may fail due to a problem with CRM itself. In these instances, the best course of action depends, once again, on your CRM deployment:

  • For On-Premise users, then the old IT adage applies here: try restarting the CRM and SQL Database Server instance. You may first need to locate the active process on SQL Management Studio that is performing the solution import and kill the process first. A database instance reset should automatically cancel this and prevent it from running again on instance startup, but its better to be safe than sorry.
  • The only recourse for Online users is to log a support request with Microsoft via the Office 365 portal. It is best to provide as much evidence as possible up-front and be advised that the Microsoft support engineer may ask you to demonstrate the problem again, which might prove difficult to perform during normal working hours if the problem is happening on your Production instance.

I was glad to discover that there is half way method of being able to interrogate possible platform issues yourself on CRM Online, but this particular example illustrates one of the drawbacks of CRM Online: little or no direct access to the organization database and/or instance level services. I would hope that in time Microsoft may develop the platform further in order to start exposing these elements to organization administrators. I would imagine that the vast majority of support queries that go through on the Office 365 portal would relate to requests that could be safely performed by CRM Administrators or Partners, leading to a cost and efficiency saving for Microsoft should this be implemented.