Archive

Archive for May, 2009

Microsoft Dynamics CRM SaaS

For online testing of Microsoft CRM, create an account on www.javista.com

Imad Hajjar

Advertisements
Categories: Microsoft Dynamics

Data Design for CRM Projects – Customisation Approaches

May 22, 2009 1 comment

CRM offers a range of options when designing a CRM solution for a customer, from providing a completely standard, ‘out of the box’ solution, to a heavily customised solution where CRM is considered as more of a development platform. In this article I’ll discuss the broad customisation approaches, and examples of their use.

Preamble

Before getting into detail, I think it’ll be useful to explain my aims behind this post:

I have recently been spending time building design patterns based on direct and indirect experience of around 100 customer implementations of Dynamics. The primary aim of these design patterns is to be able to apply the experience gained as a company from these implementations to future implementations. The areas covered in this post form a basis for identifying approaches that can be taken, and the factor that influence some of the decisions.

This post is primarily concerned with what I term ‘data design’ – i.e. deciding on the data structures (as implemented by CRM entities, relationships and attributes), and the major functionality required of the design.

Don’t expect black and white conclusions from this post. A common theme is that many approaches are possible, and an overall design typically incorporates several approaches. My main intention is to raise awareness that the different approaches exist, and to focus on what factors should most strongly influence the decisions you take.

What factors affect the design choices

Before getting to the different approaches, we need to consider what factors are most important when comparing different design approaches. Whenever we start a design for a customer, we have to be aware that each customer will put different emphasis on these factors.

Benefits of using existing entities and functionality

There are many benefits to be had from using the built-in CRM entities, and their associated functionality. Little or no development time is required, the functionality is documented in the online help and other training materials, and additional components like the reports that ship with CRM can be used immediately.

Conversely, if you create custom entities, you may need to invest development time to provide specific functionality. You may need to invest time and effort in customising the CRM online help, or developing other training material that describes the custom entities and their use. If you want to report on the custom entities you will have to write new reports, or spend time modifying the built-in reports.

However, you need to decide if the built-in entities and functionality are appropriate for your requirements…

Appropriateness of the solution

A major benefit of having a heavily customisable product like CRM is that it can be customised to meet different companies’ needs. The main reason for customisation is to make the solution appropriate to your business requirements.

It is important to note that there is normally a trade-off between the extent of customisation, and the overhead of creating the customisations. If the built-in CRM entities do not map perfectly to your requirements and existing processes, then you may make the decision to adapt your requirements and/or processes, or you may decide to customise CRM to more closely fit your requirements.

Reusability of custom functionality or designs

3rd party add-ons are a classic example of how custom functionality can be reused, where the 3rd party invests the development effort in creating an add-on, and recoups (or hopes to) the cost by selling it many times.

Companies like ourselves that primarily sell CRM implementation services frequently aim for reuse, though sometimes in a less obvious way. A lot of the custom code we develop is intended for reuse, such that apparently custom functionality may already been developed, and will not need creating from scratch. A large part of my internal company work is around promoting such reuse.

Thinking of the future – maintaining flexibility

Any given design should work for a business in its current state, but what about that business in a year’s time, or 2 years ? Requirements and processes change over time, and you should expect a solution that can accommodate these changes. Some future changes can be predicted, and others can’t, but some customisation approaches result in a more flexible solution than others.

Also consider whether the business requirements and processes are stable, well known and understood at the start of the project. It is quite common for requirements to change during an implementation project, so again flexibility can be important.

Some CRM projects are conceived as a one-off implementation, after which little change is expected. Other projects take a more phased approach, where the overall solution is expected to be extended or modified after the initial implementation. In the latter scenario flexibility is more important.

The customisation approaches

An overall CRM solution often comprises different approaches in different areas of the solution; one approach does not need to be used across the board. For example, we almost always use the Account and Contact built-in entities in a standard way, but are more likely to use custom entities to handle fulfilment areas, using custom entities like Project, or Supplier.

Using built-in entities in a standard way

This is the ideal scenario, providing the built-in entities provide the functionality you want. Some, like the Account and Contact mentioned above, and also the activity entities, most often do provide the functionality you want. You’ll typically add extra attributes and modify the forms and views, but the core functionality is appropriate in most circumstances.

