Microsoft CRM – Moving Views Between Development and Production With Inaport

At times in chez InaPlex, we are slightly dumbfounded by where our users take our product.

Guest blogger Justin Knieling of Grand Canyon University has been pushing the boundaries for a while, but now he has excelled himself. In this post, he describes using Inaport to move MSCRM views from one organization to another. Please note that in this particular scenario, he is using a SQL connection to the source CRM system, as he has it on premise. This might not work, or may need modification, if you are running hosted.

Over to Justin…

We often find ourselves needing to move system views from one Microsoft Dynamics CRM 2011 organization to another. A recent example of this was when we had a department who wanted to start using the case entity in CRM. They developed views to display their department’s cases along with some other views for activities related to the cases. Overall, I think there were about 15 views they created in our development environment.

When the time came for them to move into our production environment, I was not comfortable moving the entire cases entity from development to production as we had other users already using it in production and I have seen errors when trying to move solutions of existing items like this. So, a solution move for their changes was out. I was dreading having to re-create all those views by hand. I began searching the web for a tool that could do this, and found nothing. The closest I came was a tool that could copy the layout from one view to another within the same entity in the same organization.

A thought struck me; all the views are stored as xml in the database, why couldn’t I just use Inaport to move them? The fields were all named the same between the two orgs, so I wouldn’t see any issues there. All filtering values were the same, no problem there. The only question was whether I could use the web services connection available in Inaport to write these values back into CRM.

I fired up my copy of Inaport and set my source connector to the CRM SQL Server of our development environment. I set the target connector to our CRM connector for production. I flipped to the Match and Map to Target tab and sure enough it had an option to write to a savedquery table. I came up with the following query to actually retrieve the data from the database:

SELECT v.SavedQueryId, v.SavedQueryIdUnique,
    tv.AdvancedGroupBy, tv.ColumnSetXml, tv.ConditionalFormatting,
    tv.[Description], tv.FetchXml, tv.IsCustomizable, tv.IsDefault,
    tv.IsQuickFindQuery, tv.LayoutXml,  tv.Name, tv.QueryAppUsage, 
    tv.QueryType, tv.ReturnedTypeCode, tv.SavedQueryId, tv.StatusCode
FROM DevOrg.SavedQuery tv WITH (NOLOCK)
LEFT OUTER JOIN ProdOrg.SavedQuery v WITH (NOLOCK) ON tv.Name = v.Name
WHERE tv.Name IN (List view names you want moved here)

Simply insert the names of the views you want to move and you are good to go. You’ll notice that I join our production org to get the GUID if the view already exists. This means you can update an existing view or create a brand new one.

In Inaport the field mapping looked like this:

Copy View Map

I tested the job and it all worked great. Since then, I’ve used this method a few other times and never run into any issues. Another great and unexpected use for this tool.