UPDATE: Developer documentation can be found here: http://offers.crmchoice.com/CRM2011Beta-Developer-Videos/#content780

Prior to implementing EDI, the manufacturer would receive orders from an ASP.NET-based web site into their Dynamics CRM Online instance. A workflow in CRM would then create a packing list and send the information as an e-mail message to the shipping company.

As you might expect, the shipping company had to open the e-mail and manually re-type the order details into their system so that the warehouse could pick the items from the shelves and ship them out.  This led to high costs for the manufacturer, the possibility of mistyped information, and order fulfillment delays.

In addition to the high costs incurred by the manufacturer and the other problems with manual intervention of the ordering process, the company is experiencing rapid growth in sales. Although this is great news, especially in the current economic climate, their rapid growth also meant that the order fulfillment process had even more risk of breaking down.

Like a lot of companies in the manufacturing and shipping industries, beginning in the mid-1960s, the shipping company used by our client (the product manufacturer) supports EDI for receiving shipment requests and sending back shipment details.  With the rapid growth of our client, it made perfect sense to move to an EDI-based solution.

The diagrams to follow show the ordering and fulfillment process before and after Altriva helped our client improve the process.

Altriva and our client had many reasons to choose Windows Azure for the platform to host the EDI-processing application. First, as I mentioned previously, our client’s sales are growing at such a rate that we needed a platform that can scale-up quickly. Azure provides fast and easy scalability. Next, the application needs to run reliably 24x7x365 and Azure has proven to provide excellent reliability. Finally, since our client already subscribes to Microsoft Dynamics CRM Online and other Microsoft services, they receive a single billing statement for their use of Windows Azure as well.

On the surface, combining “EDI” and “Windows Azure” in the same sentence seems preposterous, but in practice the two can work together quite well. Maybe next I’ll get to work on a project that combines EBCDIC and Microsoft LightSwitch!  Or maybe not.
 

