Tagging Multiple Records with Multiple Tags in Dynamics CRM

With the latest version of Tagging (download here) we have introduced the ability to tag multiple records with multiple tags all in a single action. This functionality is provided via a new page available in the latest release. Simply select the records you wish to tag and click on the Multi Tag button:

Screen 0 - Multi Tag

Once you click on save the tags are applied to all of the records you originally selected.

Preconfigured Solution

To enable this functionality it requires you to create a button on each grid you wish to utilize multi tagging. To help kick start this for you we have provided a solution that enables this feature on account, contact and cases. Simply navigate to the Tagging page to download a copy of this solution.

Adding a button to the command bar

If you have a custom entity you wish to enable multi tagging on, or you prefer not to use the provided quick start solution, you will want to know how to add a button to the command bar. With the help of a tool called Ribbon Workbench we can easily achieve this.

1. Create a new solution and add the entity you want to customise ensuring you also add the 3 xrmc_ web resources in this screenshot:

Screen 1 - Solution

2. Launch Ribbon Workbench and once it opens select the solution you just created.

Screen 2 - Select Solution

3. Add a command to execute the MultiTag function:

  • Select the entity you with to customise
  • Right click on Commands
  • Click Add New
  • Give the command a name. For example, custom.account.MultiTag.Command

Screen 3 - Command

4. Add a new action to the command

  • Click on the lookup icon to add a new action.
  • Then click on the add button to add a new JavaScript Function Action.
  • The function you will want to call is openMultiTag
  • Select the WebResource called $webresource:xrmc_/MultiTagRibbon.js

Screen 4 - JavaScript Action

5. Add 2 parameters to this function so that it detects what was selected in the grid:

  • Click on the lookup icon beside the parameters box
  • Click the Add button and add a Crm Parameter
  • Set the value to SelectedControlSelectedItemReferences
  • Click the Add button and add another Crm Parameter
  • Set the value to SelectedEntityTypeName

Screen 5 - JavaScript Parameters

6. Add an enable rule to the command. MultiTag is only relevant if you have selected at least 1 record.

  • Click on the lookup icon beside the Enable Rules
  • Click on + Add New
  • Give it a name. For example, custom.account.MultiTag.EnableRule

Screen 6 - Enable Rule

7. Create a step for the rule

  • Click on Add Step and add Selection Count Rule
  • Set AppliesTo to Selected Entity
  • Set Minimum to 1

Screen 7 - Enable Rule Step

8. Now we can move on to the button itself.

  • Click on OK to save everything until you get back to the main screen.
  • To add a button simply drag a button from the toolbox on the left onto the appropriate command bar.

Screen 8 - Button drag

9. Give the button a name, for example, custom.account.MultiTagButton, and set the button properties as per the following settings:

Screen 9 - Button properties

Publish your changes by publishing the solution you have just edited. Note: if your changes don’t appear right away publish the solution again and refresh your browser window.

How to configure Timeline for Microsoft CRM with Custom Entities

One of the most sought after additions to the Timeline was support of custom entities. This new feature opens up amazing potential to expand the Timeline and customise it to suit many different scenarios. In this post we’ll discuss how to take advantage of this functionality by adding a custom entity to the Timeline.

If you would like us to configure the Timeline for your custom entities/needs we’d be pleased to help – please email us on sales@xrmconsultancy.com.

Timeline Configuration

Firstly, let’s take a look at the existing configuration to give us an idea of how the timeline works. Open up the Timeline solution and from the configuration page click on the link to open the Timeline Configuration.

Screen Shot 1

You can see here how all the existing entities currently supported by the Timeline have a configuration record associated with them. Open up the appointment record to see what it contains. You’ll notice some HTML, some Fetch XML and some other settings in here.

Screen Shot 2

An important piece of the configuration is the Timeline Entity links at the bottom. These records drive how the relevant entity links to the parent entity you place the timeline on.

Adding a custom entity

Ok, let’s put this into practice and configure a custom entity to appear on the timeline. Currently my timeline looks like the following.

Screen Shot 2014-01-22 at 23.31.50

To demonstrate how the custom entity works I will configure another entity to appear on the timeline. For the purposes of this example I have installed our SMS solution and the custom entity I will add is the SMS entity (xrmc_sms). Firstly open up the Timeline Configuration record via the solution file. Hit the plus button on top of the Timeline Entities grid to add our custom entity.

A quick summary of the more important fields we’ll use are:

Entity Logical Name: xrmc_sms. This is the underlying schema name of the entity.
Headline Field: subject. The main headline that will appear on the timeline.
Date Field: actualend. The date field that drives where it appears on the timeline. If your entity is a custom activity then putting ‘actualend’ in as the date will tell the timeline to use actual or scheduled start and end dates.
Small Icon: /WebResources/xrmc_SMSIcon16x16. The small icon that is associated with this entity
HTML: The HTML that will render the custom entity record and data within the timeline. We will discuss further below
Query: The Query that is run to pull back an individual activity record. We will discuss further below

