Monday, March 17, 2014

CRM 2011 to 2013 (Orion) Top 10 Upgrade Tips and Considerations (part 2)

This is part 2 of my previous post which helps identify tips and gotchas of CRM 2013 upgrade. Click here to read the first part: Top 10 Upgrade Tips and Considerations (part 1).

So it’s time to upgrade to CRM 2013 and the questions we always get are:

What is the impact?

What do I need to do to make sure my organization will continue to work in CRM 2013?

What are the tips and tricks for upgrading to CRM 2013?

How can I estimate the effort to upgrade?

 

So I will attempt to provide a checklist of the top 10 most common aspects of the upgrade that you should keep in consideration. In my previous post I addressed the top 5 and and here are 5 additional considerations/tips:

 

5. Mobility

Because of the limited mobile functionality of CRM 2011 (mobile express) it is easy to assume that there is no effort required to migrate your mobile express application to CRM 2013 except perhaps some testing effort. However, if you are thinking of taking advantage of the new mobile application (e.g. CRM for tablets) in CRM 2013 then you need to consider that if you are in On-Premise you might need to include additional effort to enable IFD if it is not already configured. Mobile application in CRM 2013 is only supported with claims authentication and IFD mode. Additionally, if you have third party mobile solutions (e.g. Resco, CWR) then refer to the previous paragraph.

 

6. AutoSave

If you have used the new forms of CRM 2013 you might have noticed the new Auto-save feature. By default, users are not required to click “Save” when updating a record. Every 30 seconds after editing a field, the form will automatically submit a save request in the background. Clicking some commands such as “new”, “qualify” or closing the form will also issue a save request to the server (note: it does not apply to the create form).

The impact of auto-save is that each auto-save is an update operation in the database so plugins and workflows will trigger and auditing will occur. You need to consider that if the user takes 2 minutes to update a form, then at least 4 updates will actually occur on the server side.

So why is this important for upgrade? Well, you could argue that this is nothing to worry about since this behavior corresponds to how some users are actually saving multiple times in fear of losing their updates, but it is now done automatically. I tend to agree with that but in reality some developers do not consider those type of users when designing plugins or workflows. You need to ensure that your plugins and workflows will not break because of auto-save; one typical recommendation is to limit the “triggering attributes” of an update plugin to only those fields that when changed should really trigger the plugin. This is more of a review exercise and you might not need to make any changes.

On the client side each time auto-save occurs, the fields that changed in the server will be refreshed in the form, but the OnLoad event will not be triggered because the form will not be refreshed. You need to ensure that your form scripts will not break because of this new behavior and if necessary you might need to use the new GetSaveMode() method on your OnSave scripts to identify how the save originated. You can use this same method to prevent auto-save from occurring by intercepting the OnSave and discarding any save originating from auto-save.

Note that you also have the possibility to disable auto-save at the organization level which might make things easier to manage since you don’t need to assess the exact impact of auto-save when upgrading to CRM 2013. However, I think auto-save is a great feature and should not be disabled for the wrong reason (e.g. laziness to manage the upgrade impact).

 

7. New forms, sitemap and navigation

Inevitably your forms and sitemap will need to be reviewed since the navigation and user experience changed so drastically in CRM 2013. It is very likely that you will need to re-design your forms because the new layout is different and you might want to take advantage of the new form features such as the social pane. You will also need to consider the command bar and make sure your 5 visible commands are actually the most common ones, otherwise you might need to adjust the command bar (ribbon). Keep in mind that in CRM 2013 the form tab index has disappeared so if you had large forms in CRM 2011 divided in multiple tabs, users will now need to scroll down to find the tab they are looking for and there is no quick access tab index as we had in CRM 2011. In general, CRM 2013 goes with the principle of simplicity and usability so you might need to simplify your forms, include less fields, maybe split your large forms into multiple forms, etc.