This confusing message only appears if you include the ORGNAME as part of your CRM server URL. To resolve this issue, simply delete the ORGNAME from you URL (http://servername:port/). Don’t worry if your user has access to more than one CRM Organization – the configuration wizard will prompt you to choose an Organization after you click next.

- Phil Edry
 

1. When a user creates a new entity, a plug-in registered on pre-create or post-create of that entity fires.
2. The plug-in confirms that the correct entity fired the plug-in.
3. The plug-in then calls a stored procedure to insert a row into a table with an auto-incrementing identity column. If the plug-in was registered on post-create of the entity, the GUID of the entity can be inserted into the table for future reference.
4. The stored procedure then selects the generated identity for that row and returns it to the plug-in.
5. The plug-in then sets an attribute on the entity to the identity and returns.

A separate plug-in must be created and registered for each entity that uses auto-numbering. However, it is up to the implementer whether to use one table to generate all auto-numbering or to create separate tables and stored procedures for each entity. Using one table would mean all entities would share the same sequence of numbers, while using multiple tables would allow each entity to start at “1” and have its own sequence.

I suggest creating the table and stored procedure in the MSCRM database with unique names. While creating database objects in the MSCRM database is unsupported, it allows for much simpler system backups and deployment maintenance when working with multiple environments. Care should be taken in naming tables and stored procedures to avoid naming the objects something that Microsoft might use in future versions of CRM.

Below is the plug-in and stored procedure code for an implementation of auto-numbering for the opportunity entity. The plug-in is registered on pre-create due to a client’s requirement that the displayed opportunity name “new_name” be updated and displayed on save with the auto-number appended. The plug-in stores the auto-number in the “name” attribute. Note that the connection string is hardcoded in this sample code, so changing database servers would require a recompilation of the plug-in. Be sure to modify the connection string as appropriate.

Table Creation and Stored Procedure Code:

Phil Edry

• Requirement to update to rollup 7 prior to installation
• Updates for the 40 supported language packs are contained in the update

The knowledge base article regarding the details of Rollup 8 can be found by following this link to the Microsoft Support site. The update can be downloaded by clicking on this link to the Microsoft Download Center.

Let’s jump straight into implementing this solution. When we’re done, we’ll have a new tab that has an IFrame reference to Google Finance search on the company’s ticker symbol, or if that isn’t provided, then the company’s name.

 Step 1: Add a new tab to the account entity.

In the CRM web client, navigate to Customize Entities >> Account >> Forms and Views >> Form and click Add a Tab. Name the tab as you see fit – we’ll call it “Finance”.

Step 2: Add a Section to the new tab with the default options and then add an IFrame with the following pictured settings entered.

Step 3: Add JavaScript

While still on the form, navigate to Form Properties >> OnLoad. Merge the following code into any existing code in the OnLoad event. Be sure to check the “Event is Enabled” check box if it is not already checked.

 
It is a good idea to check for crmForm.FormType to ensure the code only fires when you expect it to, but this is optional. Another optional step would be to add this code to the OnChange event for the Ticker Symbol and Name fields. Also, you could hide the Finance tab whenever the Ticker Symbol field is empty, but note that hiding tabs is technically unsupported in CRM 4.0.
 

Step 4: Publish
 

Save and close the form and then click publish.

Conclusion

That’s it! Now users can get a quick view of the financials for a given company just by switching to the Financials tab. This piece of functionality demoed above is just a taste of what can be done with IFrames. In fact, this functionality is pretty redundant, since users can simple double click the Ticker Symbol on a form and get similar data from MSN Money. The only thing this piece of functionality that this specific customization provides is the ability to search on a company that doesn’t have the Ticker Symbol field filled out, since it uses the name instead. A couple of quick JavaScript changes, and you could easily modify this example to display driving directions from your main office to an account’s primary address using Bing or Google Maps. It is small improvements like these that can give an added boost your customer adoption campaign.
 

In the following example, our fictitious client “Amgeen Brake Products” asked us to drop by each of their retail locations in Michigan for a safety inspection. Before getting in her car, our safety inspector opened Dynamics CRM, loaded the Facilities view for the customer, selected the Michigan locations, and clicked the custom Map button to get a print-out of the locations.

Clicking the Map button invokes a custom ASP.NET application. The application queries CRM for the location (longitude/latitude) of each facility and constructs Jscript code that controls Bing Maps. The resulting map is shown below.

It looks like our safety inspector has a full day of driving ahead!

Now, let’s jump into technical details for creating the ASP.NET application I mentioned above.

Application Overview

The Visual Studio .NET 2005 application structure is shown below. The application is deployed as a typical CRM ISV application, which means that it is deployed into a subfolder under the CRM website ISV folder.  (Note: The solution uses the Web Deployment Projects add-in from Microsoft to produce a fixed .NET assembly name.)

The file that is called from CRM (by way of a custom ISV.Config button) is “MapSelectedFacilities.aspx”. The custom button is added to the Facility grid’s menubar with the following ISV.Config entry:

<Grid>
<MenuBar>
  <Buttons>   
    <Button Icon="/_imgs/ico_18_debug.gif" Url="/isv/altriva/BingMaps/MapSelectedFacilities.aspx" WinMode="2">     
    <Titles>       
    <Title LCID="1033" Text="Map" />     
    </Titles>     
    <ToolTips>        
      <ToolTip LCID="1033" Text="Map the selected Facility records" />      
    </ToolTips>    
    </Button> 
  </Buttons>
  </MenuBar>
</Grid>

Determining Selected Rows in a CRM Grid

In order to map only the selected facilities, it’s necessary to get the ID of each of the selected facilities in the CRM grid and pass the collection to the ASP.NET application. The function “listselecteditems” in the ASPX page (see below) provides this functionality.  (Thanks to David Fronk at Dynamic Methods for posting the hidden field technique that I ended up using in this application.)

The HTML for MapSelectedFacilities.aspx and the code-behind C# class is provided below.

MapSelectedFacilities.aspx

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="MapSelectedFacilities.aspx.cs" Inherits="MapSelectedFacilities" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Bing Map</title>

    <script type="text/javascript">
    function listselecteditems()
    {
        var hiddenfield = document.getElementById("HiddenField_SelectedGUIDs");
        var sGUIDValues = "";
        var selectedValues;
        if (window.dialogArguments)
        {
            selectedValues = new Array(window.dialogArguments.length - 1);
        }
        else
        {
            return;
        }

        selectedValues = window.dialogArguments;
      
        if (selectedValues != null)
        {
            for (i = 0; i < selectedValues.length; i++)
            {
                sGUIDValues += selectedValues[i] + "\n";
            }
            var hidden = sGUIDValues;
            form1.HiddenField_SelectedGUIDs.value = hidden;
            form1.submit();
        }
        else
        {           
            alert("Please select one or more facility records to map.");       
        }    
    }   
    </script>
</head>
<body onload="listselecteditems()">    
    <form id="form1" runat="server">     
        <input id="HiddenField_SelectedGUIDs" type="hidden" runat="server" />   
    </form>
</body>
</html>

When CRM invokes MapSelectedFacilities.aspx, it provides the selected facility IDs in the dialogArguments window property. Those values are stored in the hidden HTML object “HiddenField_SelectedGUIDs”.

MapSelectedFacilities.aspx.cs

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.Sdk.Query;
using Microsoft.Crm.SdkTypeProxy;

public partial class MapSelectedFacilities : System.Web.UI.Page
{
    AccountFacilities _accountFacilities;
    protected void Page_Load(object sender, EventArgs e)
    {
        if (this.IsPostBack)
        {
            string crmOrgName = "Altriva";

            if (HiddenField_SelectedGUIDs.Value != string.Empty)
            {
                // Get the list of selected Facility records in the CRM grid view
                string rawFacilityGuidList = HiddenField_SelectedGUIDs.Value.ToString();
                rawFacilityGuidList = rawFacilityGuidList.TrimEnd();
                rawFacilityGuidList = rawFacilityGuidList.Replace("{", "").Replace("}", "");
                string[] arrFacilityGuidsStr = rawFacilityGuidList.Split(new char[] { '\n' });

                using (new CrmImpersonator())
                {
                    CrmDataRetriever crmDataRetriever = new CrmDataRetriever(crmOrgName);
                    _accountFacilities = crmDataRetriever.GetFacilityLocationDetails(arrFacilityGuidsStr);
                }

                Server.Transfer("~/MapSelectedFacilitiesPost.aspx", true);
            }
        }
    }
    public AccountFacilities FacilityDetails
    {
        get
        {
            return this._accountFacilities;
        }
    }
}

When the code-behind is executed, it reads the list of GUIDs, parses them into an array, and then queries CRM for the longitude and latitude for each of the facilities. The custom method GetFacilityLocationDetails is in a class that is responsible for querying CRM for facility details. Since there are several examples of querying CRM data in the CRM SDK I am not providing the source code for the CrmDataRetriever class – it is simply a class that’s responsible for retrieving and storing (as class properties) facility details.

For purposes of “separation of responsibility” in the application design, I chose to divide the work of collecting facility details and rendering the Bing Map into two ASPX pages. That explains the use of Server.Transfer in the code-behind provided above.

Rendering the Bing Map

As mentioned above, the code-behind for MapSelectedFacilities.aspx passes control to MapSelectedFacilitiesPost.aspx. This second page generates the Jscript code to render the Bing Map.

The HTML for MapSelectedFacilitiesPost.aspx and the code-behind is provided below.

MapSelectedFacilitiesPost.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="MapSelectedFacilitiesPost.aspx.cs" Inherits="MapSelectedFacilitiesPost" %>
<%@ PreviousPageType VirtualPath="~/MapSelectedFacilities.aspx" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">   
  <title>Facilities</title>   
  <script type="text/javascript" src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2">
  </script>
</head>
<body onload="LoadMap()" onunload="UnloadMap()">   
  <form id="form1" runat="server">       
  <div id='mapDiv' style="position:relative; width:800px; height:600px;" runat="server">
  </div>   
  </form>
</body>
</html>

You’ll see that the onload event of the HTML body calls a function named “LoadMap”. That function, along with UnloadMap, is generated in the page’s code-behind.

MapSelectedFacilitiesPost.aspx.cs

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

public partial class MapSelectedFacilitiesPost : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        GenerateClientSideMapCode(PreviousPage.FacilityDetails);
    }
    private void GenerateClientSideMapCode(AccountFacilities accountFacilities)
    {
        ClientScriptManager csm = Page.ClientScript;

string code = @"
<script type='text/javascript'>
 var myMap = null;
 function LoadMap()
 {
    myMap = new VEMap('mapDiv');
    myMap.LoadMap();
    AddPushpinShapes();
 }

 function UnloadMap()
 {
    if (myMap != null) {
       myMap.Dispose();
    }
 }
";
        // Render the JavaScript code that adds pushpins to the map.
        int mapShapeCounter = 0;
        string pushpinCode = "\n\nfunction AddPushpinShapes()\n{";
        pushpinCode += "\n" + "var pushpinCounter = 0;" + "\n";
        foreach (AccountFacilities.AccountFacilitiesRow dr in accountFacilities._AccountFacilities)
        {
            if (!dr.IsFacilityLatitudeNull() && !dr.IsFacilityLongitudeNull() && dr.FacilityLatitude != "0" && dr.FacilityLongitude != "0")
            {
                mapShapeCounter++;
                pushpinCode += "\n" + "var veLatLong" + mapShapeCounter + " = new VELatLong(" + dr.FacilityLatitude + "," + dr.FacilityLongitude + ");";
                pushpinCode += "\n" + "var veShape" + mapShapeCounter + " = new VEShape(VEShapeType.Pushpin, veLatLong" + mapShapeCounter + ");";
                pushpinCode += "\n" + "myMap.AddShape(veShape" + mapShapeCounter + ");";
                pushpinCode += "\n" + "pushpinCounter++;" + "\n";
            }
        }
        pushpinCode += "\n" + "if (pushpinCounter > 0) { myMap.SetCenterAndZoom(veLatLong1, 7); }\n}";
        code += pushpinCode;
        code += "\n\n</script>";

        csm.RegisterClientScriptBlock(this.GetType(), "map", code);
    }
}

