How to show SharePoint document list on main CRM form

When you enable the SharePoint integration for CRM, you get the ability to view a document list view by navigating to the document area on the form. Often, users want have this list of document available directly on the main form and not have to navigate to another page. Here is one way to do it, applicable for the “old fashion” SharePoint integration using the SharePoint List Component for CRM. It does not apply to server-based SharePoint integration with CRM. This is an unsupported customization, use at your own risk. 

What you need

  • SharePoint integration enabled and configured for the target entity (i.e. list component installed, existing SharePoint Site & folder)
  • an IFrame on the form
  • a way to get the full URL of SharePoint folder associated to your record (could be a field that you automatically populate on the entity with a plugin, could be retrieving the SharePoint Document Location records using JavaScript when for form loads, etc.)

How it works

When the document view is loaded, there is a URL pattern used by the system to display the list component with the documents:

http://sharepointdev/crm/crmgrid/crmgridpage.aspx?langId=en-US&locationUrl={document location url}&pageSize=250

What you can deduct from the URL above:

{SharePoint Root Site}/crmgrid/crmgridpage.aspx?langId={Language}&locationUrl={Document Location Url}&pageSize={Page Size}

Grabbing that Url with the correct parameters and pasting in browser will display the list of document for the target CRM record. In short, all you have to do is display that Url constructed properly inside an iFrame on your CRM form (see illustration below). Please note that this can have a performance impact on how quickly the form loads (this component can take longer to be loaded and displayed.

image

Code snippet

Javascript Method to load the content


var documentSiteUrl = ""; /* Find a way to get this information – can be read from a hidden field on the form. */
var parentSite = ""; /* Find a way to get this information – can be read from a hidden field on the form. */

if (documentSiteUrl == "" || parentSite == "") {
   return;
}

// Build document location URL - Set IFRAME target
var docViewUrl = parentSite;
if (!StrEndsWith(docViewUrl, "/")) {
   docViewUrl = docViewUrl + "/";
}

var userLanguage = "en-US";
if (Xrm.Page.context.getUserLcid() == "1036") {
   userLanguage = "fr-FR"
}

docViewUrl = docViewUrl + "crmgrid/crmgridpage.aspx?langId=" + userLanguage + "&locationUrl=" + documentSiteUrl + "&pageSize=250";

var documentIFrame = Xrm.Page.ui.controls.get("IFRAME_Documents");
if (documentIFrame != null) {
   Xrm.Page.ui.tabs.get("Documents").setVisible(true);
   documentIFrame.setSrc(docViewUrl);
}
else {
   Xrm.Page.ui.tabs.get("Documents").setVisible(false);
}
Advertisements

Customizing your CRM platform the “right way”

Over the course of my consulting experiences, I have learned to work with different platforms and products “the right way.” This means that when you are using a product (for example Microsoft Dynamics CRM), you are agreeing to use the product in the ways specified by the makers of the product. It’s like when you buy a car, there are parts that go with it and if you need to change them, you need to get them from the manufacturer. When you start modifying the car with custom parts, you lose your manufacturer’s warranty. Same thing with a phone, you jailbreak it, you don’t get support anymore. The reason behind that is very simple. When you make changes that are not prescribed by the maker of a product, it’s possible that you altered the way the product works (i.e. you may have broken it or it may break in the future), therefore the manufacturer can no longer support it because it doesn’t know if it still works as designed.

When it comes to software and especially in the case of CRM, it is very important not to break that contract. There are a few things to consider if you do and they are very well documented:

  • Unsupported changes are dangerous by nature, you don’t know what the impact is on things that you are not supposed to have control over
  • They will probably break in the future (after a patch or upgrade)
  • They can bring tons of other issues (performance, testability, bugs…)

If you are buying a product that is integrated with Dynamics CRM (ISV solution), always ask this question to the vendor: “Is you product and/or integration built in a supported way by following all Microsoft customization guidelines and APIs”? See the table of what should be your reaction based on the answer below

Answer My2cents What to do
No That’s just bad. It will either stop working at some point or it will break something. Run away!
I don’t know If the vendor doesn’t know, it means he/she is not really aware of what the impact of unsupported customizations are. That sends a wrong message and represents a serious risk. Run away or hire a technology expert to validate that all is supported.
Yes Perfecto! The vendor knows what it means and understand the importance of supported customizations. It’s a go! To protect yourself, make sure it’s mentioned in your purchase contract.

As consultant and community contributor, I keep seeing a lot of web application and ISV providers that integrate with different CRM or other platforms by simply checking out how to do stuff online and customization the platform in unsupported ways to achieve their goal and sell their product. Keep in mind that working with a platform requires the due diligence of working with experts who know how to customize it. Taking shortcuts can seem like a great idea to quickly go to market but consequences can be bad and the result is often hiring experts to figure out what is wrong when they should have been brought in from the beginning.

It’s OK to use unsupported customization as long as you are aware of the risks and are willing to live with them.

You can read more on unsupported customization for MS Dynamics CRM on the links below.

http://dynamicsuniversity.com/blog/customizing-microsoft-dynamics-crm-2011-supported-or-not-supported
http://gustafwesterlund.blogspot.ca/2012/06/unsupported-customizations.html
http://gonzaloruizcrm.blogspot.ca/2011/08/risks-of-unsupported-customizations-in.html

Cheers

Rule Based Forms Strategies for CRM 2011

CRM 2011 introduces the out of the Role Based UI (RBUI or RBF for Role Based Forms). It is a very nice feature and frankly, it was about time they introduced it. Obviously, it is limited because we can only display a form based on CRM user’s security roles. A very common request is to display a specific form based on field value(s). Example could be showing different opportunity forms based on the stage. Here I am sharing a couple of ways to achieve this.

  • Client Side Solution: The idea is to have a Jscript method that executes when the form is loaded. It reads the ‘decision’ field(s) value(s) and navigates to the appropriate form using the Xrm.Page.ui.formSelector item navigate()
    method. A very clear and simple example of that is available here.
    • Pros
      • It is 100% supported
      • Work on all types of installations (CRM Online, On Premise, ADFS)
    • Cons
      • Introduces a visible “refresh” after the form is loaded when a redirection is required
      • Selecting another form manually is no longer possible (you are always redirected to a specific form)
  • Server Side Solution: This is a little bit more complicated to set up. We did it by using a custom IIS rewrite provider. It means writing some code that
    • Reads the record ID and type name or type code from the URL
    • Loads the record from the CRM DB
    • Reads the “decision” field(s) value(s) and redirects to the appropriate form if required

    These steps sound pretty simple but there are a few things to take into consideration. In order to load the record from the CRM DB, you need to have CRM context information to connect to CRM which you don’t necessarily have from the IIS rewrite custom provider (it is executed from the GAC). In addition to that, you need to make changes to the CRM web.config file to add a rewrite section pointing to your custom rewrite provider. You can find more information on how to set up the custom rewrite provider here. If you want a concrete example, you can comment here or contact me directly (no code sample today!).

    • Pros
      • No visible “refresh”, the redirection is made directly on the server
    • Cons
      • It is complicated to setup and requires an unsupported step (modifying CRM web.config)
      • Only works for On Premise installation
      • Selecting another form manually is no longer possible (you are always redirected to a specific form)

In both cases, remember that you can hard-code the IDs of the forms in your script or C# code because they remain the same as you go from one environment to another (i.e. forms are transported in CRM solutions with their ID) so there is no additional work required for this. Given the choice, I would always go for solution one (client side script) even if it introduces a visible refresh at times. Unfortunately, sometimes that refresh is not acceptable from a client’s perspective so you have to be creative and come up with other approaches like the IIS URL rewrite custom provider.

Cheers!

Passing Query String Parameters to Navigation Link URL

I was recently asked by a client to have a custom .NET page displayed on an entity form. Because of the content of the page (it’s a heavy, long and large!), we were all in agreement that using an IFRAME or a web resource in a Tab or Section on the main form was not going to be pretty. The best user experience is to have the page displayed when users click on a navigation link on the left menu.

Sounds easy, right? Not so fast! In our case, the custom web page displays content that is specific to the record it’s opened from. That means the page needs to know the ID of the record. That sounds easy as well, right? You are thinking simply pass the record ID as parameter in the query string… Yes, it works with an IFRAME and for a Web Resource, you can change the URL programmatically when the form loads or when a field value is changed. For a Navigation Link, not so fast! There is no supported way to change the URL programmatically!

This had me do some research to see what we could do to get around that limitation. Unfortunately, it has to be a non-supported approach.

You could attach to the On Click event of the navigation link or set the URL on load of the form. Regardless, problem is accessing the IFRAME in which your page resides. There are a few ways to do this as you can see here and here. I prefer solution 1 because you use the ID of the navigation URL (it is transported as part of the CRM solution and remains the same in all environments).


Alternatively, you could do it the other way around, meaning accessing the Xrm.Page.data.entity object from the web page in the IFRAME. This is done easily in JavaScript using something like window.parent.Xrm.Page.data.entity.attributes.get(“…”).getValue();. This is also not supported since we have no control over what the parent of the IFRAME window can become.

I want to say I hope Microsoft adds this functionality in a future update but with the new process driven UI forms that are coming in the Orion release, I don’t know if all this will still be relevant in a near future. We’ll see!