Tag: customization

CRM 2015 Rollup Fields: The Gotchas

In an earlier blog post in December, I described one use case for the new Rollup Fields feature introduced in Microsoft Dynamics CRM 2015. This example involved rolling up data from email events tracked via ClickDimensions and summarizing this on the contact’s form, so you’ll want to check out the steps listed there if you don’t have any hands-on experience about this new feature yet. In this post I’m going to dig deeper into the details about how Rollup Fields actually work behind the scenes and what limitations you should be aware of when considering whether they are the right tool for the job in your own use cases.

Rollup Schedules

The first thing you need to understand about Rollup Fields is that they are not updated in real time. If you’re familiar with the difference between the real time workflows introduced in CRM 2013 and the asynchronous versions that were available in earlier versions, then this is something a bit like that, but not quite. As you might know, the traditional background workflows were triggered by an event that took place on a CRM record and the resulting workflow instance was scheduled to be executed by the asynchronous process running on the CRM server at the earliest possible date (depending on the overall workload on the server). Whereas this usually meant a delay of perhaps a minute or two at most, the new Rollup Fields are even further from real time than this.

As we saw in my earlier post, when you create a new Rollup Field, a new mass calculation job will be created for the field in question. This will be scheduled 12 hours into the future, based on the assumption that this will most likely fall outside the office hours when actual CRM end users are working with the system. (Because us CRM customizers or system admins never work during the night, right? Yeah, what a funny assumption that is, but anyway…) The reason for such precaution is that the very first calculation job will have to populate each and every record that exists for that entity, which could be up into the millions, depending on what type of data you manage in your CRM.

So, does this mean the Rollup Fields only get updated once per day, during that nocturnal schedule? No, actually they get updated once every hour. If you go to the Settings – System Jobs menu you’ll see that there are jobs of type “calculate rollup field” type running for each of your entities that have one or more Rollup Fields defined for them. They are not scheduled to start at exactly the same time, but they all run at one hour intervals. Another thing worth noting in the Rollup Field implementation architecture is that these calculation jobs are only applied to records that were created, updated or deleted after the last job finished. No point in processing a million records if only a handful of them could possibly have new values to be calculated, right? This is why the initial rollup and the recurring rollup requests are handled by different system jobs in the CRM platform.

Rollups and Workflows

Now that we know the Rollup Fields may not show a current values in the UI for quite some time, the next logical question to ask is: anything we can do to speed the calculations up? As an end user, you could go and look at any Rollup Fields that have been added onto an entity form which you have the necessary rights to view, then hover over the field and click the “recycle” icon to force the recalculation of the Rollup Field value. As a developer, you also have the option to force a Rollup Field to be recalculated on demand via a plugin, by using the CalculateRollupField message. As a system customizer… Well, there’s not much you can do, at least in the CRM 2015 version. (more…)

February 9, 2015
Analyzing Customer Behavior Data with CRM 2015 Rollup Fields

From a system customizer perspective, one of the most intriguing new features in Dynamics CRM 2015 is the addition of two new field types. Alongside the traditional “simple” fields we can now define our custom attributes to be somewhat more “complex”, by choosing to create them as either calculated fields or rollup fields. These new field type options allow us to create point & click solutions to cover scenarios that would have previously required custom code.

Microsoft haven’t been advertising this feature much in their “what’s new” materials for the CRM 2015 version release, but great blog articles have already been written on the topic, like this one by Peter Majer on the Sonoma Partners blog. There are also articles on Technet for both rollup fields and calculated fields, which provide all the details you need for getting the new feature implemented in you CRM Online or CRM 2015 on-premises organization.

Rather than repeating this documentation, I’ll be exploring the different scenarios where the new complex field types can be leveraged, as well as the considerations and limitations to be aware of. In this first blog post I’ll demonstrate how the rollup fields can give us better insights on how our customers are reacting to email marketing campaigns sent to them.

Summarize Marketing Automation Data for Contacts

When our own CRM Online production organization received the 2015 update, the first use case I had on my mind for the shiny new features was to apply the rollup field functionality to the online marketing data that our ClickDimensions solution has been storing into the CRM database. If you’re not familiar with ClickDimensions, it’s a marketing automation service that allows you to send and track email campaigns, collect website visitor data, publish web forms integrated with CRM fields, configure automatic nurture programs for new leads, among other things (see this page for a detailed feature listing).

What makes ClickDimensions particularly interesting in this case is that all of the behavior data is available inside the CRM application, in the dedicated custom entities contained in the managed CD solution package. For example, a page view transaction from a website with the CD tracking script deployed will be stored as a record for the Page View entity and then linked to either an anonymous visitor or an existing lead or contact record in CRM. Since it’s an “XRM” solution that you install as an add-in to Dynamics CRM, rather than an external marketing database that would be just synchronized with CRM, we can leverage all of the CRM platform functionality for showing and analyzing the data, automating related business processes with workflows and so on.

Now with CRM 2015, the rollup and calculated fields have been added to our marketing automation toolkit. So, what do they allow us to do that would have previously been difficult/expensive to implement? As mentioned, all of the events tracked by ClickDimensions are linked to a CRM contact or lead record when the person performing the actions can be identified from browser cookies, unique id’s in links or submitted form data. If we would now like to view this data from the perspective of an individual contact, the rollup fields provide a way to summarize the data from related entities into fields available directly on the contact form.