The code-behind generates the Jscript code that creates the Bing Map instance (see “new VEMap”), plots the pushpins, and then registered the Jscript code with the page so that it will execute once the page loads. The mapping process begins with the call to the LoadMap function.

A Second Example

The screen shown below demonstrates another way of integrating Bing Maps into Dynamics CRM. In this example, the Bing Maps screen appears in an IFRAME within the CRM UI. The code needed to implement this functionality is essentially the same as provided in this article. The difference is that, for this implementation, all facilities for the account are mapped rather than only the selected facilities.

Summary

With a small amount of ASP.NET and Jscript code, it’s possible to add significant new capabilities to Dynamics CRM. This blog post demonstrated how using Bing Maps with CRM data can help service personnel plan for road travel. Bing Maps have hundreds of other uses as well. Some of the more popular applications include geography-based sales analysis, GPS-based tracking of personnel and vehicles, and for strategic planning of business opportunities.

Bing Maps Licensing

Please visit the Licensing Bing Maps for Enterprise page for details regarding the commercial use of Bing Maps.

• It does not force users to always bring down all contacts that they own in CRM.
• It allows multiple users to easily synchronize the same contact record to their Outlook contacts.
• It allows users to easily select the subset of contacts they want to sync to Outlook by providing a quick way for marking or unmarking a contact to be synchronized.
• It allows other users in the organization the option to view who else is synchronizing a contact into Outlook (optional).
• It allows an administrative assistant to set up which contacts sync to their boss’ Outlook contacts, which makes it so the higher level users just have the data they need when they need it (optional).

Another great benefit from this solution is that it requires absolutely no custom coding. The solution completely relies on the functionality of Microsoft Dynamics CRM by creating the custom entities, local data filters, relationships, automatic workflows, manual workflows and new views to manage what contacts users want in their Outlook contacts.

1. Create a user-owned custom entity called “Sync User” with an N-1 relationship to contacts,
2. Create a workflow that will run against contacts and create a Sync User instance relating the current user to the contact,
3. Modify the Local Data Groups for each CRM for Outlook client to sync contacts where the related user equals the current user,
4. Train users on how to run On Demand workflows to sync contacts.

1. Building automatic workflows to automatically set users up to synchronize contacts,
2. Configuring a Sync User view to easily review and remove contacts from being synchronized,
3. The ability to sync all contacts at a company, including contacts added in the future,
4. System views to allow users to see which contacts are being synchronized,
5. Security role setup.

This blog post provides examples of how various industries can utilize a custom calendar and provides technical details for how a custom calendar can be implemented.

One example of the potential use of a custom calendar is in the real estate industry. If the major milestones of a real estate transaction (appraisal, inspection, closing, possession, etc.) are stored as dates on the Opportunity record, then those dates can be shown on a calendar along with the client’s name and milestone description. This can help keep office team members, clients, and third-parties informed of major milestones for a real estate office’s transactions.

Another industry or team that can benefit from a custom calendar within Dynamics CRM is one that manages deadlines for tradeshow participation. Having been involved with several tradeshows in my own career I know that it takes a tremendous amount of coordination effort to make sure everything comes together.

Demonstration

In the following example, I created a custom entity named “Tradeshow” to track the various shows that a company could participate in and the related deadlines.

• Event Calendar  (The Code Project)
• DayPilot (SourceForge)

