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

Using Full-Text Search to improve Dynamics CRM search experience

Consider the following scenario: You need to perform email searches in your CRM and your search needs to look at the content (body) of your email messages. When you start having a lot of emails in your CRM (500k+ in my case), searches become extremely slow and you need to start to look at indexes or other solutions to make the search faster and keep your users happy. This post describes a solution that leverage a new CRM feature in CRM 2015 Update 0.1 (On Premise) : Full-text search.

Enabling Search on email body

This is the easy part. If you are having this issue, you have probably done this already. To enable the ability to search on the email body, you need to add the “Description” field as a “Find Column” in the Quick Find view of the Email entity, as shown in the screenshot below. After completing that step, save the view and publish the entity to make the change available in the system.

image

Searching through emails

Now that we’ve configured the search column, we can do a quick search to get our emails by using the search box on the activity list view view or by using the “Global Search” on the top right of the top navigation bar, next to the “Quick Create” button. Note that emails are not enabled in the “Global Search” by default so you’d have to add them (not required).

If you have a few emails in your system, results are going to come back quickly. In the system that I tested against, I had about 700.000 emails in CRM so the search result took on average just over 30 seconds to return results (and I consider this good, because I’m running on SSD drives). That being said, in real life, 30 seconds or more of waiting time is enough to make users think that the system is frozen, or to just stop trusting in the application, especially if they rely heavily on this type of search.

Making search return results faster

If you are using CRM 2015 On Premise, you are in luck. In CRM 2015 Update 0.1, the product team introduced the ability to enable full-text search for Quick Finds queries. To enable it, go do Settings –> General –> Set up Quick Find. There you’ll see the option to “Enable full-text search for Quick Find.

image

Greater details about the feature can be found here and you can also take a look at this video on the Microsoft Dynamics YouTube Channel.

Important points to keep into consideration before enabling full-text search:

  • Full-text indexing for Quick Find uses SQL Server full-text indexing
  • It can take up to 24 hours for the system to enable or disable full-text search, or add and remove find columns (maintenance job has to run on the server and make the adjustments specified in the CRM configuration)
  • As a bonus, you should also activate the Org Settings “EnableQuickFindOptimization” and “EnableRetrieveMultipleOptimization” in order to get the best results. Thanks to Jean-François Cantin for that indication. If you don’t know how to update the Org Settings, here is a reference.

After waiting long enough time for the emails to be indexed, the email searches started to return results within 5 seconds. Drastic improvement. The same solution was implemented into the client’s database and it seems to have made a huge improvement. 

Have fun.

Dealing with record level access restriction with Dynamics CRM

CRM works extremely well with giving users access to records based on a different set of security configuration tools : cumulative security roles with a “most permissive win” mechanism, business units, team memberships, access teams, hierarchy and so on. One thing it does not do well is restricting access to specific record. Imagine the following scenario:

  • Company ABC uses Microsoft Dynamics CRM to manage its cases
  • An employee leaves company XYZ to join ABC
  • After joining ABC, the new employee is given access to Dynamics CRM and has access to ongoing and past cases, say in his/her region
  • Company ABC has open cases against firm XYZ. The employee should not be able to see those cases because it represents a conflict of interest (e.g. he/she might give insights to his/her old friends at XYZ)

The following image provides an illustration of what we are trying to accomplish.

image

If you have worked with Dynamics CRM and know its security model, you can already read between the lines here. There are no easy ways to make this happen. This article provides a possible solution for this requirement based on a recent experience on a large CRM implementation.

Ruling out Team Membership & Ownership

In our scenario, members of a team or a business unit get access to all records  owned by their team or business unit. If we follow basic team/BU record ownership, the problem in this case is that once a record needs to be isolated from one individual member of the team, one of two things needs to happen:

  1. The record owner has to be changed (it can no longer be the team everyone is a member of) and the record needs to be shared with users who can still see it, but not with the individual that is getting the restriction applied OR
  2. The individual who is getting a restriction applied has to be removed from the team and all the records owned by his/her team need to be shared with him/her except the one he/she is restricted to see.  This technique implies heavy maintenance since the user will need to access new cases created for the team he/she used to be a member of.

Sharing in both cases can be done via the record share functionality, access team or any other mechanism that suits the business need. It should also be automated if there is a large number of records to share. You also need to save the information about the user and its restriction on a separate entity to be able to backtrack and understand why the records/ownership and so on have been modified.

Why we didn’t like the “Sharing” functionality

Using the out of the box sharing of record can cause problems in the long run. The PrincipalObjectAccess (POA) table gets bigger and bigger, causes performance issues and has to be cleaned up on a regular basis. In addition to that, the more access is controlled by sharing, the more you run the risk of having performance issues because of the complexity overhead in system lookups when it needs to display a record or list of records to users.

A solution using “Access Teams”