However, there are often cases where the built-in entities don’t work the way you do. You may decide to adapt your processes to fit the standard functionality, but it’s more likely you’ll take a more customised approach…

Extending the functionality of built-in entities

Often the built-in entities provide useful functionality, but it’s not enough. Providing the functionality they provide does not actually interfere, or conflict, with what you want, then it makes sense to extend the built-in entities.

An example here is the sales entities, such as Quote and Order, and the associated Quote Product and Order Product child entities. The functionality around pricing and costs is frequently appropriate, but you may need additional attributes to break down the pricing into different areas on a product. You may then need to develop additional functionality to perform calculations on the data in these attributes.

Creating custom entities in addition to the built-in entities

It is often necessary to extend the CRM schema with new custom entities. Necessarily the examples become quite specific; probably the most common custom entity we create is a Project entity to manage delivery of services.

CRM does provide a fair bit of functionality for custom entities, such as support for workflow and association with activities, but more specific functionality may need to be written.

Creating custom entities to replace to the built-in entities

Sometimes you need functionality similar to that provided by the built-in entities, but it is sufficiently different to what you get out of the box that it becomes more appropriate to create custom entities instead.

This is typically the area where the trade-off between the factors covered earlier is most acute. You may make a decision to incur the additional implementation costs of creating new entities and functionality because the built-in entity functionality is too inappropriate to the way your business works.

An example of this is around the Opportunity and Opportunity Product entities, and the Product Catalog. The Product Catalog is flexible, but does have limitations when selling bespoke products or services, or when anticipated revenue over time periods is important. So, in some circumstances we effectively replace the product catalog and related entities with custom entities (e.g. an Item entity), and provide custom functionality to summarise numeric values across items, or transfer items from an opportunity to a quote or order. We have also gone further still, and replaced the opportunity, quote and order entities with custom entities.

Note that when I use the term replace, I’m referring to what the user sees in CRM. The typical implementation pattern is to remove all permissions from the built-in entities we ‘replace’ so that they don’t appear in the CRM user interface – we don’t actually remove them.

Repurposing built-in entities

There are some scenarios where you don’t need an entity to provide the functionality it was intended for, but that functionality could be used in other ways. As entities can be renamed, and the text of CRM messages can be changed, it is possible to repurpose entities while keeping terminology in the CRM user interface consistent with the terminology used in your business

Any examples tend to be very specific and hence not very useful for a general post like this, but one worth explaining relates to the price list. One feature of the price list is that, when adding products to an opportunity, the products available for selection are those that have items on the selected price list. It is possible to repurpose the price list as a way of grouping products, and restricting what is available for selection, even if you don’t actually use the pricing functionality of the price list.

A potentially significant drawback of this approach is that it can restrict your flexibility to make future design changes – using the above example you may not need the price list now, but how sure can you be that you won’t need it in the future ?

Using 3rd party add-ons or off-the-shelf solutions

The approaches I’ve covered so far come from the premise that your solution is unique. However, there are areas where you can find an existing set of extensions or customisation that are appropriate. Several companies providing CRM implementation services specialise in a particular vertical market (e.g. banking), and can provide a set of standard set customisations that are appropriate to many companies in that market. As this post is concerned with data design, the more relevant example of a 3rd party is a provider of implementation services – if this post were concerned with designing specific functionality then add-on providers would be the more relevant example of a 3rd party.

If using 3rd party customisations then you still have to consider how appropriate they are to your business (to use the above example, not all banks work the same way). You may still need further customisations, and if you have to replace or modify the behaviour of purchased extensions, then the cost may be higher than if you had started from a standard CRM design.

Conclusions

The initial conclusion is that there normally isn’t one answer; it is possible that several approaches can be viable, and as mentioned earlier, most overall solution designs we create use a combination of approaches.

But, I think choice is a good thing, and it’s good to be aware of the alternatives. Ideally, given the relative weighting of the factor discussed earlier, and your specific business requirements, you will adopt the best approach(es) and the best solution, but it is often the case that you can get a successful implementation using one of several different solutions, using different approaches.