• DayPilot (Full version)
• Dundas Calendar
• ScriptCalendar
• Infragistics WebSchedule
• Quickwebsoft EventCalendar

• Google Calendar  
• Windows Live Calendar (Note: At the time of this blog post, Microsoft had not yet released an API/SDK for this calendar. However, the word is that it will be programmable soon.)
• 30Boxes Calendar

• Project managers
• Information technology firms
• Sales teams
• Legal firms
• General contractors
• Recruitment firms
• Financial advisors

Depending on the functionality you are looking to support, assigning multiple owners to a record can be accomplished many different ways in CRM.  The question to start with is what functionality your business needs to support with multiple “owners” of something within in CRM.  Are you trying to designate multiple individuals who are responsible for a record or task for reporting purposes?  Are you trying to allow users to sync sets of data offline or contacts to Outlook without creating a separate local data filter for each account, opportunity or contact they want offline?  Are you trying to restrict and grant access for people to be able to see and update records?  Are you trying to provide users with an easy way to view the records for which they are a partial “owner”?

Today we will be looking into one of these scenarios: the need to restrict access to records based on the multiple owners of the record.

For this example, let’s assume we have a very restrictive access within our CRM system which requires only the owners of an Opportunity the ability to edit it.  This would work easily if the opportunity only had one owner but in this case each opportunity is handled by three people.  These three people are the field salesperson, the field salesperson inside sales counterpart and an assigned technical support staff who is assigned per opportunity.

Now that we have defined what functionality we want we can begin designing how to accomplish it within CRM.  To do this we first need to understand how a few things work in CRM by default and then begin to build on top of that based on the functionality we are looking for.

Microsoft CRM Security Structure

How does Security work within Microsoft CRM? How does owning a record in CRM relate to security?

Microsoft CRM by default has records in CRM that are either owned at the Organization, Business Unit or the User level.  You can only create new entities that are either Organization or User owned.  The ownership of records within Microsoft CRM is directly linked to security and granting or denying access to records. 

We cannot change the default ownership structure within Microsoft CRM.  All records in Microsoft CRM will either be owned by the Organization or a Business Unit or a single User.  That is not a customizable option for entities in the system or new entities we create.  This means that we will have to build a new “ownership” structure that will facilitate our requested functionality.  

Basically, record access can be granted at 4 levels:

• Organization (You can perform the action no matter where you or the record exists)
• Deep or Parent/Child Business Unit (You can Perform the action as long as the record is in your business unit or a business unit underneath your business unit in the hierarchy)
• Business Unit (You can perform the action as long as the record is in your business unit)
• User Owned (You can only perform the action as long as you are the owner of the record)

Microsoft CRM also provides the ability for users to grant access to a record they own to other users. This is called sharing.  Users can either share records to specific users or create a team within CRM that contains multiple users and share to the team thereby giving everyone in the team the access that they just granted to the team.

Design Options

Now that we have an understanding of how Microsoft CRM uses record ownership and we have our functionality requirements we can begin to design a system that could accomplish the functionality we are looking for. 

Manual Process using Sharing

The first option is to use the built-in security capability, along with a manual process, to provide this functionality to users. 

To do this, you would simply create a security role that only allows users to see and edit opportunities for which they are the owner.

Then, after a user creates an opportunity where they need help from someone else on they can share that opportunity to the other user and grant them access to see and update the opportunity.

PROS

No custom coding
Uses the standard built-in functionality

CONS

Requires users to manually add each person to each opportunity they create or need access to. 
Not a simple way to see those who have access to the record.
If a user forgets others who should be able to see it cannot see the opportunity.

Auto Sharing

The second option is to use the built-in security options along with an automatic process to automatically share the opportunity to their counterpart. 

The solution is to create a security role that only allows users to see and edit opportunities for which they are the owner.  Then, when a user creates an opportunity a custom Plug-in would automatically share out the record to their counterpart based on the owner of the opportunity.  The user would still have to manually share out for the Technical Support because they are assigned on an opportunity by opportunity basis.

PROS

Reduces the user’s manual work to share out records in the system.
Uses the standard built-in functionality with minimal coding.

CONS

Requires users to manually add each technical support person to each opportunity.
Not a simple way to see those who have access to the record.
If a user forgets others who should be able to see it cannot see the opportunity.
If a field reps counterpart changes could require a code change for the sharing or at least a configuration change.

Auto Sharing using Custom Relationships

In this option, we accommodate up to three people who will have access to the opportunity, as stated in our functionality requirements.  We use the built-in security options to lock down the data within CRM.  We then change the label on the Opportunity Form for the standard owner to now say “Field Rep”. We then create two new N:1 relationships from Opportunities to Users.  The first one is called “Inside Rep” and the second one called “Technical Rep”.  We then put the two new fields on the Opportunity Form. We then create a Plug-in on the opportunity that automatically shares the Opportunity to the user that is selected in the Inside Sales or Field Rep relationship.

PROS

Shows on the Opportunity form who is working on the opportunity.
Uses the standard built-in functionality with minimal custom code.

CONS

Limits the solution to only three “owners” for each opportunity.

Conclusion

There are many different ways this version of “multiple owners” can be accomplished within Microsoft CRM.  We covered three simple routes but there are many other ways to accomplish similar functionality.  Your businesses specific requirements along with user training/abilities and volume of data can determine which approach will work best for your business.

- Hoss Hostetler

Say for example that you have laid out the following fields on a custom entity named Property.

If you add all of the fields to a single section, the tab order will go top to bottom on the first column before starting on the second column. So starting from Name, the tab order would above would be Name > Street Address 1 > Street Address 2 > Zip > Status > City > State > Country > Owner. Given our fields, it would make more sense to keep the address fields in a more logical order, so the tab order should be the following: Name > Street Address 1 > Street Address 2 > City > State > Zip > Country > Status > Owner. To achieve this without changing the field layout, “split” the section into multiple sections, but have only the General section display its header.