In terms of sitemap, you might have noticed how different it is to navigate different parts of the application. For the most part according to feedback from the community, it has become harder to be efficient when navigating between different modules of the application. Consider the scenario of a service representative talking to a client and then generating a lead from the conversation. The service representative might need to change from “Service” to “Sales” often and this is much harder to do in CRM 2013 as you might need to scroll horizontally to find your entity and the navigation will also disappear by default requiring more clicks to bring it back. Therefore, you might need to optimize your sitemap for your organization to keep users happy with CRM and minimize the amount of time they spend switching areas. For example, making sure that the most common entities appear first in each area so users don’t have to scroll every time to reach the entity tile they need to work with.

 

8. Migrate customizations to built-in features

While you might be sure that your customizations will continue to work after the upgrade, it would be great to consider whether you can “un-customize” the system and migrate some of those customization to use built-in features that are configurable. This will of course increase the amount of effort for the migration but will simplify your deployment and make it more maintainable down the road, it is usually an “easy” sell for customers since the advantage is very evident.

As an example, you might have multiple javascripts that perform conditional actions on forms and maybe most of these can be re-written using Business Rules. If you take the time to replacing your scripts with Business Rules then you gain the advantage that the business rules are configurable, no developer will be required to make changes and additionally since it is now a CRM feature, it could be enhanced in future versions of CRM thus setting you in the right path. Similar examples are: Custom notification in forms can be replaced with the new built-in notification bar, custom Bing maps integration, custom image for records can be replaced with the new image field, etc.

Another example of this is customers that use third party mobile solutions for simple mobile scenarios that can now be supported with CRM 2013 built-in mobile features. If you migrate to the built-in mobile features then you will save considerably on infrastructure, maintenance and licensing.

 

9. Infrastructure

Unless you are working with hosted CRM (e.g. CRM Online), infrastructure is always something you need to consider. I suggest you review the CRM 2013 implementation guide and review all the infrastructure considerations. If you are doing an upgrade, it is always recommended that you setup a parallel environment in CRM 2013 to which you will import the CRM 2011 organization instead of doing an “in-place” upgrade because it will make it easier to do multiple trials and have a better roll-back strategy. It is supported to import CRM 2011 organizations to a CRM 2013 deployment and upgrade the organization during the import. Once the upgrade completes you can decommission the CRM 2011 environment.

Keep in mind that the server and client minimum requirements have changed for CRM 2013 so you need to ensure that you are covered from all angles (operating system, browser support, SQL version, etc.).

Another infrastructure-ish consideration is to have a strategy around the extension tables merge. If you are not familiar with this, here is a brief explanation: In CRM 2011 each entity has a base table and an extension (e.g. custom fields) table. As part of the performance improvements of CRM 2013, these two tables are now merged into a single table. Therefore, when you upgrade an organization from CRM 2011, the table merge is one of the upgrade operations, but it is a special one for a number of reasons:

  • It is not a required upgrade step. You can skip this step and continue to use your upgraded organization. However, there might be some performance implications by not merging the tables
  • Depending on the data volume, it can take a long time to merge these tables which can considerably increase your downtime during upgrade
  • If you decide to skip this step, you can always perform it in the future (another downtime window will be required).

Therefore, when you start testing your upgrade, if you notice that it takes a really long time you might want to defer the table merge to a later date. This way you can split the downtime into 2 different time windows. In order to defer the table merge, there is a registry setting that you need to set during upgrade and then to perform the merge at a later date you need to run the CrmMergeBaseAndExtensionTableTool.exe tool located in the CRM server under c:\Program Files\Microsoft Dynamics CRM\Tools.

 

10. Avoid platform-only upgrade

If you are upgrading to CRM 2013 and are just doing a platform upgrade (upgrade as is, no changes to current customizations), then you should think twice the question: Why do I need this upgrade? CRM 2011 is still supported for some years so the primary motivation for an upgrade is to take advantage of the new features. So if you are just doing a platform upgrade, then the upgrade motivation is questionable.