Creating Rollup Fields for Contact’s Email Link Clicks

Let’s go ahead and add a new field for the contact entity. Yes, it must be a completely new field as you cannot convert existing standard or custom fields into calculated or rollup fields. Not a problem in our scenario, as we’re building a brand new feature into our CRM organization. The first field will be called Total Clicks and we’ll use it to count the number of related records found, so whole number is a suitable data type for us. By setting the field type as “Rollup” we’re given the option to edit the rollup formula.

In the rollup field definition editor we must now choose the related entity from which we wish to roll the data up to the contact entity. As we’re dealing with email link clicks, these are stored in the Email Event entity in the ClickDimensions solution, so that will be our choice. However, since the entity also contains data about events other than link clicks, we’ll need to add a filter into the related entity section and define that only email events where the field “type” equals “click” should be included in our rollup. As a final step, in the aggregation section we select “count” as the function that will provide the actual value for this new field on the contact record.

Let’s repeat the process for another new field: Latest Click. Instead of counting records, we’ll be looking at the date values on the related records, retrieving the highest date available and storing it into our rollup field. This means the data type should now be “date and time”. The rollup field definition is otherwise the same as with the first field, but in the aggregation section we’ll now have a different list of functions available for this data type. Let’s pick the Max function and apply it on the creation date of the email event records associated with the contact.

Alright, let’s save these fields and get them published! Oh, by the way, did you notice the yellow notification bar down in the rollup field definition editor window? That’s actually very useful information to be aware of once we move on to the next stage of our customization process.

Displaying the Rollup Field Data for Contacts

There are two main places where fields are presented in Dynamics CRM: forms and views. Let’s start from the contact form and include our new rollup fields there. In my scenario, we already have a suitable custom form available for the contact entity, which has been used for summarizing all the ClickDimensions data related to an individual contact record. Notice those fancy embedded charts and subgrids showing the email events for this test contact record of mine? That’s actually something you’ve been able to do already since the CRM 2011 version, so not exactly related to our agenda of the day, but a good reminder about how you can leverage the XRM capabilities of the Dynamics CRM platform to present data in a format that’s easier for end users to consume. (Check out my 10 tips for better CRM user experience for more discussion on that topic.)

I’ve added the Latest Clicks and Total Clicks on the contact form, below the existing chart and subgrid. But wait a minute: why are they empty? Did we do a mistake in the rollup field definitions? Don’t worry, this is exactly the expected result after creating a rollup field. If you took a moment to read that yellow notification bar I mentioned earlier, you’ll know that a mass calculation job was created by the CRM system after you added the rollup fields for the contact entity. Also, since it was by default scheduled to be run 12 hours after the field creation, we’re not going to see the whole magic until the next day in many cases.

If you’d rather validate that the new customizations you’ve created are working as planned, instead of just taking my word for it, open up a contact record form and hover over the rollup field. You’ll see a “recycle” icon that you can click on, after which CRM will perform the rollup calculation for that field, for only the currently selected record. (more…)

December 15, 2014
Who Is The Customer in Your CRM? (Podcast)
Recently I was invited to make my second appearance on the CRM Rocks podcast series, hosted by Markus Erlandsson. The first episode we did back in fall last year was focused on “what’s new in Microsoft Dynamics CRM 2013”, which was certainly a timely topic back then. This time we decided to discuss on a theme that was less focused on the CRM application functionality or a specific version of it. On our agenda was the question “who is the customer”?

It might seem like not such a complex question to answer at first. After all, if we are deploying or developing solutions for customer relationship management then surely there must be a clear understanding of what exactly we need to be managing with the system, right? Well, as with most things related to designing a CRM solution, there isn’t a single right answer, but there are many good questions instead! To help anyone who’s starting their journey towards implementing a CRM system for their company and wondering what questions should be asked from the business and process owners, I’ve listed some of these topics into the following presentation available on SlideShare:

Who is the customer in your CRM? #CRMRocks podcast from Jukka Niiranen

Our discussion in the podcast covers five major aspects of the CRM solution design fundamentals:
- Who is your customer?
- B2B customer modelling
- Segmenting your customers
- The role of non-customers in CRM
- Why Social CRM is the new CRM
While some of the podcast content is of course specific to the application platform that I have the most experience of working with (can you guess which one?), I hope and believe that much of the guidance would also apply to any modern CRM system you might be deploying. So, please have a look at the slides above, and if you feel like the contents is relevant to the business problems that you hope to solve with customer relationship management technology, proceed to listening to the full CRM Rocks podcast.
December 9, 2014
Dynamics CRM 2013 in Retrospect

Dynamics CRM 2013 was released only a bit over year ago, on October 8th 2013 to be exact. With CRM 2015 already knocking at the door, this seems like ages ago already, even though the actual time between these two major releases is shorter than their marketing names imply.