Note that the two new sections, tabSectionAddress1 and tabSectionAddress2, have grayed out section names and no black line underneath the name. This means that these sections will not be seen as separate form sections by the user, so the final published form will appear the same way, with the only different being the tab order.

Ease of data entry can greatly improve user adoption, so remember to design your forms intelligently with a tab order that makes sense.

- Phil Edry

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

By default, the Resource Center is added as a “Group” in CRM just like Workplace, Sales, Marketing, Service, and Settings are Groups. Via the web client, the Resource Center is accessible by simply clicking the Resource Center group.

 Via the CRM for Outlook client, the Resource Center appears alphabetically with the other CRM groups.

The Resource Center has quite a bit of content on it, some of which is applicable to typical CRM users, some of which is applicable really only to admins and super users. One of my favorite pieces of the Resource Center is the Getting Started Videos.

There are three videos that can be quite eye opening to users who are new to the system. The videos are high quality, and can really convince Marketing and Management that Microsoft Dynamics CRM 4.0 is much more powerful than a simple contact aggregator. Altriva teaches Advanced Find as a topic in user training, but it doesn’t always sink in the first time. A quick video refresher can help solidify CRM concepts introduced in training.

Still not sold? Think it’s just a bunch of clutter, or maybe it’s just not right for your business? Then remove it with the below steps. Anyone can still access the resource center by going to the following link in a web browser: http://rc.crm.dynamics.com/rc/regcont/en_us/opdefault.aspx

The following is taken directly from the Microsoft Dynamics CRM Installing Guide (4.4.0, pages 123-124)

1.     Export the SiteMap by using the Export Customizations feature.

a.    In the Navigation Pane, click Settings, click Customization, and then click Export Customizations.

b.   Select SiteMap, then on the Actions toolbar, click More Actions, and then click Export Selected Customizations.

c.    Save the customization compressed (.zip) file and make a copy of it as a backup.

2.     Extract the customization.xml file from the customization.zip file.

3.     Open the customization.xml file by using a text editor such as Microsoft Visual Studio or Notepad.

4.     Locate the following node in the file.

/ImportExportXml/SiteMap/SiteMap/Area Id="ResourceCenter"

5.     Comment the Area by using <!-- and -- > tags where the Id attribute is set to "ResourceCenter" as follows:

<!--<Area Id="ResourceCenter"

 ResourceId="Area_ResourceCenter"

 Icon="/_imgs/resourcecenter_24x24.gif"

 DescriptionResourceId="ResourceCenter_Area_Description">

 <Group Id="ResourceCenter">

  <SubArea Id="nav_lc_overview"

   ResourceId="Homepage_LearningOverview"

   DescriptionResourceId="LearningOverview_SubArea_Description"

   Icon="/_imgs/ico_18_129.gif"

   Url="/resourcecenter/overview.aspx"

   AvailableOffline="false" />

  <SubArea Id="nav_lc_sales"

   ResourceId="Homepage_LearningSales"

   DescriptionResourceId="LearningSales_SubArea_Description"

   Icon="/_imgs/ico_16_sales.gif"

   Url="/resourcecenter/sales.aspx"

   AvailableOffline="false" />

  <SubArea Id="nav_lc_marketing"

   ResourceId="Homepage_LearningMarketing"

   DescriptionResourceId="LearningMarketing_SubArea_Description"

   Icon="/_imgs/ico_16_marketing.gif"

   Url="/resourcecenter/marketing.aspx"

   AvailableOffline="false" />

  <SubArea Id="nav_lc_services"

   ResourceId="Homepage_LearningServices"

   DescriptionResourceId="LearningServices_SubArea_Description"

   Icon="/_imgs/area/18_service.gif"

   Url="/resourcecenter/services.aspx"

   AvailableOffline="false" />

  <SubArea Id="nav_lc_customization"

   ResourceId="Homepage_LearningCustomization"

   DescriptionResourceId="LearningCustomization_SubArea_Description"

   Icon="/_imgs/area/18_settings.gif"

   Url="/resourcecenter/customization.aspx"

   AvailableOffline="false" />

 </Group>

</Area>-->

6.     Make your changes to the customization.xml file.

7.     Import the updated XML file by using the Import Customizations feature.

8.     In the Navigation Pane, click Settings, click Customization, and then click Import Customizations.

9.     Locate your modified XML file and then click Upload.

10.  On the Actions toolbar, click Import All Customizations.

- Phil Edry

Click on the picture:

A few examples of the questions we have seen are:

“Let’s say I want to be notified 3 days in advance about birth dates of all the contacts in the system”
“I want a reminder sent to the owner of a case 3 days before the due date of the case”
“Is there a way to send a note to a manager if a case is untouched after 4 hours”

As with most requirements around Microsoft CRM there are multiple ways we can accomplish getting the reminder requested in each of these instances.  When we look at the different ways each one can be accomplished we need to understand what the actual business process we are trying to facilitate is and then look at our options.  Once we know our options and what business process we are trying to facilitate we can then decide based on our company's abilities or the abilities of our implementation partner which approach will work best for us.

Microsoft CRM allows this to be accomplished through many avenues:

• Passively (The user must do something to be reminded); a view or report
   
• Actively (The user receives the reminder without doing anything); schedule a report, creating a workflow or a custom application.

Build a View

The simplest to build is a simple view either via Settings -->Customizations --> Customize Entities or via Advanced Find and then sharing it out.  This view is very simple to create and will show you all open cases due in the next 3 days anytime a user goes to it.

This would make the view available in the case section of Microsoft CRM.  This will work but it requires the users to look at the view each day to make sure there are no cases due in the next few days.  This solution is very simple to complete and does not require any custom code and does not cause any performance concerns.  All you have to do is then train users to look at the view of "open cases due in the next 3 days" and enforce this process with review of the view by managers also to make sure things are happening.