My recommendation is that when you start the upgrade discussion with your customers, start delivering the message early on that there are multiple advantages of CRM 2013 and that the upgrade is just a great opportunity to explore these. Consider the upgrade planning as the opportunity to adapt your CRM deployment and customizations to whatever CRM 2013 has to offer, simplify the deployment and maintenance of your environment while keeping end users happy and engaged with the application by providing them great new features.

Monday, March 10, 2014

CRM 2011 to 2013 (Orion) Top 10 Upgrade Tips and Considerations (part 1)

This post aims at helping organizations understand the impact of upgrading to CRM 2013 and provides tips for assessing the upgrade considerations. It does not provide an exhaustive list of all the possible items you need to validate before upgrading but it provides a list of the most common ones.

So it’s time to upgrade to CRM 2013 and the questions we always get are:

What is the impact?

What do I need to do to make sure my organization will continue to work in CRM 2013?

What are the tips and tricks for upgrading to CRM 2013? How can I estimate the effort to upgrade?

 

So I will attempt to provide a checklist of the top 10 most common aspects of the upgrade that you should keep in consideration. In this post I will address the top 5 and you can expect a follow-up with the next 5.

 

1. Deprecated Features

Some features from CRM 2011 were already marked as obsolete and have been deprecated in the new version. I am providing a list to the best of my knowledge of those features. If you have a CRM 2011 environment that you upgraded from CRM 4.0 it is more likely that this will be a problem since many CRM 4.0 features/endpoints/APIs have been deprecated although they continued to work on CRM 2011.

A. CRM 4.0 plugins and custom workflow activities. If you have plugin assemblies that were compiled against the CRM 4.0 SDK then you will have to re-write and recompile against the CRM 2013 or CRM 2011 SDK.

B. CRM 4.0 client side scripting. If you have javascripts that make use of the CRM 4.0 client side scripting API (e.g. “crmForm”) you will need to re-write them to make use of the CRM 2013 or CRM 2011 API (e.g. Xrm.Page…).

C. 2007 web service endpoint. If you have any external applications or any code that is referencing the 2007 endpoint (asmx) then you need to update them and recompile then using the CRM 2013 or 2011 SDK and point to the endpoints supported in CRM 2013 such as the OrganizationService (WCF) or the REST endpoint (OData).

D. ISV folder. The ISV folder was made obsolete in CRM 2011 for hosting custom web applications inside the CRM ASP.net root. This folder is no longer supported in CRM 2013 so you would have to move those custom web pages to a separate IIS website.

E. Reduced ribbon support. With CRM 2013 new user experience you might have noticed that the ribbon has been replaced with the new command bar. The good news is that when you upgrade, most of your ribbon customizations will be automatically upgraded to the new command bar model, only a small subset of ribbon controls are no longer supported: Dropdown, MRU Split Button, Textbox, Insert Table, Gallery and Gallery Button, Combobox and Color Picker. It is quite rare to make use of those controls which are no longer supported so most organizations will be fine after the upgrade but it is always a good idea to review your custom ribbon rules and make sure you are not making use of those controls. In case you are, you’d need to replace them by some of the supported command bar controls (see SDK for details). The other important consideration with CRM 2013 is that the command bar will only display 5 commands and the rest need to be expanded by clicking on the “…” icon. Therefore, fore usability, you might need to refactor your command bar to place the true 5 most used commands in the bar and move all others to the “expand” section.

F. Read-optimized forms. This was a short-lived feature of CRM 2011 that came with CRM 2011 UR7 and has been removed in CRM 2013. More information on this feature here.

G. Duplicate detection during create and update in forms. In CRM 2013 duplicate detection will not kick-in during record creation or updating via the application forms. This is a well known limitation and although you might find tons of workarounds on the web (e.g. this article from MVP Adrii Butenko), it is possible that Microsoft will bring this functionality back. For now, you might need to do a custom extension for duplicate detection if you rely on it. Note that duplicate detection is still supported when making SDK calls and setting the SuppressDuplicateDetection optional parameter in your create or update request.

 