Since the discussions in the Dynamics CRM community will inevitably be moving towards the latest 2015 version as the year turns, it’s a good moment to reflect back a bit and recap what the previous release gave us. I took a look at some of the blog posts I’ve personally written regarding CRM 2013 specific functionality since the version came out. By analyzing the page view stats from my blog, the following articles came out on top as the five hottest topics that you, the readers, were interested in reading about. If you missed any of the articles, now’s the time to do a quick catch up before CRM 2015 steals all the attention.

Synchronization vs. Tracking: Understanding Activity Management Options

(Article link)

CRM 2013 introduced a new feature called server-side synchronization, which allowed the CRM server to communicate directly with the Exchange server for the first time in the product’s history. Upon first look it might have appeared like the long dependency on Dynamics CRM Outlook client was about to be history. However, in our brave new “cloud first, mobile first” world there are many more aspects to managing activity data in relation to CRM records that you need to understand.

While the synchronization options for activities and contacts were indeed expanded with CRM 2013, the tracking options were not. In addition, the combinations supported email client and server applications for each entity and action type were quite a maze to navigate in. Since this is not such an easy topic to grasp nor explain, I ended up building a support matrix of my own, so that I was able to clearly communicate the various synchronization and tracking options to our customers.

Getting Your Head Around Dynamics CRM 2013 Processes

(Article link)

Changes in the application’s UI may have grabbed most of the attention when it came to the CRM 2013 release, but there were also notable enhancements made to platform capabilities behind the scenes. Business Rules and Real-time Workflows opened up a whole new world of possibilities for the system customizers to create custom business logic that had previously required JavaScript or plug-in development.

The one process type that was highly visible to the users, Business Process Flow (BPF), was also perhaps the most demanding one when it came to applying it in real world scenarios. Since BPF’s themselves don’t provide any automation but rather rely on the other process types to work in conjunction with the BPF process stages and steps, understanding the role of each of these components will require a fair bit of experimentation. This is why I wrote a two-part article where I tried to lay out the big picture of process automation in CRM 2013.

Connecting to CRM Online OData Feed with Excel 2013 Power Query

(Article link)

While the CRM 2013 release itself didn’t provide any dedicated feature for the Power BI tools announced by Microsoft a bit earlier, there were updates made to the Power Query component in Excel 2013 that made it very interesting for CRM Online customers. More specifically, the December 2013 version of Power Query finally delivered the ability to connect to OData feeds what utilize Office 365 authentication – with CRM Online being such an application.

There isn’t a whole lot of official documentation available on the topic of how to leverage CRM Online OData feeds to build reports utilizing the Power BI toolkit. The process isn’t necessarily very straightforward and requires a fair bit of experimentation with the various Excel components (Power Query, Power Pivot, Power View). In addition to the OData feed connection part, I also wrote a couple other posts on what to do once you have the CRM data flowing into Excel via Power Query.

Setting Up a Microsoft Dynamics CRM 2013 Development Server on Azure

(Article link)

Running Dynamics CRM in the cloud via CRM Online is a popular option these days, but for performing testing and development tasks it’s often more convenient to have your own sandbox where you can control each and every part of the system. Azure has evolved into quite an attractive option for running virtual machines, especially with MSDN subscription credits and discounts for development environments.

I’m not an infrastructure specialist that enjoys configuring servers very much, but when new versions of Dynamics CRM become available as preview/beta versions, it’s a good exercise to set up your own sandbox server. To better remember what the minimum steps are to be able to install the Dynamics CRM server application, I decided to document the process via screenshots and make it available on SlideShare for anyone else wanting to complete the same task.

Expanding Add Activity Options on CRM 2013 Forms

(Article link)

In the course of the UI refresh performed in CRM 2013, the number of menu options visible to the end users were optimized to cover only a single way to perform many of the options that previously might have had alternative route options. While the intention was noble, this did create a few situations where the navigation path required to perform an action may have not been the optimal one.

The great thing about Dynamics CRM is that it’s a customizable platform that allows you to adjust the data model, forms and also the menu options to the specific use cases required by the customer organization – as long as you know how. With awesome community contributed tools like the Ribbon Workbench these tasks can be completed with a few clicks of a mouse, which is what I illustrated in this post where I added a new flyout menu onto the CRM 2013 Command Bar to access standard as well as custom activity records, and even launching a dialog process directly from the menu.

November 13, 2014
Don’t Merge Your Forms in CRM 2013

If you have been using Dynamics CRM before the 2013 version was released, you may have something in your system called “information forms”. This is not a very descriptive term for them, since of course all the entity forms are about presenting “information” to the end user. These forms actually date back to a time in the Dynamics CRM platform history when there was only a single form available per entity. Times have changed quite a lot since then, as entities can now have role based forms, mobile forms, quick create forms and quick view forms.

Although not a specific form type in itself, CRM 2013 introduced a whole new layout for the default entity forms as a part of the UI refresh. Instead of the traditional & boring two column layout, the new CRM 2013 forms are made up of three columns that can consist of not just entity fields but also related entity subgrids, the social pane, Bing Maps component and other exciting new features. Whereas the old default forms were called “Information”, the names of these new forms follow the entity names. So, the account entity will have a new form labelled “Account”, as an example. (By the way: check this tip for optimizing your form naming convention.)

Merge Forms Feature