Build a Report

This is the next simplest route to go is to either use the Report Wizard to build a report or use the SSRS report designer to build a simple case report.   If you are using CRM Online then you should use the Report Wizard because currently you are not allowed to load custom reports built using SSRS report designer.  Once you have created the report you can make it available from the reports section and from the case area via the reports icon. 

As with the view this is a very simple way to get this information to your users but it is a passive reminder because the user must remember to run the report each day to see the Cases that have a due date in the next 3 days.  The positives are that if you used the Report Wizard there was no special tool to learn and no custom work to build or deploy and you once again have no performance issues to worry about.

Build a Report and send it via E-mail (Not able to be done if using CRM Online)

If you are using CRM On-Premise you can create the same report using either the Report Wizard or SSRS Report Designer that shows the cases with a due date in the next 3 days.  You can then schedule the report within SSRS to use stored credentials and automatically send the report to a user or a group of users each morning.  This is less passive because the users do not have to remember to go to a view or run a report within Microsoft CRM but the users still must open the report in the e-mail and review the open cases.

Use Workflow

This is possible in workflow depending on how you want the reminder (Outlook Reminder or E-mail) to happen and how your users are using the system. 

If your users are using the Outlook client and synchronizing tasks to their outlook then you can very easily have a workflow on create of case first wait for the due date to be filled in and then create a task due 3 days before the due date that was entered which will pop up in their outlook as a reminder to work on the case.  The problem with this approach is if they do not use the outlook client or decide not to sync tasks to Outlook they will not get a reminder pop up and will then just need to be looking at their tasks due in CRM.  Another problem is if you only want the reminder to go out when the case is within 3 days of the due date this does not work because this will make a task for all cases when the due date is filled out.

A second approach using workflow would be to create a workflow that basically checks once a day and then send out an e-mail to the owner if it is within 3 days of the due date for the case.  This workflow would be pretty simple:

a. It would first have a wait condition that waited 24 hours
b. It would check if they case is still open if so continue otherwise end workflow
c. If the case is still open it would check if the Due Date is less the 3 days greater than the workflow execution time. If so it would create an e-mail and send it to the owner of the case.
d. It would start a new instance of that workflow again.

The good part with this second option is it only sends the reminder if the case is still open and within the 3 days of the due date.  The bad part is that it means you have at least one workflow running for each case you have open.  This can cause a performance burden on your system depending on the number of cases you have.   If you have lots of cases this is something to consider before you decide to implement this solution.

Custom Application

This will be a development effort and you can approach it multiple ways depending on your developer’s skill set and if you are using CRM Online or On-Premise.  Your developers could build a simple tool that runs hourly or daily and it could query CRM for open cases due in less than three days.  You can query against the SQL views (On-Premise only) in the database and send an e-mail or you can build it to query through the API's (Online or On-Premise) and either send an e-mail or create new tasks or e-mails within CRM. 

Summary

The route you choose depends on the actual business process you are trying to facilitate and your company’s abilities or partner's abilities in development and CRM architecture. All of the above will work with varying degrees depending on your specific business process requirement.

- Hoss Hostetler

Execution Pipeline Synchronous vs. Asynchronous Overview

The Microsoft Dynamics CRM 4.0 Execution Pipeline allows for synchronous and asynchronous event processing. Synchronous events execute one at a time, either before or after CRM Platform Core Operations (Create, Delete, Update, etc). Asynchronous events are added to the asynchronous event queue to be executed by the asynchronous process at some point in the near future.

The business impact of using synchronous and asynchronous events is more easily understood with the help of examples. The following two hypothetical examples detail two scenarios where events could be registered synchronously or asynchronously to satisfy a business requirement. While the scenarios will function with either registration method, there are advantages and disadvantages to the method as described below. 

Example 1: Account to Contact Cascading Addresses 

CRM users have requested an extension to Microsoft Dynamics CRM 4.0 that would update the addresses for all sub-contacts for an account when the account’s address changes. You write code to check if the address has changed on save of an account. If so, you retrieve the sub-contact records and iterate through the records to update each contact’s address. You now must decide if you should register the code synchronously or asynchronously.

If you register the event to run synchronously, users will have to wait for all of the sub-contacts to be retrieved, edited, and saved before form control is returned to the user after clicking save. The up side to this approach is that the user could be sure that once the full save event finishes, all sub-contacts would immediately reflect the address change. The down side is that user experience could become extremely sluggish when working with large accounts with many sub-contacts or when bulk-editing multiple accounts.

If you instead register the event asynchronously, the sub-contacts will be processed in the background (with a slight delay) without affecting user experience. The one downside occurs in the corner case when a user saves an address change for an account and then quickly opens a sub-contact record to see if the address was updated. There might be some user confusion if the asynchronous process had not yet updated the contact record. Since this is a rare corner case and it can be avoided through training, registering asynchronously is the clear choice to avoid performance issues.

Example 2: Custom Case Number Generation with Immediate Feedback

CRM customer service users track customer support information using the case entity in CRM. When a new case is created, an email is sent to the customer providing them their case number. The business has decided not to use the out-of-box CRM case number functionality, since they require an abbreviation of the case subject to appear in the case number in order to more easily categorize cases by topic outside of CRM.

When a user is in the process of creating a new case, they first ask the customer the nature of the call and choose a case subject. You write code that executes on save to generate a new case number and include an abbreviation of the subject appended to the number. You then create a workflow to send an email to the customer using an email template that retrieves the newly-generated case number.

At the end of a service call, customer server representatives would also like to verbally communicate the case number to the customer. If you register the .NET assembly asynchronously, service users would have to do an initial save on the case and then continuously refresh the case form until the asynchronous process gets around to updating the case with the case number. Synchronous registrations allows for the field to be updated on the case form as soon as the save event completes, allowing the representative to quickly provide a case number to the customer. Synchronous Plug-in registration is the clear choice in this case.