For more details on these fields you can consult the Timeline Install Guide.

How the HTML works

The HTML we are going to use is as follows:


<div class="summaryinfo">
<div class="openentity">
<a id="recordURL" href='#' title="Open full record"></a>
</div>
<p id="to" class="xRMC-Attribute xRMC-PartyList">
<span>To:</span>
</p>
<p id="from" class="xRMC-Attribute xRMC-PartyList">
<span>From:</span>
</p>
<p id="regardingobjectid" class="xRMC-Attribute xRMC-Reference">
<span>Regarding:</span>
</p>
</div>
<p>
<span>Message:</span>
</p>
<div class="innerwrapper">
<p id="description" class="xRMC-Attribute">
</p>
</div>

Let’s take a closer look at this HTML. The main thing to point out within the first 2 divs is the openentity class and the recordURL anchor. These are used to create a link back to the record for the current entity so ensure to include them in your custom HTML:

<div class="summaryinfo">
<div class="openentity">
<a id="recordURL" href='#' title="Open full record"></a>
</div>
... other fields and attributes
</div>

The next set of tags you’ll see all have the xRMC-Attribute class. This tells it that the id of this tag is an attribute on the entity. So when you put in “to” it will look at the entity and extract the “to” field.

<div class="summaryinfo">
<div class="openentity">
<a id="recordURL" href='#' title="Open full record"></a>
</div>
<p id="to" class="xRMC-Attribute xRMC-PartyList">
<span>To:</span>
</p>
<p id="from" class="xRMC-Attribute xRMC-PartyList">
<span>From:</span>
</p>
<p id="regardingobjectid" class="xRMC-Attribute xRMC-Reference">
<span>Regarding:</span>
</p>
</div>

Also, as you will probably know, in CRM the “to” fields are a special type called Party Lists, and regarding are references to other entities. So these have special classes to allow the timeline to handle the attributes appropriately. There are many more different types of classes you can use to display different types of fields and all are covered in the Timeline Install Guide as mentioned previously.

Query CRM for the Entity Record

The final piece of the puzzle when configuring an entity is telling the Timeline how to get the record from the database. This is done using Fetch XML. A really quick way to build some Fetch XML is using the Advanced Find to create your query and then using the Download FetchXML button. For now let’s just use the following to pull back the required record:


<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
<entity name="xrmc_sms">
<attribute name="to" />
<attribute name="regardingobjectid" />
<attribute name="activityid" />
<attribute name="description" />
<attribute name="from" />
<filter type="and">
<condition attribute="activityid" operator="eq" value="{0}" />
</filter>
</entity>
</fetch>

The main thing of note here is the special id parameter here:


<condition attribute="activityid" operator="eq" value="{0}" />

This will be replaced with the relevant SMS id at execution time to load the correct SMS entity record.

Linking this entity to a Timeline

We’re missing one last important link, when I place a Timeline on the Account page how does the Timeline know how to link this SMS entity to the Account entity? That’s where Timeline Entity Links come into play. If we take a look at the bottom of our Timeline Entity form you’ll see a section at the bottom for these Timeline Entity Links. Add a new one to the grid with the following details:

Name: SMS
Logical Entity Name: xrmc_sms

And put the following in as the query. It will locate all of our xrmc_sms records that are regarding a particular account:

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">
<entity name="xrmc_sms">
<attribute name="subject" />
<attribute name="statuscode" />
<attribute name="regardingobjectid" />
<attribute name="activityid" />
<attribute name="scheduledstart" />
<attribute name="actualstart" />
<attribute name="actualend" />
<attribute name="activitytypecode" />
<attribute name="statecode" />
<order attribute="actualend" descending="true" />
<order attribute="actualstart" descending="true" />
<filter type="and">
<condition attribute="regardingobjectid" operator="eq" value="{0}" />
</filter>
</entity>
</fetch>

The main thing you’ll notice here is we’ve put in account for our Logical Entity Name. This tells the timeline, when placed on an account record, to use this timeline entity link.

Also, in addition to this, in the query you’ll notice that special field again:

<condition attribute="regardingobjectid" operator="eq" value="{0}" />

This will get replaced with the Account Id when it’s rendered on the account page.

Timeline with Custom Entities!

If you navigate back to an account you’ll now see SMS messages appear in the timeline:

Screen Shot 2014-01-23 at 23.16.53

Download

The updated Timeline is supported on CRM 2013 and CRM 2011 and is available for download now.

A free version of the Timeline is still available with all the features of the previous version, but to unlock custom entities and other great new features purchase a license key today!

Migrating from ACT! to Dynamics CRM