Since the new forms are designed to make better use of the new navigation paradigm of CRM 2013 as well as present the data in a much richer way than the old “ERP style” forms of past CRM versions, customers who are upgrading their Dynamics CRM deployment to the latest version are advised to migrate into using these new forms. In fact, Microsoft has stated that the next major version (CRM 2015) would no longer support the use of the old “information forms”.

To make this transition easier, Microsoft has provided a feature called “Merge Forms”. This new button available on the form editor in the CRM customization UI (which still utilizes the old CRM 2011 style layout even in CRM 2015, by the way) is intended to be used for bringing the tabs, sections and fields from your old forms onto the new forms with as little clicks as possible.

The process is described in the article “Update your forms to Microsoft Dynamics CRM 2013 or Microsoft Dynamics CRM Online Fall ’13”. Even more detailed steps can be found from the PDF document “How to Prepare for the CRM Online Fall ’13 Service Update”. Basically what the feature does is bring in the contents of the old form to the end of the currently open form, with the intention of making it faster to rearrange your customized fields and sections to align with the new default form’s content and layout.

Sounds like a handy feature, right? There’s only one slight problem with it: it doesn’t work.

Conflicting ID Values

“What do you mean it doesn’t work? I have used the button to bring in my custom fields and it did just what I expected.” Well, maybe I should rather say that it works partially. If you never export your CRM customizations into a solution file and move it to a different environment, you may not notice that anything is wrong with your forms. However, if you do want to move the customizations between development, test and production organizations, you might run into the below error message during the solution import process.

After the error, if you download the log file and open it, you’ll see a message like this:

Error code 0x8004F658. The label ‘E-mail 2′, id: ’87dc7c9c-94c1-3953-e490-11413b31d0ad’ already exists. Supply unique labelid values.

What the system is telling us is that we’re trying to insert an item into the customization metadata that has a non-unique ID. Depending on the scenario, the item could be a field or section label. But how did the ID end up being a duplicate? After all, we don’t assign these GUID values in the customization UI, rather the CRM platform generates them. What could have caused the system to violate its own rules?

The answer can be found from this thread on the MSDN forums: CRM 2013 Solution Import. A Microsoft support engineer has confirmed that the error is caused by a design mistake in the Merge Forms feature. Apparently in the process of merging form content from the old form onto the new one there is more data carried over than is needed. Not only do you get the form components exactly the way they are configured in the original form, but you also get the same ID’s. Now, since the old form also exists in the system, this will cause an error message when you try to import your solution file from the source system to the target environment, like from development to test environment, for example.

The Workaround

The system where I ran into this problem was running Dynamics CRM 2013 Service Pack 1 (6.1.0.581) with no Update Rollups (see this earlier blog post for help on understanding the different updates and version numbering). The forum thread above does not indicate that a hotfix for the form merge bug would have been included in one of the released updates so far, so I’m assuming that all CRM 2013 environments are affected by it during the time of writing.

The suggested workaround in the forum discussion was basically “start all over”, meaning removing the merged content from the form and re-adding the components back there one by one. In the environment I was working on this would have required many hours of work with using the form editor on a number of entities , which I wasn’t too keen on spending there. I had just migrated a copy of the CRM 2011 production organization database onto a CRM 2013 test server and was in the process of testing the upgrade steps before the final go-live, so re-doing the customizations at this stage just sounded like both a schedule challenge as well as a potential source for new issues.

I extracted the CRM solution zip file and poked around the customization.xml file for a while, trying to think of a way out of this situation. After I realized that trying to edit the XML manually would only land me into a deeper hole, it occurred to me that there was another feature in CRM that performed something similar than the broken Merge Forms: the “Save As” button. Copying entity forms to create new variations was something that I had used many times with no issues, so perhaps I could rely on it here as well?

I proceeded with creating a copy of each of the entity forms where I had used the Merge Forms feature. Since the new form versions created via “Save As” are able to co-exist with the original forms without causing any conflicts, this must mean that the CRM platform assigns the required new ID’s to the form components. Based on this reasoning, I therefore assumed that once I deleted the original merged form and renamed the new copy (as well as configured the form order and security roles), I would have a clean solution file with unique ID values. After testing the solution import I was extremely glad to see that this was in fact the case, as no more error messages appeared during the import. Saved by the “Save As”!

Don’t Just Merge – Design

So, with the above workaround and a potential upcoming hotfix, is there any reason not to use the Merge Forms feature? In my humble opinion, the merge process is not a best practice but rather just a quick’n dirty way of getting the custom fields to appear on the entity forms. If you don’t in practice know how to customize your Dynamics CRM environment but need to cope with the updated UI of the new version, then the merge will technically make it possible to keep using your CRM data. What it will not do is produce a system that your end users will enjoy.

The merge will bring over a lot of duplicate content (all the default fields) that you may forget to clean away from the new form. It will also create very confusing components for the system administrators, such as the old “What’s New” section vs. the new Social Pane, which require a deeper understanding of the Dynamics CRM platform evolution to really figure out. The biggest risk is that the form content designed for the old version UI will end up living alongside the content that is specifically made for the post CRM 2013 world, creating a disconnected and illogical application that works differently depending on the area where the user navigates to.