2. Unsupported customizations

Having unsupported customizations is never a good idea and I have blogged in the past why: The Risks of Unsupported Customizations in CRM. So it would be a great opportunity to review which unsupported customizations you have since they will likely break when you upgrade to CRM 2013. The tricky question is: How do I identify unsupported customizations? As a rule of thumb, any extensions to CRM that you make which are not explicitly documented in the CRM SDK are unsupported. Now, that might be too vague and sometimes not completely accurate but it is my favorite way of defining unsupported customizations. If you want to be a little more specific here is a list of unsupported customizations that I compiled from the SDK and a couple from experience:

  • JavaScript developers are used to interacting with Document Object Model (DOM) elements in code. You might use the window.getElementById method or the jQuery library. You are free to use these techniques in your HTML web resources, but they are not supported to access elements in Microsoft Dynamics CRM application pages or entity forms. Instead, access to entity form elements are exposed through the Xrm.Page object model. The Microsoft Dynamics CRM development team reserves the right to change how pages are composed, including the ID values for elements, so using the Xrm.Page object model protects your code from changes in how pages are implemented.
  • We do not recommend using jQuery in form scripts and ribbon commands (Note: previously this was called out as unsupported and in CRM 2011 has been updated to “not recommended” in CRM 2013). If jQuery accesses the page DOM then it would be clearly unsupported for CRM forms.
  • Modifications to any .aspx, .css, .htm, .js, .xml, .jpg, or .gif files or the addition of files in the wwwroot directories of the Microsoft Dynamics CRM application, Microsoft Dynamics CRM tools, or Microsoft Dynamics CRM files located at Program Files\Microsoft Dynamics CRM. However, if you have made changes to these files, these files are checked for modifications and will not be overwritten.
  • Modifications to the Microsoft Dynamics CRM website (file and website settings). Custom solutions should be installed in a different website. This includes modifications to the file system access control lists (ACLs) of any files on the Microsoft Dynamics CRM server.
  • Use of client certificates is not supported by the Microsoft Dynamics CRM SDK. If you configure the Microsoft Dynamics CRM website to require IIS client certificates, you will get authentication failures for any applications that were built using the SDK.
  • Modifications to the physical schema of the database, other than adding or updating indexes. This includes any actions performed against the database without using the System Customization capabilities in the web application or using the metadata APIs that are described in this SDK documentation. Modifying tables, stored procedures, or views in the database is not supported. Adding tables, stored procedures, or views to the database is also not supported because of referential integrity or upgrade issues. For Microsoft Dynamics CRM 2013 on-premises deployments, adding indexes is supported per the guidelines in the “Microsoft Dynamics CRM 2013 Implementation Guide.” This applies to all Microsoft Dynamics CRM databases and the Microsoft Dynamics CRM for Microsoft Office Outlook local database.
    When you change the database without using the support methods for system customization, you run the risk of problems occurring during updates and upgrades.
  • Data (record) changes in the Microsoft Dynamics CRM database using SQL commands or any technology other than those described in the Microsoft Dynamics CRM SDK.
  • Referencing any Microsoft Dynamics CRM dynamic-link libraries (DLLs) other than the following:
    • Microsoft.Xrm.Sdk.dll
    • Microsoft.Crm.Sdk.Proxy.dll
    • Microsoft.Xrm.Sdk.Workflow.dll
    • Microsoft.Xrm.Sdk.Deployment.dll
    • Microsoft.Crm.Outlook.Sdk.dll
    • Microsoft.Crm.Tools.EmailProviders.dll
  • The use of application programming interfaces (APIs) other than the documented APIs in the web services DeploymentService, DiscoveryService, Organization Data Service, SOAP endpoint for web resources and OrganizationService.
  • To achieve the appearance and behavior of Microsoft Dynamics CRM, the reuse of any Microsoft Dynamics CRM user interface controls, including the grid controls. These controls may change or be overwritten during an upgrade. We do not recommend that you use or change the Default.css file in the Microsoft Dynamics CRM root installation folder.
  • The reuse of any Microsoft Dynamics CRM JavaScript code, including ribbon commands. This code may change or be overwritten during an upgrade.
  • Modifications to any one of the Microsoft Dynamics CRM forms or adding new forms, such as custom .aspx pages, directly to Microsoft Office Outlook or making changes to .pst files. These changes will not be upgraded.
  • Making customizations except when you use the Microsoft Dynamics CRM supported tools available offline in the CRM for Outlook.
  • The use of custom HttpModules to inject HTML/DHTML into the Microsoft Dynamics CRM Forms.
  • Creating a plug-in assembly for a standard Microsoft Dynamics CRM assembly (Microsoft.Crm.*.dll) or performing an update or delete of a platform created pluginassembly is not supported.
  • Creating an Internet Information Services (IIS) application inside the Microsoft Dynamics CRM website for any VDir and specifically within the ISV folder is not supported. The <crmwebroot>\ISV folder is no longer supported.
  • Editing a solutions file to edit any solution components other than ribbons, forms, SiteMap, or saved queries is not supported. For more information, see When to edit the customizations file. Defining new solution components by editing the solutions file is not supported. Editing web resource files exported with a solution is not supported. Except for the steps documented in Maintain managed solutions, editing the contents of a managed solution is not supported.
  • Silverlight Application Library Caching is not supported.
  • Adding custom indexes is not unsupported but I am not 100% clear about updating/deleting built-in indexes.

 

 