Today let’s discuss migrating data from ACT! to Microsoft Dynamics CRM 2011. The last migration we undertook from Act to Microsoft Dynamics CRM also involved a brand new tool for us called Data Synchronisation Studio from the team at Simego. At xRM Consultancy we have dabbled with a lot of data migration tools, but Simego and it’s Data Synchronisation Studio stood out from the pack this time due to some powerful features it offers. So we decided to give this a trial to see if it really was worth investing our time and money in. For this post let’s pick one part of a migration that is often a pain point: attachments. This will also allow us to explore some of the features of Data Synchronisation Studio and how it stands up to the task.

Preparing the data

First question you may ask – what exactly is ACT! underneath the hood? More importantly, how do we extract that data and get it into Microsoft Dynamics CRM? ACT! sits on top of a SQL Server database so this makes querying and pulling the data out a lot easier than having to deal with APIs or flat files. Most of the data in here is quite straight forward and you’ll immediately identify some entity tables such as TBL_CONTACT and TBL_COMPANY. Linking the data up to related tables and retrieving the relevant columns is a little more challenging.  Our strategy to ease this pain is using a set of views and functions we’ve built up over time which allows us to easily extract the relevant and linked data.

For this example let’s deal more specifically with how attachments are stored and referenced. People already up to speed with Microsoft Dynamics CRM will know that attachments are base 64 encoded and stored directly in the database. In ACT! these files are stored externally and the file name is referenced within the relevant table – TBL_ATTACHMENT. So we need to combine queries with external files. Let’s start off with an example query:

SELECT * FROM TBL_ATTACHMENT

Running will get you some results like this:

SS1

As we can see from the query ACT! gives us a list of files, which includes the file name, but no path. This isn’t a problem, because there will be a folder on the server where all these files are stored. Once you find them it’s pretty much a 1 to 1 mapping from each record to a file. All we need to do is map these files to the relevant entity records we will have already imported. Let’s take a look at a basic query to link these attachments to a company record. Take the following query:

SELECT [a].[ATTACHMENTID]
      ,[t].[NAME]
      ,[a].[FILENAME]
      ,[a].[DISPLAYNAME]
      ,[c].[COMPANYID] as [OBJECTID]
      ,'account' as [OBJECTTYPE]
from TBL_ATTACHMENT [a]
inner join TBL_HISTORY [h] on [h].[HISTORYID] = [A].[HISTORYID]
inner join TBL_HISTORYTYPE [t] on [t].[historytypeid] = [h].[historytypeid]
inner join TBL_COMPANY_HISTORY [ch] on [ch].[HISTORYID] = [h].[HISTORYID]
inner join TBL_COMPANY c on [c].[COMPANYID] = [ch].[COMPANYID]

Running this will get you some results like this:

SS2

The key thing to note here is linking to the company record via a table called TBL_HISTORY. This table is a multipurpose table, but it’s main purpose could be described as keeping a record of all “history” of actions that occur against records. I’ve included the TBL_HISTORYTYPE in the query to show how to pull out a description of the type of history activity that was recorded, but this isn’t something we need to migrate. Finally, and most importantly, we can use the link table TBL_COMPANYHISTORY to pull back records that are associated with companies.

Importing the data

Now that we have these company attachment records we need to import them. Remember, there is a mixture here between table records and files stored externally on the hard drive. This is the perfect opportunity to see what Data Synchronisation studio can offer in order to fulfil this task. At a first glance it looks just like your standard data import tool:

ss3

On the left you can link up your source data, i.e. the ACT! database. As I mentioned previously we have a set of views we create in the ACT! database so let’s hook into one of those. For all intense purposes let’s say the view is called xrmc_CompanyAttachments. On the right you link to your target table, which is the annotation entity in your Microsoft Dynamics CRM organisation. You can map across most of the columns straight from the query I prepared above.

ss4

So everything apart from the file contents has been mapped. Getting Data Synchronisation Studio to read this file and import it opens up a really interesting and powerful feature of this tool, namely Dynamic Columns. Every Dynamics CRM developer who has used a migration tool will love this – Dynamic Columns are simply properties exposed using C# classes! So let’s write our property:

// Convert the pysical file to a Base64 string
public string FileContents
{
  get
  {
    string fullFilePath = "C:\\Path To Act Attachments\\" + FILENAME;
    if (System.IO.File.Exists(fullFilePath)) {
      return Convert.ToBase64String(System.IO.File.ReadAllBytes(fullFilePath));
    }
    return string.Empty;
  }
}

And you end up with the following in Data Synchronisation Studio:

ss5

Imagine the power of this. Suddenly, reading in a file becomes such a simple task. Simply build the code using the provided build button and this provides you with a new list to map to your data. Map this new Dynamic Column across to your DocumentBody and you’re pretty much done:

ss6

If we do a compare, using the Compare A -> B button, let’s take a quick look at what our data looks like:

ss7

And that’s pretty much it. Click on Synchronise and watch those file migrate!

Next time I’ll discuss a more advanced scenario where we had to merge customer data from ACT! and Sage 50 Accounts into a single view of the customer within Dynamics CRM.

If you’ve got ACT! and you are looking to upgrade to Microsoft Dynamics CRM why not get in touch with our team.