Instead of taking the shortcut and doing a quick content merge, I recommend investing a bit more time and effort in planning what’s the best way to present the data and how to make it as easy as possible for the users to interact with it through the UI. If you need some ideas for improving the user experience of your Microsoft Dynamics CRM environment, take a look at my previous post that listed 10 tips for designing a great user experience in Dynamics CRM.

October 12, 2014
10 Tips for Designing a Great User Experience in Dynamics CRM

Last week I had the privilege to talk at the Dynamics CRM Finland User Group meeting in Helsinki (quick recap available in Finnish here). When planning on what topic to choose for my presentation, I tried to think of something that would appeal to a wide audience of CRM users – both experienced consultants as well as key users who might still be relatively new to the product.

The common denominator for the group was, as the name suggest, that we’re all CRM users in one way or another. In this role we interact with the software in a variety of different ways, most likely several times during the course of a typical working day. As information workers, systems like CRM are our tools to get the job done. How effectively we succeed in this is largely affected by how much cognitive effort is needed to use these tools to shape the expected output.

So, I decided to talk about the many ways how we can sharpen our saws when it comes to Dynamics CRM. While every CRM environment is ultimately different from one another, due to the business processes we manage with it, the systems it integrates to, the user groups working with the application and so on, I believe there are still general design guidelines that apply to basically any organization using Microsoft Dynamics CRM. My presentation, “10 Tips for Designing a Great User Experience in Dynamics CRM“, introduces many of these guidelines that I personally try to follow when designing CRM solutions for customers. You can view the embedded presentation below, or if the content is not showing, then go and have a look at it on SlideShare.

10 Tips for Designing a Great User Experience in Microsoft Dynamics CRM from Jukka Niiranen

While UX has always been an important piece of the puzzle when trying to convince business users that using a CRM system can actually deliver tangible benefits to them, rather than just serve as a management tool for keeping track of what the employees are doing, the launch of the Dynamics CRM 2013 version has really heightened the importance of designing solutions with a polished user experience. This is due to the fact that the refreshed user interface and new customization points available in the UI can be leveraged to deliver a much more usable business application than the CRM systems of the past. But: you also need to plan the flow of user interactions with much more attention to detail, because sloppy customizations will now stick out like a sore thumb.

The good news is that many of the new details in CRM 2013 (and CRM 2015, too) are easy to configure once you know the role of each platform component. You can do so much these days without writing a single line of custom code that the system customizer can easily have his or her plate full of CRM enhancement ideas to implement without ever consulting a .NET developer. That’s why it’s also good to think in advance how to prioritize the areas into which you invest your efforts. This Top 10 list of mine provides one example of such a tool, to help in identifying the low hanging fruit when it comes to making your CRM users happier and more productive with the system. If you have any topics on your mind that I forgot to include on my list, be sure to leave a comment below!

Oh, one more thing: if you’re a Microsoft Dynamics CRM user in Finland and would be interested in networking with other fellow CRM professionals, I’m glad to announce that there’s now a new Yammer network available for you: Dynamics CRM Finland User Group. Whether you’re from a customer or partner organization, please feel free to sign up for this network and come join the planning for future events and other ways to share Dynamics CRM knowledge and experiences with peers. Tervetuloa!

September 30, 2014
Time Travel with Workflows: Accessing “Before” and “After” Values
Dynamics CRM has had a built-in auditing feature since the 2011 version, which provides a really handy tool for situations where someone needs to investigate the changes that have taken place on field values of a specific record. By default auditing is not enabled, but I recommend you to seriously consider enabling it for all business critical entities like accounts and contacts, since without it there’s not much to go by if you ever need to track down any intentional or unintentional updates made to your CRM data.

Auditing is a great tool for capturing the “fire hose” of data updates that are taking place in CRM. However, since the audit data is not stored in actual CRM records but rather in a denormalized state inside the audit database tables, it’s not accessible for any type of reporting or business process logic. If you know what record to look for, the related Audit menu will give you the information. If you are an administrator and have access to the Audit Summary View, you can also use filters to narrow down the audit data stream and hunt down the events that are relevant to your investigation. Very useful for resolving issues in the data, but not so practical for simply staying informed about updates that are of interest to your role in the organization.

Workflow processes can also be used for tracking specific changes made on the CRM records, just by setting the workflow to start when a particular field or a set of fields change. You can then perform any notification action you see appropriate, such as sending an email, creating an Activity Feed post, adding a note, appending a description field etc. Almost like auditing, but on a much more granular level, and also something that you can report on if necessary. One limitation compared to auditing, though, is that you can only see the new value of each field but not the previous one. So, you can’t produce a similar view that auditing provides, with the old and new values side by side.

Or can you? With the launch of the CRM 2013 version we gained a whole new category of workflow processes, called real-time workflows. These behave much in the same way as custom plugins, as they are executed synchronously as part of the event pipeline of the CRM platform rather than via the asynchronous service that the traditional workflows use. The extra benefit we gain from this, aside from the fact that the workflow logic is executed immediately, is that we now also have the ability to choose whether the real-time workflow should be started before or after the event. This allows us to actually read the data that was in a field before the update took place. Sounds like a cool little feature? Well why don’t we take it our for a spin then and see what we can achieve with it.

Tracking Account Name Changes