3. Code inspection or analysis tools

There are a number of tools that you can install to help you assess the code that you need to review before upgrading. These tools will typically find most of the issues with your existing code and tell you what action you need to fix them before upgrading. However, do not rely 100% on these tools as they are not fully deterministic, but it is a great deal of help. Here are some examples:

CRM 2013 Custom Code Validation Tool

CRM 2011 Custom Code Validation Tool

Microsoft Baseline Configuration Analyzer for CRM (determines if your CRM 2013 environment is configured according to best practices)

 

4. ISV solutions

If your CRM organization is using third-party solutions it is always required that you reach out to the ISV and validate the compatibility with CRM 2013 before making any assumptions. In some cases the solution will upgrade automatically while in other cases manual intervention will be required to make the ISV solution work with the new version.

 

5. Mobility

Because of the limited mobile functionality of CRM 2011 (mobile express) it is easy to assume that there is no effort required to migrate your mobile express application to CRM 2013 except perhaps some testing effort. However, if you are thinking of taking advantage of the new mobile application (e.g. CRM for tablets) in CRM 2013 then you need to consider that if you are in On-Premise you might need to include additional effort to enable IFD if it is not already configured. Mobile application in CRM 2013 is only supported with claims authentication and IFD mode. Additionally, if you have third party mobile solutions (e.g. Resco, CWR) then refer to the previous paragraph.

Sunday, February 23, 2014

All about outer join queries in CRM 2011 and CRM 2013

 

Outer joins are the way to implement the commonly requested queries in which you are searching records that have no child records (e.g. All accounts without contacts, all users without security roles, etc.). This article explains what the options are for such queries in CRM.

A recurring business scenario is to have a view of records with no child records (display all leads without activities, accounts that have no contacts, etc.) and we also have sometimes a similar requirement but for N:N relationships, for example, provide a list of all users without security roles. Unfortunately achieving these requirements is not as straight forward as we’d like.

Ideally we’d like to be able to use Advanced Find to produce those results. The reality is that Advanced Find does not support outer join constructs so we are not able to build such queries. So what are the options?

 

1. CRM 2011 or CRM 2013: SQL Report

