RSMUS.comHave you ever created a workflow to send an email with a link to the record? If you’re in the Microsoft Dynamics CRM 2011 world then I bet most of you have. But, have you ever tried clicking on that link from a mobile phone, or maybe your default browser is Chrome. If your default browser is not Internet Explorer, clicking the link in an email client opens Chrome and depending on what rollup you are on, you might get an error message. Let’s take a deeper look into what is happening behind the scenes and how we can fix the mobile user experience.
Deep linking from a workflow is standard functionality in out of the box Dynamics CRM 2011. From the workflow designer add the send email workflow activity and put the dynamic URL field in the body of the email. The link works great from a desktop, but when clicking the link on a mobile phone results in an error.
To fix this, we could write a fancy custom workflow action that allows us to build unique URLs or capture the GUID of the existing record, but that would need to be included in the email as a second link. I like to avoid custom code as much as possible and in this scenario, the alternative to the custom workflow action was very straight forward. The solution described below, referenced in Microsoft’s KB Microsoft Dynamics CRM Compatibility List, solves this issue with one link and no custom workflow actions:
Mobility testing is fairly easy, and does not require a mobile phone. Simply use an “unsupported” browser such as Chrome and by default CRM falls back the experience to the mobile view. The catch here is that the mobile browser check happens on the root CRM URL, not a deep link to a specific entity. For example:
Mobility testing is fairly easy, and does not require a mobile phone. Simply use an “unsupported” browser such as Chrome and by default CRM falls back the experience to the mobile view. The catch here is that the mobile browser check happens on the root CRM URL, not a deep link to a specific entity. For example:
- https://crm.local/OrganizationName/ (will redirect successfully to the mobile view)
- https://crm.local/OrganizationName/edit.aspx?etc=112&id=00000000-0000-0000-0000-000000000000&pagetype=entityrecord (will not redirect to the entity’s mobile form)
For an on-premises deployment there are some very nice options to assist in getting the mobile forms to load. Let’s take a look at how to get a mobile form to load.
Enter the Microsoft URL Rewrite Module for IIS (MURM). Yes, I just created that acronym. You should already be somewhat familiar with it because it is a prerequisite for Microsoft Dynamics CRM Server 2011 upgrade preparations, but if you need a refresher take a look at this introduction to Using the URL Rewrite Module.
Not too dive to deep into how MURM works but it inserts itself in the HTTP Pipeline before Dynamics CRM gets its hands on the request for processing. That makes it easy to identify a mobile or unsupported client and redirect the request to the appropriate mobile friendly URL.
To start, launch IIS in your DEVELOPMENT environment and bring up your Dynamics CRM site. You should see the (MURM) icon in the IIS section of the Features View.
Double-clicking the URL Rewrite icon will bring up the existing inbound and outbound rules for this site. Surprise, there are three default rules which come with Dynamics CRM out of the box. We want to create a new rule so select the Add Rule(s)… link in the upper right corner.
The Add Rule(s) wizard dialog should appear. It might look different depending on what version of MURM you have installed but select the Blank rule icon under the Inbound rules section and click OK.
The URL we want to intercept came from our workflow generated email and looked something like this: http://[CRM URL]/[OrgName]/userdefined/edit.aspx?etc=112&id=00000000-0000-0000-0000-000000000000 where [CRM URL] is your CRM URL and [OrgName] is the working Organization name.
We want to intercept requests when the first part of the URL contains edit.aspx. To do this we can use a regular expression. Configure your rule like the following screenshot.
Here is what the regular expression rule is doing. First, it will grab any existing request when the URL has zero or more of any character (.*) before the specific text “edit.aspx”.
Tip: Take advantage of the Test pattern… button and paste in your target URL example to see if your pattern will match. Always try a few other URLs which should not be a part of your redirect rule and test, test, test.
For the next part of the rule’s configuration we need to introduce two new conditions:
- Only target mobile browsers
- The Entity Type Code/Object Type Code (?etc=) portion of the URL should equal 112 (Case entity)
Locate the Conditions section of the Rule and verify the Logical group dropdown value is Match All.
Next, click the Add.button in the conditions section to add condition 1.
In the Condition input field type: {HTTP_USER_AGENT}. This is a part of the HTTP Request header which every browser sends along with a request for a web page.
In the Check if input string drop down choose: Matches the Pattern
In the Pattern text box type: mobile|phone|chrome. The chrome value is optional but I wanted testing to be easy so I included it initially.
Leave the Ignore case checkbox checked.
Click the Add.. button again in the conditions section to add condition 2.
In the Condition input field type: {QUERY_STRING}. This is a part of the URL which includes the ? and everything to the right.
In the Check if input string drop down choose: Matches the Pattern
In the Pattern text box type: (?=.*etc=112.*)(?=.*id=(.{0,36}).*)
Leave the Ignore case checkbox checked.
There’s a lot going on in this regular expression so I’m only going to cover the important parts. The Pattern field filters out all forms except when the query string contains the text “etc=112” and “id=(some value 0 to 36 characters long)”. This particular type of regular expression tests for the values in no particular order to protect the match from changes made by Microsoft in future service packs. Normally a regular expression will parse text left to right but in our scenario there is no guarantee the order of the query string parameters. The query string parameter “etc” stands for entity type code and 112 is the type code for the Case entity. See this post for the full listing of entity type codes . The parenthesis after the text “id=” is known as a backreference. A backreference captures the text matched by the expression inside of the parenthesis. The value of a backreference is we can use it later on in our rule’s configuration to pull out the ID of the Case entity.
The last part of our rewrite rule is to perform some sort of action when all of our conditions are met. In this scenario the request should be redirected to the mobile form. To get the mobile form URL, I opened up CRM in Chrome and navigated to a specific Case from the home page. The mobile URL format is quite different from the non-mobile URL. Instead of entity type codes in the URL, CRM uses the entity name. Here’s an example I pulled from a test environment:
http://crm/TestOrg/m/ef.aspx?etn=incident&id=00000000-0000-0000-0000-000000000000.
In the Action section of the form, change the Action type drop down list to: Redirect.
In the Action Properties grouping, type into the Redirect URL textbox: http://[crm]/[testorg]/m/ef.aspx?etn=incident&id={C:1}
Then replace [crm] and [testorg] with your organization’s specific values. In the Redirect type drop down choose See Other (303).
If you are looking to configure deep linking in your Dynamics CRM system, the professional at RSM are certified with the Gold Customer Relationship Management competency in the Microsoft Partner network. We offer services from basic out of the box to complex customization. Contact our professionals at crm@mcgladrey.com or 855.437.7202.
By: Luke Grindahl – Minnesota Microsoft Dynamics CRM partner