We decided to go with a design centered around Access Teams. The “Case” entity gets an “Access Team Template.” When a user is created and added to his/her group (team or business unit), we start a process to insert the user in the Access Team of each case related to his/her business unit. In order to restrict access to a specific case for a user, we can simply remove the user from the case’s Access Team.  For tracking purposes, we created a “Security Exception” entity that is created and has a relationship with a case and a user and an additional attribute that indicate the type and reason for the “Restriction”. To apply the access restriction on a case for a user (i.e. remove user from access team), we create a Security Exception record. We link the target case and user, and specify the restriction type. After the Security Exception record is created, a plugin is fired to perform validation and to remove the user from the case’s access team.

One of the reasons with went with that model was that we didn’t want to have a base security model that gets “broken” every time there a single person with restricted access, by changing record ownership or removing user from the team he/she is supposed to be a member of. With access teams, the record ownership remains the same, and users also remain on their team at all times which makes everybody happy and maintenance easier. The downside is that when a user is created, we have to look for all the cases in his/her business unit and manually (with code) add the user to each access team. Same when a case is created, users member of the case’s business unit have to be added to the case’s access team manually (also with code). That is the comprise we had to make.

As far as performance goes, the end results remain to be seen in the long run. Our system will have between 2000 and 3000 users when we complete our rollout. It will deal with over 1 million cases across multiple teams. Preliminary performance tests results look promising. I will repost if we get into any issue as it relates to performance.

It’s been a while! This feels great Smile  – Happy CRM’ing !

CRM Online 2015 Update 1 – Alternate Keys

Very often in CRM implementations, we find ourselves writing plugins to validate the unicity of records and prevent the creation of duplicates. One example is having contacts uniquely identified by an email address. That can be useful for user login from portals (unique emails in CRM), or when integrated systems need to connect to CRM and perform operations on existing records (no need to synchronize the CRM ID, use an existing alternate identifier to access your data).

The Dynamics CRM Online 2015 Update 1 brings a new and exciting functionality to handle this type of scenario very easily: Alternate Keys.

Alternate keys enable data integration in an efficient manner. Users can now define an attribute in a Microsoft Dynamics CRM entity to correspond to a unique identifier (or combination of columns) used by an external data store. Use this alternate key to uniquely identify a record in CRM in place of the primary key. This feature enhances the developer and customer experience by:

  • Reducing roundtrips to look up record IDs from other unique columns.
  • Increasing overall throughput of bulk data processes, especially with CRM Online.
  • Simplifying programming from external systems without CRM record IDs.

How to Define an Alternate key?

  1. Navigate to the Customization area and expand the target entity
  2. Select “Keys”
  3. Click New to define a new key

  1. Define a name for your key
  2. Select the attribute(s) that define your key from the “Available Attributes” and add them to the “Selected Attributes” columns
  3. Click OK

Once this is completed, CRM will create an asynchronous system job that will create the database index to enforce uniqueness and optimize lookup performance. The process can be lengthy if there are lots of existing records in the table for which the new key is created. The possible statuses the after creating an alternate key are the following:

  • Pending (waiting for the asynchronous job to start)
  • In Progress (system job – and SQL job – running)
  • Active
  • Failed

It’s worth noting that if there is existing data that violates the uniqueness defined by the new key, the job will fail and the key will not be activated. Looking at the asynchronous job will give you details of the failure as shown in the screenshot below.

This is great because it forces an initial cleanup of your system data before you can use existing fields as alternate keys.

Now that you’ve created an alternate key, you can run a quick test to validate that the new unique key is being enforced by the system. To that, simply create two records with the same key (in my case, 2 contacts with the same email address). You will get “Duplicate Record” error message as shown below.

So how about code? What can I do from a coding perspective?

The process of creating, retrieving and deleting Alternate Keys can be done using the API. Read more about the new SDK requests that allow to manage the alternate keys on MSDN.

It only makes sense that we can now create instances of Entities and EntityReference classes using alternate keys. You can read more on this on MSDN. Here are the new constructors for the Entity and EntityReference tables:

public Entity (string logicalName, Guid id) {…}
public Entity (string logicalName, string keyName, object keyValue) {…}
public Entity (string logicalName, KeyAttributeCollection keyAttributes) {…}
public EntityReference(string logicalName, Guid id) {…}
public EntityReference(string logicalName, string keyName, object keyValue) {…}
public EntityReference(string logicalName, KeyAttributeCollection keyAttributeCollection) {…}

This is a very exciting feature. Hopefully, it will soon make it to the On-Premise version of Dynamics CRM so we can all benefit from it!

Cheers

CRM 2015 is out!

For those who have been waiting, Microsoft Dynamics CRM 2015 is now available!

You can download the installation package here. Also, if you create a new instance of Dynamics CRM Online, you’ll notice that it has been upgraded. For the existing CRM Online customers, the process will be similar to the previous major update: they will have the option to schedule a date for their upgrade.

A few links that points to the nice features of CRM 2015 below.

Happy CRM’ing!