My personal view is that it is normally worthwhile customising CRM to meet your specific requirements. The customisation capabilities of CRM are very powerful, and if you have an implementation partner with solid experience customising CRM, then a lot can be achieved for relatively little cost. However, attention does need to be paid to the ramifications of heavy customisation, especially how it affects the training material and user documentation.

Cheers,

David Jennaway

Dynamics CRM 4.0 Implementation Guide update 4.4.0 is now available

I’m pleased to announce that the fourth update to the Microsoft Dynamics CRM 4.0 Implementation Guide (4.4.0) is now available!

In our commitment to provide continuous publishing to our customers and partners, Microsoft Dynamics CRM 4.0 Implementation Guide update 4.4.0 contains the following:

  • Over 40 corrections and revisions.
  • Several new topics, including…
    • Configure a Microsoft Dynamics CRM Internet-facing deployment
    • Install E-mail Router on multiple computers
    • Upgrading from Microsoft Dynamics CRM 3.0
    • Planning e-mail integration
    • Performance Counters
  • Included in this release is the entire IG assembled into a searchable compiled Help file (CHM)!
  • A mini-table of contents located at the beginning of each Word document chapter to ease navigation.
  • A change summary sheet that describes each correction and addition as well as its relative location in each guide.

To verify that you’re viewing the latest version, open any of the guide document files or chm file, and then on the first page of the document the revision number is displayed. Again, the most current release is 4.4.0.

The change summary sheet is a separate document included in the package. The document file name is v4_4_0_ChangeSummary.doc.

Get the latest version today at www.microsoft.com/downloads/details.aspx?FamilyID=1ceb5e01-de9f-48c0-8ce2-51633ebf4714&DisplayLang=en

Reminder: Most new topics are published to the Resource Center before being added to an update to the IG. To view this content and more like it early, visit http://rc.crm.dynamics.com/rc/regcont/en_us/opdefault.aspx?page=settings or click Resource Center in the application and then in the left navigation bar click Settings.

Special thanks to Greg Burbidge on our Doc team who worked unwaveringly to not only drive this update through completion but also migrate the entire IG into a new content development environment during the process.

Regards,

Matt Peart

CRM Online: ‘Contact Us’ Web Form Made Easy

May 22, 2009 1 comment

The Microsoft Dynamics CRM Online March 2009 Service Update introduced a very nice feature called “Internet lead capture” that is very useful for most small medium businesses (SMB).  It can save a lot of time by automatically capturing ANY web form entries and loading them into Microsoft CRM Online.

FLee

Here is a video about it in more details: http://www.democrmonline.com/IMWebtoLead/

We had updated our Workopia website’s Contact Us web form to utilize this new Microsoft CRM Online Internet lead capture feature.  It was really easy to setup and works the very first time.  It took only about 30 minutes from start to completion and now anyone that submits our Contact Us web form, the data will go directly in to our Microsoft CRM Online system.  Very cool.

Some notes about setting up:

1. The Landing Pages setup wizard is very user friendly, since this is an initial release, the choices are pretty basic but should be enough to get the job done

2. There are only 32 CRM Lead fields (last name, first name, company, title, email, business phone, address, etc.) that are available for use on a landing page.  Currently, it doesn’t support adding other CRM Lead fields to this list.  Again this works for most landing pages

3. In case you do need to capture data that is not a direct map to any of the 32 CRM Lead fields – I would suggest picking one of the un-used 32 CRM Lead fields to capture the data and then use a CRM Workflow rule to move this field’s data to the proper CRM Lead field after it is in CRM Online

4. I would prefer the “Use your own site” option for most cases.  This allows for total control of our Contact Me Request web form looks and feel.  However, for a quick and simple web form to capture data, I’d suggest trying out the “Lead capture pages” option.  Using this option, the web form is automatically generated and hosted by Microsoft CRM Online.  Here is an example of our CRM Online Statistic FREE Download Registration web form using this option

5. I want to be email alerted whenever someone submitted our Contact Us web form, however this option is not built-in.  Instead here is a good “keep it simple” work-around: we had our web site developer customized the Landing Page’s Submit button URL page with the functionality to send an email alert.  Any good web administrator or programmer should know how to perform this work-around.

Cheers,

CRM MVP Frank Lee

Microsoft Dynamics CRM Online Video Gallery

We have a lot of CRM screen casts posted at www.democrmonline.com. Some samples include:

Video: General Overview – Time: 15:00
This video will provide a navigation overview of Microsoft Dynamics CRM Online via the Outlook client and Internet Explorer Web Browser.

Video: Sales Overview – Time: 12:00
This video will show the sales features in Microsoft Dynamics CRM Online from creating a lead that leads to an opportunity that then
leads to a quote.

Video: Customer Service Overview – Time: 14:54
This video will provide an overview of the customer service functionality in Microsoft Dynamics CRM Online.

Video: Marketing Overview – Time: 21:04
This video will show the marketing features of Microsoft Dynamics CRM Online, including Campaigns, Marketing Lists, Campaign Activities and Responses, and Reporting.

Video: Service Scheduling Overview – Time: 13:55
This video will provide an overview of the service scheduling functionality in Microsoft Dynamics CRM Online.

Video: Reporting Overview – Time: 15:29
This video will show the reporting capabilities in Microsoft Dynamics CRM Online.

And one of my favs:

Video: Workflow – Trade Show Lead Process – Time: 10:30
This video will show how easy it is to utilize workflow to create a simple trade show lead follow up process.

Enjoy,

Eric Boocock

Customizing Microsoft Dynamics CRM 4.0 for High-Latency and Low-Bandwidth Environments

The MS CRM Engineering Excellence (E2) and Dynamics Premier Field Engineering (PFE) teams recently collaborated on a benchmark testing effort designed to measure the performance improvement associated with customizing an “out-of-the-box” implementation of Microsoft Dynamics CRM 4.0 to accommodate the requirements of a specific, real-world business scenario in which the customer would encounter potential issues with network latency and bandwidth.

Testing Plan

To derive the necessary data, we defined the following testing plan:

1. Define the specific business scenario

2. Perform a 500 user un-optimized run

     a. Collect network stats for first-run (cold) experience

     b. Execute benchmark

3. Customize CRM to accommodate requirements of business scenario

4. Optimize CRM/SQL based on the workload

5. Perform a 500 user optimized run

     a. Collect network stats for first-run (cold) experience

     b. Execute benchmark

Business Scenario

To meet the criteria of for the business scenario, we specified that the customer:

  • Has offices located in four, geographically dispersed regions with varying network characteristics
  • Uses Microsoft Dynamics CRM 4.0 for account and contact management
  • Has customized the CRM deployment for optimal levels of network performance across all regions

Summary of Customizations

Based on this scenario, the teams customized the application by engineering a user interface that required fewer roundtrips and transmitted less data. Below is a summary of these customizations.

  • Customized the Account and Contact forms
    • Disabled Forms Assistant
    • Changed the Default Public View to display two fields
    • Removed selected fields and search fields
  • Changed Number of Fields returned to 25
  • Specified to show only Sales in Workplace Pane
  • Changed the security role to only allow the Contact and Account Entities
  • Disabled Duplicate Detection
  • Removed as many items as possible from the left Navigation Bar (except Workplace)
  • Customized Accounts and Contacts grid to show only the Name and a few other key fields
  • Removed the majority of items in the left Navigation Bar of the Account and Contact forms

Detail of Customizations

The actions, rationale, benefits, and potential caveats that are associated with each of the customizations are shown in the following table:

Customization Rationale Benefit/Caveat
Customized the Account and Contact forms
Disabled the Forms Assistant Users do not require the Form Assistant Application requires fewer roundtrips to load
Changed the Default Public View to display two fields Eliminating unnecessary or unused fields Reduces the amount of data sent to/from the CRM Client
Removed fields:

  • Account form: Other Phone; Fax; Phone; Address2; Address3
  • Contact form: Street2; Street3; Country/Region; Phone; Salutation; Middle Name; Home Phone; Fax; Pager
Eliminating unnecessary or unused fields streamlines form layout Reduces the amount of data sent to/from the CRM Client
Removed search fields:

  • Account form: Account Number; E-mail
  • Contact form: All except FullName
