Did you know that you can send a hyperlink shortcut to an entity in CRM 4.0 over email? This functionality is especially useful when team members are collaborating on a customer or case together and want an easy way to link to what they’re working on so that the collaborating team member won’t have to search for the record to find it. But what happens if one team member connects to CRM 4.0 over the company intranet, while the other team member connects using IFD (Internet Facing Deployment)? Depending on network infrastructure, chances are that the sent shortcut will not work for both users. This blog entry will describe a workaround for this scenario.

Say you’re on an opportunity and you’d like to email a shortcut to a colleague so that you can collaborate on it. From an open Opportunity window, you can select the Actions menu, and then “Send Shortcut…” which will open up a new email with your default mail client (usually Outlook).

This leaves you with the option to alter the email body and add as many recipients as you see fit.

The downside to this approach is that depending on your network infrastructure and IFD configuration, you may get a different shortcut URL when you do the same operation over IFD:

This could cause a problem if your network infrastructure and IFD deployment settings are such that internal URLs only work internally (intranet) and/or external URLs only work externally (over IFD). Here are two workarounds to this issue:

Workaround 1: Configure your network and IFD settings to support the IFD URLs internally and configure each outlook client to only use the IFD URL. As an example, say that your external IFD URL is https://altriva.altriva.com. If you have the ability to configure your network to also recognize this URL internally, then you have the option to configure CRM for Outlook to only use this URL, instead of one URL when connected to your Intranet and another URL when not connected to your Intranet. This way, the send shortcut functionality will always send the IFD URL and the link will work both internally and externally.

Workaround 2: Create two custom buttons or menu options on each entity you want to support, where one button sends an internal link and the other button send an external link.

To implement this workaround, you will need to modify the XML in the isv.config to include some JavaScript. The following XML from isv.config is an example of one way to accomplish this for the Account entity (see http://msdn.microsoft.com/en-us/library/bb928136.aspx to learn how to modify your isv.config).

        <Entity name="account">
          <MenuBar>
            <CustomMenus>
              <Menu>
                <Titles>
                  <Title LCID="1033" Text="Send Shortcut" />
                </Titles>
                <MenuItem JavaScript="OpenEmailForm('', crmForm.all.name.DataValue, crmForm.all.new_internalshortcut.DataValue);" PassParams="0" WinMode="1">
                  <Titles>
                    <Title LCID="1033" Text="Send Internal Shortcut" />
                  </Titles>
                </MenuItem>
                <MenuItem JavaScript="OpenEmailForm('', crmForm.all.name.DataValue, crmForm.all.new_externalshortcut.DataValue);" PassParams="0" WinMode="1">
                  <Titles>
                    <Title LCID="1033" Text="Send External Shortcut" />
                  </Titles>
                </MenuItem>
              </Menu>
            </CustomMenus>
          </MenuBar>
          <NavBar>
          </NavBar>
        </Entity>

The above code assumes that two fields named new_internalshortcut and new_externalshortcut have already been added to the account form and contain the complete URLs for the internal and external shortcuts respectively. In my solution, I populated these two fields through direct SQL updates for existing data, and then with JavaScript OnSave of the account entity for future data. Note that direct SQL updates are considered to be unsupported customizations, but this direct SQL update is relatively low risk.

The new_internalshortcut and new_externalshortcut fields are not technically required, and in fact could be derived directly in the isv.config JavaScript by appending “<<urlroot>>/sfa/accts/edit.aspx” and the crmForm.ObjectId, but I will leave that as an exercise to the reader. Note also that the below XML calls a mysterious function called “OpenEmailForm(string, string, string)”. This is an internal CRM JavaScript function that creates the appropriate “mailto” statement we need, and is exactly what is called by the existing “Send Shortcut” functionality. Calling internal CRM JavaScript functions are completely unsupported, and there is a good chance that this code will not work after an upgrade. To avoid this, you could replace the OpenEmailForm function with a direct mailto statement, which would keep your CRM system in a supported state.

Always be sure to backup your database before editing the isv.config file. CRM 4.0 does a better job than CRM 3.0 at detecting invalid isv.config files before it imports them, but you still run the risk of hosing your UI. If you find this high level approach to the workarounds a little lacking in detail, you may want to consider bringing in a CRM expert or consultant to help fill in the details to make sure your systems stays up after implementation.

- Phil Edry