Let’s consider a scenario where we would be interested in tracking the changes performed on the account name field. We have decided to leverage the Activity Feeds feature to post a message on the record wall every time an existing account has its name field updated. As a part of this post, we need to provide both the old name and the new name, so that the users can easily associate this particular account as a customer they’ve previously done business with under a different name.

Since we need a place to store the old name of the account for the purposes of formulating the post’s content, first we’ll add a new custom text field for the account entity, called “Old Name”. Then we’ll open up the workflow editor and create a new real-time workflow process for the account entity, called “Account Name Change: Store Old Name”. The important part here is that we’ll set this workflow to be run when “Record fields change” with a box ticked for the “Account Name” field and change the “Start when” value to “Before”. The actual workflow actions only need to do one thing, which is to copy the value of the standard “Account Name” field to the new “Old Name” field. Nothing else.

Next we’ll create a second workflow, called “Account Name Change: Post Old & New Name”. We’ll set it to run in real time for the account entity, just like the first one. We’ll even associate it with the very same event, meaning the change of the “Account Name” field. The difference will be that we’ll run this workflow “After” the event. Again, the actions that the workflow will perform are very simple, as we’ll only need it to create a new Activity Feed post record. Here’s how the message will be configured with the dynamic field values from the account record:

So, we now have two real-time workflows running for the same entity, for the same field change event. Is this a smart thing to do? Will the universe by any chance collapse onto itself as a result of this reckless twin workflow configuration that we’ve built? Well, there’s only one way to find out! Let’s activate these two workflow processes, go to an account record and change it’s name.

After the name is changed, we can click onto the Activity Feed’s auto posts column to refresh the post view. There we discover a post created by our second workflow process, containing both the “before” and “after” names for this account. Success! If we keep feeding further update events to this workflow duo, we can see that the post message is always updated to contain the last two names for this account in search of its true identity.

If our second workflow process would have been an asynchronous process instead of real-time, the results might be different, though. As I’ve experimented in a previous post, “Auto-Numbering with CRM Workflows: Real-Time vs. Asynchronous”, the record data and execution order for traditional background workflow processes may not always be consistent, due to their asynchronous nature. By using a real-time workflow we are guaranteed to receive a ticket to the front row seats of CRM’s event execution pipeline. In practice this means the following:
- “Account Name Change: Store Old Name” – this workflow is executed at the pre-operation stage, which means that it sees the record as it was before the update event took place. Therefore when it reads the account name field it still has the old value stored. Furthermore, because the workflow is completed before the actual platform event for the account update takes place, it can inject a new value into the “Old Name” field and have it committed to the database as a part of the original transaction.
- “Account Name Change: Post Old & New Name” – this workflow is executed at the post-operation stage, meaning after the update has already taken place, but before the transaction is completely over. It receives an image of the account record where the standard “Account Name” field is populated with the new value the user has entered and the “Old Name” contains the value updated by the first workflow in the pre-operation stage.
As this example scenario demonstrates, while a workflow can’t directly compare the “before” and “after” values of a record, there is actually a workaround available where you could pass the old value from the pre-operation workflow to the post-operation workflow. You could then perform a comparison of the values with the tools that the workflow editor offers (or extend it via custom workflow activities) and alter the outcome of the transaction based on the business logic. If needed, you could even cancel the operation and show an error message to the user if the old & new values are violating the rules of your business processes.

To close things off, it’s important to keep in mind that just because you can do something with a workflow instead of custom code, it doesn’t mean it would always be the right tool for the job. Aside from the greater level of flexibility that a plugin will give you for comparing and manipulating the data during the update event, there are also performance considerations you should be aware of before pushing a ton of real-time workflows into your production CRM system. I recommend reading this post by CRM MVP Scott Durow: Real Time Workflow or Plugin?
September 14, 2014
Our New Book: CRM 2013 QuickStart
A few people have asked me for recommendations on what books they should get if they want to learn about the ins & outs of the current Microsoft Dynamics CRM 2013 version. Even though there’s a wealth of blog articles out there that study specific features and an ever growing library of content produced by Microsoft themselves, there’s not been a whole lot of material in traditional book format that would have covered the latest CRM 2013 functionality. Well, now there is a great title available that I can recommend: the CRM 2013 QuickStart.

How do I know the book is any good? Because I wrote a part of it! Aside from shameless self promotion, I can honestly say that the writing team behind this book is quite an extraordinary league of CRM experts:
If that’s not a group of CRM MVP’s you’d trust for advice on how to work with the platform then I don’t know who you would!

What exactly does the book cover then? As the title suggests, it’s not a complete A-Z of each individual feature included in the Dynamics CRM 2013 platform. Neither is it meant to be “my first Dynamics CRM manual” for people who are unfamiliar with any version of the product. Let me borrow some of the official intro text for the book here to explain the reason for its existence:

The CRM 2013 Quick Start is a first look at Microsoft Dynamics CRM 2013 and all the new features that have been included.

In the CRM 2013 Quick Start you will find details that can help administrators, customizers (functional consultants) and developers; not to mention power business users wanting to know all the details the admin never tells them. If you run CRM in the cloud or sitting in a server room at your office the information is useful.