If you are not in CRM Online you can always build a custom SSRS report and build your SQL query to provide such results. This is a very straight forward query in SQL. For example, if you’d like to retrieve all leads that have no tasks associated the following query will do:

SELECT lead.FullName
FROM Leads as lead
LEFT OUTER JOIN Tasks as ab
ON (lead.leadId = ab.RegardingObjectId)
WHERE ab.RegardingObjectId is null

 


2. CRM 2011: Use the SDK


You can always use the CRM SDK to query records and process the results. However, there is no way to specify an outer join in a QueryExpression, FetchXML or LinqExpression in CRM 2011 in the way that we need. Note that you might find a “LeftOuter” join type in the JoinOperator enum, however, this will not help you in this case. Therefore if you want to retrieve all leads without tasks you’d have to do multiple queries and filter the results manually in your application. For example, if you are looking for all leads without tasks then you’d have to first retrieve all leads and then retrieve all tasks regarding a lead. Finally, you’d then have to merge the results to exclude from your entire lead list those that have a task from your second query. This is less than ideal because if you have thousands of records then making use of paging can be a challenge. It is also not possible to have a view in CRM that would return these results because the CRM platform in CRM 2011 does not support this construct in a single query operation.


 


3. CRM 2013: Use FetchXML


The good news is that in CRM 2013 the platform has been improved to be able to process these type of queries. Therefore FetchXML capabilities and syntax have been expanded to be able to use outer joins. For our example of retrieving all leads without tasks, this would be the fetchXML you would need:


<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true">
  <entity name="lead">
    <attribute name="fullname" />
    <link-entity name="task" from="regardingobjectid" to="leadid" link-type="outer">
       <attribute name="regardingobjectid" />
    </link-entity>
    <filter type="and">
        <condition entityname="ab" attribute=" regardingobjectid" operator="null" />
    </filter>
  </entity>
<fetch/>

The bad news is that the Advanced Find interface does not yet support designing these type of queries. However, you can update the fetchXML of your system view or your saved query and it will work (users can access this query via CRM views), nonetheless, they will not be able to design or modify this query in the Advanced Find designer, they can only see the results. To update the FetchXML you would need to export the view in a solution and then modify the FetchXML of your view in the customizations.xml file, then you can import the solution back and voila.

 


4. CRM 2013: Use QueryExpression


Since we know that besides aggregation capabilities, FetchXML and QueryExpression are equivalent (any FetchXML query can be converted to QueryExpression and vice-versa), then we know that QueryExpression has also been expanded to support outer joins. Here is the CRM 2013 syntax you can use in your QueryExpression for outer joins, the following query returns all leads that have no tasks associated:

QueryExpression qx = new QueryExpression("lead");
qx.ColumnSet.AddColumn("subject");

LinkEntity link = qx.AddLink("task", "leadid", "regardingobjectid", JoinOperator.LeftOuter);
link.Columns.AddColumn("subject");
link.EntityAlias = "tsk";

qx.Criteria = new FilterExpression();
qx.Criteria.AddCondition("tsk", "activityid", ConditionOperator.Null);

 


 


Perfect, now what about N:N relationships?


For example, how can you query users that have no security roles associated? (There is an N:N relationship between user and security role). The trick with N:N relationships is that the “intersect” entity is actually an entity that can be queried, therefore you can see N:N relationships as two 1:N relationships:



SystemUser : Role (N:N)


Is the same as the combinaation of these two:



SystemUser : SystemUserRoles (N:1)



SystemUserRoles : Role (1:N)


Every N:N relationship has an intersect entity, in the case of the user : role relationship, the name of the intersect entity is “systemuserroles”. Therefore if you want to query users that have no security roles, this is the same as querying users who have no SystemUserRoles (intersect entity) associated, and that is a simple 1:N relationship. So you could simply do it in this way:


QueryExpression qx = new QueryExpression(SystemUser.EntityLogicalName);