Eliminates unnecessary or unused search fields Enhances query execution; reduces the amount of data sent over the network
Changed the Number of Fields returned to 25 Users can locate specific records by reviewing 25 or fewer fields Increases the efficiency of record searches and reduces the amount of data sent to the CRM Client, resulting in faster rendering times
Modified the Workplace Pane to show only Sales Simplifies navigation by removing unused/un-needed options Prevents accidental navigation; facilitates training; and reduces the amount of data that is sent to/from the CRM client and the number of associated roundtrips
Changed the security role to allow only the Contact and Account entities “Hardens” the deployment by removing access to unused entities Helps to lock down the application to provide access only to necessary business functions. Removing access to unnecessary entities also removes their visibility from the Workplace pane, in turn reducing the amount of data and roundtrips required by the CRM Client
Disabled Duplicate Detection Customer anticipates that the system will not contain duplicate records Reduces data checks on Save; limits on-screen functionality to reduce roundtrips and data sent to the CRM Client
Removed all unnecessary items (except Workplace) from the left Navigation Bar Simplifies navigation Streamlines interface, prevents accidental navigation, facilitates training, and reduces the amount of data sent to/from the CRM Client and the associated number of roundtrips
Removed unnecessary items from the left Navigation Bar of the Account/Contact forms. Customer only uses CRM for account/contact management Streamlines interface, prevents accidental navigation, facilitates training, and reduces the amount of data that is sent to/from the CRM Client and the number of related roundtrips

 

Testing Results

Overview

The tests we conducted were focused on the first-run (Cold) experience of the application. The subsequent run (Warm) experience of the CRM 4.0 application is highly optimized and typically only involves a handful of roundtrips and a very small amount of data transferred.

Note: For details of a network utilization study that documents the results of an un-optimized Cold and Warm run experience, on MSDN, see Microsoft Dynamics CRM 4.0 Performance and Scalability White Papers at:
http://www.microsoft.com/downloads/details.aspx?familyid=5852B14A-394C-4898-8374-CAF5E6479EB0&displaylang=en

While the performance improvements covered in this posting apply to both a Cold and Warm run experience, the savings associated with Cold runs are more significant.

Test Run Results

Deployment Home Page Create Account Create Contact Find Account Find Contact Open Account Open Contact Update Account Update Contact
UN-OPTIMIZED                  
Bytes Sent  98,262 170,982 173,482 115,114 114,807 160,878 160,435 174,791 173,832
Bytes Received  278,385 443,321 449,537 312,798 311,167 455,093 450,625 458,521 454,488
Roundtrips 123 222 223 141 140 220 219 226 225
UN-OPTIMIZED IFD                  
Bytes Sent 146,485 290,842 289,113 174,169 172,566 291,207 286,798 301,482 297,972
Bytes Received 191,681 357,704 353,496 226,743 225,255 364,542 359,335 367,247 361,876
Roundtrips 90 177 176 106 105 179 177 183 181
OPTIMIZED IFD                  
Bytes Sent 131,007 213,304 228,210 138,444 149,952 230,151 221,229 217,022 229,750
Bytes Received 174,321 267,011 292,400 180,052 203,839 354,941 295,024 273,788 295,251
Roundtrips 81 131 140 86 93 143 137 133 141

% Improvement between Un-optimized non-IFD and Optimized IFD

Measurement Home Page Create Account Create Contact Find Account Find Contact Open Account Open Contact Update Account Update Contact
Total Bytes Transferred 18.94% 21.81% 16.44% 25.57% 16.95% 5.01% 15.52% 22.50% 16.44%
Roundtrips 34.15% 40.99% 37.22% 39.01% 33.57% 35.00% 37.44% 41.15% 37.33%

IFD vs. Windows Authentication

The default authentication model (Windows Authentication) attempts to send each web request with anonymous credentials, and the server responds with a 401 response for those items that require authentication. At this point, the client sends the credentials. Items that do not require authentication are sent back immediately.

It is important to note that using the IFD deployment model reduces the roundtrips that are required to complete a business transaction because authentication credentials are sent with the web request. However, adding this credential also increases the amount of data sent to the server, which is reflected in the test results above.

Summary

Test results demonstrate that the customizing the CRM application can significantly improve performance in WAN environments. While customer business requirements will dictate the level of customization required, taking the approach described can dramatically reduce the network utilization and roundtrips required by the CRM application.

Thanks,

Jim Toland

Update Rollup 4 for Microsoft Dynamics CRM 4.0