Conclusion

These two examples have quickly highlighted some the advantages and disadvantages of using asynchronously or synchronously processing of you custom business logic.  When deciding which route to take you need to understand how each will impact the user.   Will waiting for a response interrupt the process flow within the application or will not having the confirmation or custom logic result interrupt the process flow.  With each area of process automation we need to examine the best approach to facilitate the intended business process.

- Phil Edry & Hoss Hostetler

Workflows with Custom Workflow Activities vs. Plug-ins in Microsoft Dynamics CRM 4.0

We will start with high-level guidelines of when to use each tool and then get into the specifics of how the tools work within the Microsoft Dynamics CRM 4.0 Execution Pipeline with regards to the synchronous and asynchronous processing of events in a later blog post. We will not get into definitions of Custom Workflow Activities and Plug-ins or provide code samples since these are accessible from the CRM SDK documentation (click links to view).

As described in an earlier post “Custom Extensions Discussion - Intro”:

The best way to approach the custom extension capabilities of Microsoft Dynamics CRM 4.0 is to first fully understand your business processes, specifically which parts of those processes are causing you pain or costing your business money. The next step is to build those processes into CRM using the base CRM functionality and then re-examining your system to see which pain points remain. Then, with a good working understanding of all the ways you can extend Microsoft CRM, design your custom extensions to relieve the remaining pain points while taking into account the pros and cons of each custom extension approach.

Creating workflows through the CRM client (without calling custom assemblies) is a powerful way to improve business process facilitation. Basic workflow provides many benefits: no need for .NET expertise to develop, easy to modify (no code changes required), and you can export and import them like customizations. However, basic workflow also has its functional limitations. Fortunately, Microsoft Dynamics CRM 4.0 supports Custom Workflow Activities and Plug-ins for calling custom .NET assemblies to extend beyond basic workflow limitations. Given their similarities, it can be difficult to decide which method to use. Below are guidelines to consider when choosing your extension tool.

High-level Usage Guidelines

1. Custom Workflow Activities can only execute.NET assemblies asynchronously, while Plug-ins can execute .NET assemblies both synchronously and asynchronously. If you have already decided that your extension needs to execute synchronously, the choice is simple: Plug-ins are the only way to go. Synchronous and asynchronous event execution will be covered in detail in a following post with a description of the Execution Pipeline Synchronous vs. Asynchronous and examples.
2. If your .NET assembly is one step in a multi-step workflow, use Custom Workflow Activities. Workflow maintenance is simplified when all of the processing logic is in one place. This is especially true if a business process requires a mix of basic steps and Custom Workflow Activities to occur in a specific order. If you instead put your basic steps in a workflow and register you custom code as an asynchronous Plug-in, you’d have two places to maintain the processing logic and you would not be able to control the order in which the plug-in and workflow execute.
3. If you want to track a history of when your .NET assembly was run against an entity, use Custom Workflow Activities. Otherwise, use Plug-ins. Each time a workflow runs, a record of it is audited in CRM. This can be useful in some cases and distracting or unnecessary in other cases.
4. If you want the flexibility to easily disable or change what triggers a .NET assembly without changing code, use Custom Workflow Activities. Using Custom Workflow Activities within a workflow gives you the flexibility to publish and un-publish changes to the “Start when:” settings on the workflow form. It also allows users to run .NET assemblies against records as an on demand workflow.  The ability to quickly remove or add in custom logic to a workflow that business users can control can be very helpful especially with processes that are either dynamic or will be changing frequently.
5. If none of the above applies, it comes down to personal preference. We suggest Plug-ins. Generally speaking, it simplifies business logic maintenance to manage most of your .NET assemblies in the same place. Since Plug-ins can do both synchronous and asynchronous processing, and there is a good chance your system will require synchronous plug-ins at some point, it makes sense to register the asynchronous .NET assemblies as Plug-ins as well.

Conclusion

To close, there are quite a few things to consider when deciding when to use Workflows with Custom Workflow Activities and when to use Plug-ins. If you intend to register your .NET assembly synchronously or you don’t intend to leverage any of workflow’s basic functionality, use a Plug-in. If you’re ok with asynchronous processing and your .NET assembly is a sub-process in a contiguous workflow, you want an audit history, or you want to ease event trigger administration, use a Custom Workflow Extension.

- Phil Edry & Hoss Hostetler

There are many different options to automate business processes within Microsoft Dynamics CRM 4.0.  Today we will look at the differences between doing it via JavaScript that calls back into the CRM API’s versus using Plug-ins.

Automating Business Processes: Using JavaScript to Call API's vs. Plug-ins

Data validation and retrieval from other CRM entities or systems are often useful when automating business processes. There are multiple ways you can accomplish these tasks in Microsoft CRM. Two frequently used methods are synchronous plug-ins and form-level JavaScript calling either the CRM API's or integrating with another system.

One benefit to using JavaScript is that since JavaScript is run on the form (client-side), it can react to any OnChange or OnLoad event on the form and provide immediate feedback to users. In other words, users do not have to wait until saving the form for data validation or retrieval to take place. Additionally, client-side JavaScript allows for greater flexibility when communicating messages to the user, as well as with field manipulation. JavaScript's downside is that since it runs client-side, it requires more roundtrips between the server and client. This approach is not an issue if most users have good connections to the server. However, a client-side approach can impact performance in the case of a deployment with users spread across multiple offices or with users having slow server connections. Furthermore, creating an additional client-side connection to the CRM server or other external servers can break functionality when a user is offline or cannot access the external server. Another point to consider is that the use of client-side scripting transfers additional processing load from the server to the client