LinkEntity link = qx.AddLink(SystemUserRoles.EntityLogicalName, "systemuserid", "systemuserid", JoinOperator.LeftOuter);
link.Columns.AddColumn("fullname");
link.EntityAlias = "sur";

qx.Criteria = new FilterExpression();
qx.Criteria.AddCondition("sur", "systemuserroleid", ConditionOperator.Null);

Saturday, February 15, 2014

Pregúntale a los expertos CRM!


Para todos los hispanos interesados, nuestros amigos de la Comunidad CRM han organizado un evento este jueves 20 de Febrero para responder preguntas generales de la comunidad. Regístrate y envía tus preguntas para que varios líderes de la comunidad CRM te respondan en vivo.
Las siguientes personas (MVPs o empleados de Microsoft) estarán presentes para responder tus preguntas:
•Gus Gonzalez (MVP, Zero2Ten)
•Damián Sinay (MVP, Remoting Coders)
•Ramón Tebar (MVP, MetroBank)
•Demian Raschkovan (MVP, Infoaván)
•Gonzalo Ruiz (MVP, Avanade)
•Pablo Peralta  (MVP, UruIT Dynamix | CRMGamified)
•Jimmy Larrauri (Microsoft)
No olvides registrarte y enviar tus preguntas!


Wednesday, October 30, 2013

Quick Views in CRM 2013

One of the simplest and most exciting features of CRM 2013 (Orion) is the ability to embed and display fields from the parent entity in the form a given record. This feature is not nearly as promoted as other features but I like it so much I will write about it.

Many times in the past I have struggled with the need to include fields from a related entity in the form of a given record. Typical scenario is that you would want to include the account number and the primary contact of the account in the form of a given case for which the customer is an account. Additionally, if the customer of the case is a contact, then I’d like to display in the case form the contact name, contact phone number and list of activities associated with the contact in the case form. While this was a nightmare to implement in previous version of CRM (require custom web resources that query and display data from related entities), all this is possible very easily out-of-the-box with MS CRM 2013 without having to write a line of code.

First, I will define the quick view forms for contact and account which I will later include in the case form:

image

image

image

 

Now that I have defined the quick view forms for both the accounts and contact, I can modify my contact form to include the related information form the account/contact. I have created a “Customer Details” section in the case form and will now insert the quick view forms I defined earlier:

image

 

Then I need to specify the quick view forms that I will use and for which lookup field it applies:

image

 

After I publish my case form, this is what it looks like if the contact of the case is an account:

image

 

If I change the customer field on the case, the form is updated dynamically and the “customer details” section is updated to display the contact quick view form I defined:

image

 

You can see that I can even insert sub-grids for records related directly to my lookup field (in this case activities related only to my customer contact). It is also  worth noting that fields from the quick view form are always read-only (e.g. From a case form, I cannot see the phone number of the contact associated, but I cannot edit it). If I need to edit fields from the related record I have to open the record and edit them in the regular form.

Tuesday, October 29, 2013

Filtering activities by type in CRM views

In some scenarios you might want to wish to filter your activity views by activity types. While it sounds very trivial it can be a bit more complex in the context of solutions because activity type is stored as objecttypecode (OTC) which is different in each environment for custom activities.

 

Scenario

I defined a custom activity called “Follow-up” and I would like a view/sub-grid in the account form which shows me all the related Follow-ups to the account (I don’t want to see any other activity there). I also don’t want to create an additional relationship between Account and Follow-up but rather use the generic “Regarding” lookup that is used by all custom activities.

 

Solution #1

I can simply define or edit an existing view and use the field “Activity Type” (activitytypecode) to filter and show only the activity type that I desire:

image

After I do this I can use my view in a sub-grid and voila, very simple, I now have a sub-grid in the form which displays related activities but only those of type “Task” and “Follow-up”:

image

 

The problem with solution #1