The Microsoft Dynamics CRM Sustained Engineering team released Microsoft Dynamics CRM 4.0 Update Rollup 4 on Thursday, May 7, 2009.

Below are the links to the release and related information about the Rollup. Please see the Knowledge Base (KB) article for more details about the Update Rollup 4 content and instructions.

Install Details about Update Rollup 4

 

  • Update Rollup 1, Update Rollup 2 and Update Rollup 3 are not prerequisites for installing Update Rollup 4
  • The Update Rollup 4 client can be deployed before the server is upgraded to Update Rollup 4
  • Update Rollup 4 can be uninstalled

How to avoid a required reboot when installing a patch for the CRM Outlook Client

  • Before starting the update process, go to Options from the CRM menu. On the “General” tab, uncheck the bottom checkbox that says “Always run the…Host process” and then click “Ok” button.
  • When manually checking for updates, go ahead and close Outlook by choosing Exit from Outlook’s File menu. This will close Outlook along with the CRM add-in and the Hoster process.
  • Now check for updates by selecting All Programs from the Start menu. Then select Microsoft Dynamics CRM 4.0 and choose Update.
  • Restart Outlook after the patch is installed.

Note: If the user doesn’t want to make the permanent change of always having the Hoster process exit when Outlook exits, they can close the Hoster process manually after Outlook has been closed by right clicking on the Dynamics icon in the Notification Area of the Task Bar.

Making Update Rollup 4 available to your clients via AutoUpdate

You can find more information about AutoUpdate in Eric Newell’s blog entry at http://blogs.msdn.com/crm/archive/2008/05/08/crm-client-autoupdate.aspx and the Microsoft Dynamics CRM 4.0 Operating and Maintaining Guide, part of the Microsoft Dynamics CRM 4.0 Implementation Guide.

If you have a direct internet connection from your client machines, you can avoid some of the configuration steps and use the LinkId directly. Below are the necessary steps to configure the AutoUpdate for Update Rollup 4.

Note: These are steps 5, 6 and 7 of Eric’s blog.

Steps for the English version of the product

The PatchId and LinkId values will be different for every localized version of CRM 4.0. The IDs can be found in the KB article at http://support.microsoft.com/?kbid=968176.

1. Create the configuration XML file and save it.

   1: <ClientPatches>
   2:     <Create>
   3:         <!--- *** UR4 PATCH -->
   4:         <ClientPatchInfo>
   5:             <!--- *** The PatchId is different for every Language.  Please see the KB Article at http://support.microsoft.com/?kbid=968176 for correct Patch ID to use -->
   6:             <PatchId>{004A7E60-5DB7-4F05-B7C1-1D2DD653A1A6}</PatchId>
   7:             <Title>Update Rollup 4 for Microsoft Dynamics CRM 4.0 (KB 968176)</Title>
   8:             <Description>Update Rollup 4 for Microsoft Dynamics CRM 4.0 (KB 961768)</Description>
   9:             <!--- *** This will make it Mandatory -->
  10:             <IsMandatory>true</IsMandatory>
  11:             <IsEnabled>true</IsEnabled>
  12:             <ClientType>OutlookLaptop, OutlookDesktop</ClientType>
  13:             <!--- *** The LinkId is different for every Language.  Please see the KB Article at http://support.microsoft.com/?kbid=968176 for correct Link ID to use -->
  14:             <!-- & in xml documents must be escaped using &amp; -->
  15:             <LinkId>150735&amp;clcid=0x409</LinkId>
  16:         </ClientPatchInfo>
  17:     </Create>
  18: </ClientPatches>

2. From the command prompt, go to the directory where the ClientPatchConfigurator.exe is located ([ServerInstallDir]\Tools and type microsoft.crm.tools.clientpatchconfigurator.exe [configfile].xml

3. Once the patch has been uploaded, launch the Outlook client

The dialog should now appear saying that “Update Rollup 4 for Microsoft Dynamics CRM 4.0 (KB 968176)” is available. If the <IsMandatory> is set to false, the client will only see the update if the user selects “Check for Updates” via the CRM Menu in the Outlook client.

Cheers,

Matt Brown

Link and Patch IDs for Update Rollup 4 are now part of the KB article. Please see http://support.microsoft.com/?kbid=968176 for more details.