To contrast, Plug-ins in Microsoft Dynamics CRM 4.0 run server-side and therefore do not offload any processing load to the client. This is usually a non-issue unless your CRM server is underpowered. With server-side processing, the performance impact will be the same for all users no matter where they access CRM from. Another benefit is that the Microsoft CRM Plug-in model has built in ways to handle online and offline processing that are described in the CRM SDK. The downsides of using Plug-ins are that a user must click save to trigger the Plug-in and there are a limited set of responses you can send to the user from within your plug-in.

Both Plug-ins and JavaScript scripting to call API's have their uses. For example, JavaScript is a viable choice and could be the best solution if you are building a solution for a call center where all users have consistently fast connections and immediate data validation response helps their business process. On the other hand, if you have a dispersed workforce with slow or limited connections to CRM server, then the plug-in model might work better for you. One roundtrip on-save that results in an error message might be much quicker than waiting for multiple server roundtrips after each field is filled out.

- Hoss Hostetler

Removing Unused Entities via SiteMap vs. Security

Microsoft Dynamics CRM 4.0 has a full CRM suite of functionality built in out of the box encompassing Sales, Service, and Marketing. Most implementations of Microsoft Dynamics CRM 4.0 will not use the entire set of the CRM functionality, and in many cases, exposing unused functionality to the users can reduce the usefulness of the overall system. Removing unused areas or entities within MS CRM can make the MS CRM application much easier for a user to grasp.

Figure 1: User sees all links in the main navigation and the related section of the Account, which can be very distracting to users.

Figure 1

Figure 2: Shows the links pared down to the three they use currently in Sales and removed all the sections they do not use on the account related form.  This was done quickly through security.

Figure 2

SiteMap customization is a tool in Microsoft Dynamics CRM 4.0 that allows you to customize the main navigation pane by modifying XML. The good part about editing the SiteMap is that you can quickly remove areas of the application so that users do not see those pieces of the application in their clients. This can be really helpful within the outlook client because you can limit the CRM folders to only display the folders users will use. The big drawback to removing unused areas or entities via the SiteMap is that it applies to all users in the application, regardless of role. This means you cannot use the SiteMap to hide the Sales area for the Service team and hide the Service Area for the Sales team. Another drawback to using the SiteMap to remove certain entities is that it removes them from the main application navigation, but they will still show up on related entity forms.

Using Role Based Security to limit access by itself or in conjunction with SiteMap modifications is usually a better route to remove unused entities from users' views. Building security roles allows for differences among groups/users regarding which pieces of functionality are displayed in CRM forms as well as in the main navigation.

When deciding how to hide pieces of functionality in Microsoft Dynamics CRM 4.0, the first question to ask yourself is will a currently-unused piece of functionality be useful sometime in the future. Where possible, it is usually preferable to take away the right to see an object via security rather than just removing it from the sitemap. This is especially is true if you try to add the functionality back in later since users with the System Administrator role will still have access to the hidden entities and can quickly extend visibility to other roles.

In addition to hiding CRM functionality, SiteMap customization can be used to add new links to external systems or to rearrange the main application navigation to group things together to better fit your business processes.

Note: This only looks at two ways, which tend to be most often used, to accomplish removing/hiding functionality within Microsoft Dynamics CRM 4.0.   Other options exist such as unsupported JavaScript, unsupported base CRM page modification, rebuilding system entities using custom entities to not have related items you do not use and many others options.  Each option has different Pro’s and Con’s that you need to think about.  We will look into some of these other options in future posts.

- Hoss Hostetler

 
Success with Microsoft Dynamics CRM 4.0: Implementing Customer Relationship Management is aimed at readers who are interested in understanding how to successfully implement Microsoft Dynamics CRM 4.0 within their projects. It is intended as an implementation roadmap for the business and technical representatives leading or engaged in a project.

The book covers the capabilities of Microsoft Dynamics CRM, both in the traditional functional areas of sales, marketing, and service and as an applications framework for XRM deployments.

The book demonstrates Microsoft CRM best practices for design, configuration, and development. Through real–world solutions and exercises, you will be given the confidence and expertise to deliver an implementation that provides long–term success for your organization.

- Hoss Hostetler

• Your businesses processes do not align with standard SFA/Service/Marketing processes,
• The information users need for certain processes is not or should not be captured within your CRM system,
• The data requirements of your business processes are too complex for a user to manually enter and the potential for automation exists to streamline data entry.

• Designing your Microsoft Dynamics CRM 4.0 system without a good understanding of what is possible by leveraging custom extensions to better facilitate your business processes
• Building potentially unnecessary custom extensions without spending adequate time to analyze your business processes
• Building custom extensions for their "coolness factor" alone without making sure it helps facilitate your business process -- if an extension does not help facilitate your business processes then you run the risk of distracting from the real work that needs to happen.
• Favoring one form of custom extension over another due to familiarity with the tool without understanding the benefits and drawbacks in relation to other options to extend Microsoft CRM
• Building an overly complex system that can overwhelm users or not removing unused items till later in your company's CRM evolution when users will need those functions.

•  Workflows and Workflow Extensions vs. Plug-ins
•  JavaScript Use 
•  Supported JavaScript vs. Unsupported JavaScript 
•  SiteMap vs. Security
•  Workflows who should vs. who shouldn’t have access

- Hoss Hostetler

Now that we have wrapped up writing our CRM book (Success with Microsoft Dynamics CRM 4.0: Implementing Customer Relationship Management) it is time to move on to publishing some additional content through our website.

Since the book is now complete we needed a place to continue to share our insights and experience for planning, designing, and deploying successful CRM and portal solutions. We hope you find this section of our website helpful to your current and future projects.

In the first few weeks we will discuss how to successfully implement custom extensions within Microsoft Dynamics CRM 4.0 for your organization. We will be looking at how to approach custom extensions to make them the most successful for your organization in your implementation effort of Microsoft Dynamics CRM 4.0.

- Hoss Hostetler