The problem now is that when I transport this view and form to QA/Prod or to another CRM organization, it might break. The reason is that the view uses the activitytypecode field to filter on activity type. This field references an objecttypecode (OTC) which is a unique number given to each entity. For system entities (task, accounts, etc) the OTC is the same in all environments. However, for custom entities, new OTCs are assigned incrementally so there is no guarantee that they are consistent across environments. In my dev environment, this is what my view definition looks like in the exported solution:image

While I can be sure that 4212 is always “task” in all environments, I cannot be sure that 10007 is my custom activity “Follow-up'” in all environments. In fact, an entity with OTC 10007 might not even exist in other environments, even if my custom “Follow-up” entity does exist (but with a different OTC).

 

Solution #2

If I would like to avoid my solution referencing a hard-coded OTC, I can use linked-entity in my view as a work-around. However, I cannot edit the views in the view designer of the application because it does not support joins. I would need to export my solution and edit the view XML in the solution file and then import it back. I will update the XML of the view I defined above in order to retrieve all tasks and follow-ups but without using the activitytypecode attribute:

image

Note that there is no reference to any objecttypecode in the view definition above, but it will automatically filter to show only activities of type new_followup because of the inner join. In order to update the view XML you will need to include the Activity entity to a solution, export the solution and then look for your view in the customizations.xml file and update the view definition fetchxml.

The problem with solution #2

Although solution #2 will work in all environments and will not break even if you transport the solution to another organization (as long as the new_followup entity exists), there are some disadvantages of this approach: First, the view filter criteria cannot be edited using the application view designer (so you will always need to update the XML if changes are required). Second, this only works if you want to filter to display a single activity type. However, if your requirement is to filter the activities to show 2 or more activity types (e.g. Follow-ups and tasks) then you will not be able to do this solution and only then I’d recommend solution #3.

 

Solution #3

Thanks Jukka for suggesting this. Every activity has at least on activity party (at least the owner). Therefore, we can leverage the activity party relationship to display “all activities which have an activity party which has a parent activity of type X”. This is what the query would look like if I only want to display Follow-up activities for example:

image

The problem with solution #3

The only problem with this solution is that it only works if you want to display a single activity type. If for example you have multiple custom activities and you want a view to display only follow-up and task activities then this will not be possible. Note however that if you want to display only custom activities you can easily filter out the out-of-the-box activities using solution #1 with a filter of “Does Not Equal (task,appointment, etc).” and that will be fine to transport across organizations because OTC for out-of-the-box activities are always constant.

 

Solution #4

You might be disappointed but if you need to filter to display more than 1 activity type but not all activity types, and you are using custom activities in your filter, then the only other solution would be to stick to solution #1 (see above) and then create a tool that automatically remaps the objecttypecode in the views xml to replace it with the appropriate objecttypecode in the target environment. You could do so as a stand-alone tool or you can have a post-solution action which does this for you (using the solution configuration page web resource).

Sunday, October 27, 2013

Join the CRM 2013 experts round table in Spanish

On October 31st the most distinguished CRM experts in the Hispanic community are getting together to discuss in a virtual round table the new features of Microsoft Dynamics CRM 2013 (“Orion”) and the challenges for migrating.

The following attendees are invited:

  • Gus Gonzalez (MVP, Zero2Ten, moderador de la sesión)
  • Damián Sinay (MVP, Remoting Coders)
  • Ramón Tebar (MVP, MetroBank)
  • Demian Raschkovan (MVP, Infoaván)
  • Gonzalo Ruiz (MVP, Avanade)
  • Pablo Peralta  (MVP, CRMGamified)
  • Jimmy Larrauri (Microsoft)

 

Additionally, you can ask your own questions in advance! Please leave your questions here and let the experts do the best to answer* during the session.

* We will try our best to respond all questions during the discussion and the timeframe we have. Given the time limitations we cannot commit to answer all questions although we will try our best.

Don’t miss out this opportunity, even if is just to practice your Spanish (even my Spanish is a bit rusty)! Thanks to Gus and Pablo for being the champions organizing this event!

Register for the event here.