This book is targeted to someone who has some CRM prior experience. By that we simply don’t spend any time explaining the basics of Microsoft Dynamics CRM from a beginner’s point of view. That said, the information in this book would still be useful on your journey to become proficient.

Imagine that you’re someone who’s started their Dynamics CRM journey with an earlier version like 4.0 or 2011 and you’re now faced with the upgrade project for moving the solutions onto the latest CRM 2013 version. Is this the right book for you to gain an understanding of what’s new & what has changed in the platform? Absolutely! How about if you’re a system administrator or a customizer that has some exposure to the new version (via CRM Online perhaps) but are looking to ramp up your knowledge about the platform for future projects, enhancements or admin tasks. Will the CRM 2013 QuickStart help you get up to speed faster than searching for random articles online? You bet!

Now, this is actually the first book that I have ever written content for and it makes me immensely proud to have managed to make my debut in such a prestigious crowd of co-authors. My personal contribution to this title focused on describing the founding principles of how to design a great user experience for the CRM solution that you wish to deliver to your end users. While some of the topics I covered in the book are specific to the latest CRM 2013 version, many of the solution design guidelines are actually universally applicable to any Dynamics CRM version, representing best practices that I’ve personally learned over the past decade of working with the product. I’m really glad to have been given the opportunity to present them in a format that allows for a different type of discussion than your typical blog post.

Being a newbie in authoring content for books, it was also a valuable learning experience for me. Although I’ve been writing down my thoughts on all things Dynamics CRM on this blog for six years now, the project of producing close to 50 pages of content on a given topic to create a coherent book chapter that can stand on its own was still a very different kind of assignment. Let’s just say that I have new found respect for authors that have managed to create entire books for new software products on their own.

The great thing about my writing project was that it provided me a really concrete reason to dig into the details of the various new customization options that Dynamics CRM 2013 offers and experiment with different scenarios that I’m likely to encounter in real life customer projects. As they say, the best way to learn a new topic is to teach it to someone else. If this content that I’ve put together as a part of my own learning process then ends up helping also other members of the Dynamics CRM community to discover better ways to solve customers’ problems with the application, then I consider that a win-win result.
July 21, 2014
Dynamics CRM Platform Evolution Revisited
In celebration of receiving my second Microsoft Dynamics CRM MVP award today (thanks to the whole #MSDYNCRM community for your support!), I’m publishing an article series on the Microsoft Dynamics CRM 2013 Customization and the Platform Evolution.

For the regular readers of my blog this title may sound eerily familiar, and you are correct. This is indeed a re-release of my earlier webcast topic that I presented in May for MSDynamicsWorld.com. I’ve previously shared the links to the live recording and the slide deck, but this time I decided to put it all down in writing. I had a huge pile of speaker notes, so I tidied them up a bit and published them as articles on this site.

Why bother revisiting the same old story? Well, it all comes down to my own behavioral patterns and personal preferences. You see, even though there’s an ever increasing number of webcasts, podcasts and other forms of streaming content published these days on highly interesting topics and shared all over the social networks I hang out at, I very rarely find myself actually consuming any of that content. Jeffry van der Goot nicely captured the underlying issue in his recent tweet:

Recordings of people presenting on a topic that they claim to be experts in just isn’t a very effective method of online knowledge sharing, if you ask me. Sure, you might be able to convey your message a lot more effectively with the help of audio and video, but the problem is that I, the audience, have a difficult time in assessing whether the content you’ve prepared really is worth my precious time (my precious free time in most of the occasions, I might add).

It’s not just that all of us can read much faster than we can listen. It’s the avenue of opportunities that a piece of information receives when it’s put down in writing. The audience will be given the chance the glance at the content from a higher level, scan through for highlights that capture their attention and, most importantly, easily revisit any of the words transmitted in this form of communication. The content producer, the presenter of words, also gets to enjoy the same benefits when reviewing his or her own thoughts in a structured manner and designing the detailed message that is to be delivered. Last but not least, written content is infinitely more discoverable via the tools we all now turn to when in need of answers to our everyday questions – the mighty search engines.

Now that I’ve explained the “why” behind the content strategy, it’s time to return back to the “what”. The Platform Evolution article series is about exploring some of the key themes that are shaping the process of how we can deliver customized business solutions on top of the Microsoft Dynamics CRM 2013 platform. The discussion is broken down into four parts:
- Part 1: The History. Where does Dynamics CRM as a product originate from and how did we get to where we are now with the CRM 2013 version?
- Part 2: Mobile Computing. How has the evolution of client devices affected the CRM platform and what should you know about the new client options?
- Part 3: Customizing CRM Today. What is the difference between a traditional CRM system and a modern business application built to match the CRM 2013 design language?
- Part 4: Delivering Responsive Solutions. How could we optimize the user experience of our application without diving into the sea of custom code?
Hope you find something of interest in these articles, but as said, they are there for you to conveniently scan through and judge for yourself. Because life’s just too short for sitting at your computer, watching long recordings that in the end didn’t quite deliver what you had expected.
July 1, 2014
Configuration Migration Tool: Working Smarter with Metadata Entities

If you mostly work with configuring the Microsoft Dynamics CRM solutions via the customization UI with its graphical point & click tools instead of writing custom code in Visual Studio, you may not keep such a close eye on the changes introduced in the CRM SDK. After all, the term SDK stands for “software development kit” and you may not consider yourself as the target audience if you don’t actually develop any new software that would interface with Dynamics CRM.

The What’s New page in the CRM SDK documentation is a place that would be very useful for also non-developers to have a look at whenever updates to the product are released. Apart from the end user guidance material published on CRM Customer Center, the SDK is pretty much the official place where changes to the platform functionality are introduced. With the latest CRM 2013 Service Pack 1 release (a.k.a Leo) now available, there’s a long list of new and improved features to review. One new addition that didn’t receive a mention on that page, though, is the Configuration Migration Tool, which is a very handy tool if you need to transfer metadata entities across different CRM organizations.

What Are “Metadata Entities”?

In theory the CRM solution files should contain all of the configuration data about your CRM organization. This is what is often referred to as metadata, which could be described as “data about data” in short. As an example, the list of possible values for the Relationship Type attribute on your account record would be considered metadata, whereas the actual account records referring to one of these values would be “real” data stored in the business entities. To illustrate the difference, a blank CRM organization containing only your customizations would not contain any records for the business entities (accounts, contacts, opportunities), but it would contain all of the records in the metadata entities that would be necessary for executing the customized business processes, since otherwise the configuration of that environment would be incomplete.

In practice there are often valid reasons for why it makes more sense to store this type of metadata in a custom entity of its own, instead of using option sets. This provides a whole different level of flexibility in terms of what type of metadata and how much information you can store. Maintaining the list of values can be done without the need to update the customizations. Filtering available records to the end user can be done via standard security roles and BU’s. Building dependent lists on the form can be achieved via the filtered lookups feature. You can leverage the new Quick View Forms to show data from related parental records. And so on.

One problem with using these type of metadata entities is that the data cannot be packaged into a CRM solution file. While you can easily export any changes to the standard customization components and move them to a different CRM organization, getting the metadata entity records from one org to another requires a bit more effort. As a result, keeping the different development, test and production environments in sync requires specific attention to be paid on these metadata during the release process.

Introducing the Configuration Migration Tool

The CRM 2013 Service Pack 1 release includes the new Unified Service Desk (USD) application that relies heavily on storing its configuration data into these metadata entities. In order to support the systematic deployment of USD solutions configured for the customer’s environment, Microsoft has introduced new tools in the version 6.1 (a.k.a. CRM 2013 SP1) SDK. These are the Configuration Migration Tool and the Package Deployer tool. While the latter one is surely useful in deploying larger ISV solutions, I believe it’s the Configuration Migration Tool that can benefit a far wider audience. Also, since you don’t need to run Visual Studio to work with the tool, I’m personally more comfortable discussing its features in my blog as a non-developer who generally steers clear from anything that isn’t close to point & click.

In short, what the Configuration Migration Tool (from here on referred to as “CMT”) allows you to do is 1) choose the entities that you want to migrate data from, 2) export all the records from those entities as a .zip file and 3) import it into a different CRM organization. There’s a great illustration available in the SDK article describing CMT, presented below:

“Awesome, now we have a built-in tool for CRM data migrations!” Well, actually, no. While CMT can move a set of records from several entities in one package and maintain their relationships, it has not been designed for the purpose of business data migration. For example, you cannot filter out any of the records to be transferred from the source organization, nor are there any guarantees for the tool’s performance when moving very large sets of data. Here’s what the Dynamics CRM product team has to say about the tool:

Check out this CMT feature overview video on YouTube for more information on the above points.

Moving Configuration Data with CMT

Let’s see how the tool works in practice. To test the features, I created two custom entities for storing my configuration data: “Category” and “Subcategory”. A category can have many subcategories (1:N relationship), but in order to make the experiment more interesting, I also added a lookup on the category form that allows selecting the default subcategory to be used. So, we have both a 1:N and N:1 relationship between our entities, as shown on the Category form below. For the purpose of testing I added category A with subcategories 1*, 2, 3 and 4, then category B with subcategories 1 and 2*, with the asterisk determining the chosen default subcategory (notice the duplicate names in the subcategory data, we’ll get to that later on).

After launching CMT, choosing to define the schema (step 1) and entering the connection information to log into my own development CRM 2013 server via IFD (hint: enter the server URL with the org name as “org.domain.com” and the user name as “user@domain.com, no other connection option worked for me), we’re presented with a screen for choosing the components to be included in the schema. We can pick from entities included in a specific solution. After selecting the entity, we can either choose which fields we want to transfer data from or just be lazy and add the whole entity into our schema definition. Save and Export will give us an XML file with the contents from the included entities, fields and relationships.

The next step is the data export. Here we’ll choose the schema XML we just created and a target file for the data export. Hitting the Export button will start the process, report the progress for each entity in the CMT app window and finally produce a .zip file containing the data for all the components defined in the schema file.

The last step is to connect to a different organization that already has the same schema. So, if you’ve not yet transferred your solution files into the target organization, now’s the time to do that, since CMT will not modify the organization schema, but rather just assume that it is identical to the source organization as far as the selected entities and fields go. (more…)

June 9, 2014