Microsoft Dynamics CRM Team Blog

CRM 4.0 Simplified Sales Process Scenario

We often use scenarios such as this to test the individual components and entities of CRM in an integrated fashion. This is one example of a very simple sales scenario describing the flow of user actions in the Sales module of CRM. The flow chart below summarizes the walk-through text.

David is a dedicated sales representative and has just attended a trade show where he collected a large number of leads. He’s organized these into an Excel spreadsheet and uses CRM’s Bulk Import feature to quickly import these into CRM as Leads. CRM’s Duplicate Detection works to reduce any duplicate records. He also checks to see if any other salespeople are working with the existing customer(s).

Based on communications with a new Lead, David qualifies the Lead into an Opportunity with an existing Account. He sets the Price List for the Opportunity to enable him to draft a Quote to sell 100 bicycles to the customer. He collects information about Competitors and adds this to the Opportunity record for tracking. He sends Sales Literature information to the customer via e-mail to see if they are interested in other similar products. With the basics established for this customer relationship, David assigns the Opportunity and Quote to an Account Manager, Michael.

Michael continues working on the Quote with David’s help, along with Kevin, the Sales Manager. He uses CRM’s multi-currency functionality to establish pricing based on the current Exchange Rate, and maximizes the mark-up by modifying pricing on the Quote. When he’s completed with the Quote, he hands it off to the Order Processor, Susan. She verifies the pricing, mark-ups, and checks for accuracy before printing it for the customer via Mail Merge and faxing it to the customer.

After reviewing the proposed Quote, the customer requests that additional parts be added to the Quote and some others be removed. Michael revises the Active Quote to make the necessary adjustments and the revised quote is re-routed past Susan who takes the necessary steps to verify the changes, get them approved, printed and faxed back to the customer. The customer is satisfied with the revised Quote and decides to go ahead with placing an order.

Michael converts the revised Quote to a Sales Order record and a Workflow rule alerts Susan about the Order which needs to be fulfilled. She uses an ERP system to pull together the items needed to fulfill the Order. Susan closes the Order as Fulfilled and creates an Invoice from the Order. She sends the Invoice to the customer along with the bicycle parts the customer ordered. The customer then pays the amount billed in the Invoice. When Susan receives the payment from the customer, she closes the Invoice as Paid (complete).

Cheers,

David West

Customize the Default Member Type of a New Marketing List

When creating a new Marketing List from the detail form you will notice that the Member Type field has no default value, you must select what the member type should be. The Member Types allowed on a Marketing Lists are restricted to Account, Contact, or Lead. These values are not customizable, but there is a method I will cover in this blog that will allow you to select which of these three types (Account, Contact, or Lead) you would like to have populated as a default on the form when creating a new Marketing List. Setting a default value may save an extra step if you primarily only create Marketing Lists of one Member Type. The default value will still be selectable and changeable until you lock it in by “Saving” the new Marketing List.

Fig 1: New Marketing List with no default value populated for Member Type

Steps: (System Privileges to Customize the Marketing List Entity will be Required)

1. Navigate in MSCRM to Settings -> Customization, Clicking “Customize Entities”

2. Locate “Marketing List” in the Customize Entities Grid and Open

3. Navigate to the Marketing List “Forms and Views” and open “Form”

4. When the Form Window opens, Click “Form Properties” located in the lower right of the window.

5. When the Properties window appears, you will see on the Events Tab an “On Load” and “On Save” option. Choose “On Load’ and then click “Edit”. This will launch a new “On Load” event details dialog.

6. Check enable the box “Event is enabled”.

7. Next, Type the following code into the function onLoad text field

if (crmForm.all.createdfromcode.DataValue == null)
{
crmForm.all.createdfromcode.DataValue = 2;
}

Where Account is represented by the value of 1, Contact 2, and Lead 4.

8. Click ‘Ok’ on the Event details dialog, Click ‘Ok’ on the Form Properties window, and then Save and Close the Customize Form.

9. On the Customize Marketing List Entity Form, Actions Menu, Choose to “Publish”

Result: Now when you choose to create a new Marketing List and Launch the Form, the Member Type field will contain a default value.

Cheers,

Jim Schumacher

Time Zones in Microsoft Dynamics CRM 4.0

What’s New

Time zone implementation has undergone a redesign for Dynamics CRM 4.0.  Time zone definitions are now stored in the database.  All known rules are  maintained, and allow users a “Dynamic TZ/DST” experience. 

Terminology

Time Zone - A geographic area that observes the same local time.

Time Zone Rule - The definition of a recurrence pattern of how local time is converted to/from Universal Coordinated Time (UTC).  This includes information about Daylight Savings Time (DST) versus Standard Time.  Time zone rules can change over time, thus a time zone can have multiple rules from a historic point of view, but can have only one rule that is current and in effect.

Time Zone Definition - The entire set of rules (past, present, and future) for a particular time zone.

Dynamic TZ/DST - The notion that time zone definitions change over time.

Implementation and User Experience

Note: The following information is simplified for informational purposes, and does not represent exact implementation in CRM.

Example, using “(GMT -8:00) Pacific Time (US & Canada)”, hereafter “Pacific Time”:

Time zone rules are stored in the CRM database as follows:

TimeZoneRule (a single rule corresponding to the definition for Pacific Time)

In plain English, this rule can be interpreted as:  Starting 1/1/2007, Pacific Time is 8 hours behind UTC from 2:00 a.m. on the first Sunday of November until 1:59:59 a.m. on the second Sunday in March, and is 7 hours behind UTC from 2:00 a.m. on the second Sunday in March until 1:59:59 a.m. on the first Sunday of November.

The table above shows the current rule for Pacific Time, but actually there are two rules:

This is interpreted as:

• For dates between 1/1/1900 and 12/31/2006, rule ABC will be used (DST first Sun Apr– last Sun Oct)
• For dates greater than or equal to 1/1/2007, rule XYZ will be used (DST second Sun Mar – first Sun Nov)

Let’s say a user in Pacific Time creates the following appointments:

Now suppose the US government decides that starting in 2009, Pacific Time will no longer observe DST.  A new rule can be added via a hotfix:

This is interpreted as

• - For dates between 1/1/1900 and 12/31/2006, rule ABC will be used (DST first Sun Apr– last Sun Oct)
• - For dates between 1/1/2007 and 12/31/2008, rule XYZ will be used (DST second Sun Mar – first Sun Nov)
• - For dates greater than or equal to 1/1/2008, rule DEF will be used (DST not observed)

Now the appointments will appear as:

What happened?  Why is ApptC from 8:00 – 9:00 now? 

The time zone definition changed for all dates that occur after 1/1/2009.  Since ApptC occurs after 1/1/2009 and was created before the new time zone rule (DEF) was added, it still reflects the original rule (XYZ) that was used when this appointment was created. 

Why isn’t ApptC rebased when the new time zone rule is added?

It’s not possible for anyone but the user to know for sure what the true time of the activity is intended to be.  For example, an appointment for a conference call with attendees in multiple time zones – the user’s time zone changed, but the conference call is still occurring at the originally scheduled time in another time zone that did not change.  Only the user can know what the correct time should be.  If ApptC should appear as 9:00 – 10:00 in the user’s local time, the user will have to manually modify the appointment to correct the times.

Now the user in Pacific Time creates two new appointments:

The appointments are stored in the database as:

Note that although ApptD and ApptE were created at the same time, a different local-to-UTC conversion happened for each one.  That is because the latest known rule for each date was used.  Rule DEF was used for ApptD and Rule ABC was used for ApptE.  This is “Dynamic TZ/DST” in action!

Frequently Asked Questions

Now that time zone definitions are stored in the database, is a hotfix still necessary for new/changed time zones?

Yes.  Direct modification of time zone definitions is not supported.  A hotfix from the Microsoft Dynamics CRM Sustained Engineering Team is required to apply new time zone rules and definitions.

What should I do if I think I am affected by an upcoming time zone definition change?

Contact your CRM administrator or your Microsoft Dynamics Support team to inquire about hotfixes.

Additional Information

• Microsoft Daylight Saving Time Help and Support Center: http://support.microsoft.com/gp/cp_dst.
• Microsoft Hot Topics for Daylight Saving Time Changes:  http://support.microsoft.com/gp/dst_hottopics

Leslie Zavisca

Auto Numbers in Microsoft Dynamics CRM

Today we welcome our guest blogger and CRM MVP Ayaz Ahmad.

Last week I looked for the best approach to use auto numbers in Microsoft Dynamics CRM. After discussion with my peers I have come to the following possible options that can be used for auto numbering. These may not be the most efficient techniques to get auto numbers to work in CRM, but they are all workable and easy to implement solutions.

Option 1:

Very simple, supported and mostly acceptable way of auto numbering is to read the attribute Max value and then add 1 to get next auto number. For example you have a custom entity named Project and you want to auto number Project_Ref_Number attribute. But do not retrieve all records. Just retrieve the record with maximum number value by using following two properties of PageInfo Class in SDK and set descending order.

PageInfo.Count = 1;
PageInfo.PageNumber = 1;

One more consideration should be taken in account to register your auto number plugin to at PreCreate rather at PostCreate.

Issues:

In multi-user environment, this approach can come up with duplicate numbers in Project_Ref_Number when more than one user is creating project records.

Option 2:

This technique requires a bit more work but still supported way of doing things and all the time you will be getting 100% unique number.

You need to create a new table for project entity in a different database and not in CRM default database.

create table dbo.ProjectNumbers
(
Project_Ref_Number int identity(1,1) primary key clustered,
Projectid uniqueidentifier not null
)
go

Create a stored procedure for inserting a record into new database. This will increase the performance of your insert query.

create procedure dbo.proc_new_ProjectNumber

@ProjectId uniqueidentifier,

@Project_Ref_Number int output

as

insert into dbo.ProjectNumber

(

ProjectId

)

values

(

@ProjectId

)

select @Project_Ref_Number = scope_identity()

go

In your Plugin/Callout:

1. Access you database using ADO.NET

2. Execute stored procedure and get next number from returned results

3. Set the value of the returned number to target entity attribute appropriately.

4. All Done

Issues:

1. You have to setup database.

2. You have to read and insert into external database.

Option 3:

This option used a lock mechanism on a text file placed somewhere at your webserver. You can create one file to store next number for all entities or you can create one file for each entity. In your Plugin/Callout:

1. Put a lock on file.

2. Read the file and read the number there.

3. Update the number by adding 1.

4. Release the lock.

5. Use this number and set your target entity attribute appropriately.

string ProjectAutoNumber = "FilePath"

lock(this)

{

TextReader textReader = File.OpenText(ProjectAutoNumber);

AutoNumber = textReader.ReadLine();

textReader.Close();

AutoNumber = (long.Parse(AutoNumber) + 1).ToString();

TextWriter textWriter = File.CreateText(ProjectAutoNumber);

textWriter.WriteLine(AutoNumber);

textWriter.Close();

}

Issues:

1. Resource locking

2. File system Read/write cost

Although all these options work well but I am still looking for a more robust solution. Ideally I am looking for something using GUIDs which are instantly available and 100% unique.

For your suggestions and improvements, please comment.

Ayaz Ahmad

Testing CRM Plug-ins

During the development of CRM plug-ins, a developer will test his/her plug-in before putting in production server to make sure it works as designed. One way to do it is to have a development environment to test plug-in. However, the turnaround time between deploy-test-debug-build-deploy is very significant even when putting the plug-in on disk.

It would be nice to test plug-in locally without deploying it on CRM server. The approach I am going to demonstrate is to execute a plug-in in a small EXE container. Since IPluginExecutionContext is just an interface, we can mimic the context in our test container. Effectively, you will be able to rapidly develop/test/debug plug-in without ever leaving Visual Studio until you are ready.

I created a sample solution containing a simple test context and a test plug-in on code.msdn (http://code.msdn.microsoft.com/MSCRMPluginDebugger). This sample shows you how to populate relevant input parameters and how to create CrmService behind context. You might need to add more implementation to TestContext to suite your needs but this sample should be a foundation you can build on for example pre/post image or MetadataService.

A developer can use this approach for both debugging during development or for writing unit test. It would enable ISV to write unit test and run it from test harness/framework such as one provided by TFS.

Even though mocking IPluginExecutionContext can emulate container that plug-in will execute in, it is only approximation. Other differences can still make running in production different from test context, for example:

• Security context. CRM runs plug-in in service account (usually network service). Test contain runs plug-in in currently logged in user context. Files/registries may be accessible from log in user but service account may not , and vice versa.
• HttpContext. Accessing HttpContext.Current is not recommended. If you need something that is available only HttpContext.Current, please let us know. Ideally, plug-in should be able to get everything from IPluginExecutionContext.

NOTE: Depending on currently logged in user, you may or may not be able to impersonate a particular user. Only AD user in PrivUserGroup can impersonate other user in CRM.

Akezyt Janedittakarn

Configuring a Service Business in Microsoft Dynamics CRM 4.0

I’m excited to be the new writer on the Microsoft Dynamics CRM Product Documentation Team and I’m happy to contribute to this team blog.

When I first arrived I became very interested in the Service Scheduling feature and have written three articles about it for the Microsoft Dynamics CRM 4.0 Resource Center. In the article Configuring a service business in Microsoft Dynamics CRM 4.0 I use the example of a sports food service business to illustrate the power of the scheduling engine. The concessions business has some interesting dynamics: staff for food and drink stands, each resource having different skills (cashiers, cooks, counter servers), and some resources needing two skills, like a cashier for a mobile food service truck − who also must be able to drive the truck.

The article answers the question, how do we automatically schedule personnel based upon skill so that we can staff multiple food stands in a sports venue, like an arena or coliseum?  The answer is creating resource groups for skilled staff, creating services that require these skills in certain combinations, and then creating service activities in the scheduling calendar. It works! The power of the scheduling engine is amazing. Check it out and let me know what you think. If you have any insights or experiences around services scheduling (inbound or outbound), send them to me. I’d be delighted to hear them.

Kind Regards,

James Matteson

CRM Client AutoUpdate

A new feature in CRM 4.0 is for administrative ability to prompt clients to install patches on their CRM client. This feature is called AutoUpdate and it applies to any client where the user has administrative rights on his/her machine. I’ll document some common scenarios here and I’ll encourage you to read the Implementation Guide – Operating document for more detailed information.

When you install the CRM 4.0 client, one of the new components is a tool called Update. This is the client component of the AutoUpdate process. You can launch the Update tool directly, run it as a scheduled task quietly, launch it from Outlook under the CRM toolbar – Check for Updates or it will run each time you launch Outlook. Also, by default, the AutoUpdate check is performed on all CRM 4.0 clients* every 4 hours*.
* These options can be turned off or adjusted via registry keys.

In order to make updates available to clients, you need to post the updates to the server. The CRM Server installation comes with a new tool called the Client Patch Configurator. The tool is installed by default at [Program Files]\MSCRM\Tools\Microsoft.Crm.Tools.ClientPatchConfigurator.exe. You need to run a DOS command to call the XML file you can use to define the patches that will be provided to the client. The patch configurator process will add the patches to the MSCRM_Config database. You can use the tool to create, update or delete patch information, so if you add a patch you didn’t intend to add, you can remove it from being pushed to clients.

With that background information, here are the steps I give to customers asking how to set up AutoUpdate in their environment:

1. The first time you run autoupdate, go to your [ServerInstallDir]\Server\CRMWeb and create a new folder named crmpatches. Create this same folder on each subsequent web server in your deployment.

2. On each client, go to the registry and add a value in the HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRMClient key called AutoUpdateDownloadUrl (String). Give it a value of http://[servername]/crmpatches/ (remember the closing /). If you don't set this value, the clients will look to http://go.microsoft.com/fwlink/?LinkId= then the value in the LinkId XML parameter.

3. Download the hotfix to your server (or each web server) and extract the contents to the [ServerInstallDir]\Server\CRMWeb\crmpatches folder.

4. Extract the contents of the client patch on your server to determine the PatchId value which is required for the XML file configuration.

a. Open a command prompt, and type [DownloadLocation]\CRMv4.0-KB[KB#here]-i386-Client-INTL.exe /x

b. You will be prompted for a location to which the files will be extracted

c. Once extracted, find the config.xml file at the root of the directory

d. Within the XML file, copy the value of the <patchid> element and paste it into your configuration file in step 5

5. Create your configuration XML file

Here's a sample configuration XML for the KB949086 fix:

<ClientPatches>

<Create>

    <ClientPatchInfo>

        <PatchId>{85F5616A-F266-4E0B-BB4C-39B5B3AECE5C}</PatchId>

        <Title>Duplicates in Outlook with Shared Calendars, Tasks or Contacts</Title>

        <Description>Sharing calendar, contacts or tasks can allow editors to clear all custom crm information resulting in duplicates when synching</Description>

        <IsMandatory>true</IsMandatory>

        <IsEnabled>true</IsEnabled>

        <ClientType>OutlookDesktop,OutlookLaptop</ClientType>

        <LinkId>CRMv4.0-KB949086-i386-Client-INTL.exe</LinkId>

    </ClientPatchInfo>

</Create>

</ClientPatches>

Note: You can add multiple <ClientPatchInfo> and container elements to post multiple hotfixes at one time. The title and description are up to the administrator to complete. The IsMandatory option dictates whether a user has to install this hotfix in order to continue using CRM functionality within CRM. The ClientType can be either OutlookDesktop or OutlookLaptop or OutlookDesktop,OutlookLaptop depending on which clients should receive the updates. There are several more options available, so please see the Implementation Guide for further detail.

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

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

When Outlook launches, the following screen will pop up:

When complete, you'll see this screen:

8. You can then proceed to use CRM with the hotfixes applied. The hotfix installs will show in the Installed Updates area within Programs and Features in the Windows Vista Control Panel or in Add/Remove Programs on Windows XP.

This feature provides administrators with the assurance that their clients will be on the most updated hotfix. Therefore, CRM client troubleshooting doesn’t have to begin with the question “Did you apply these patches?”

Eric Newell

Integrating CRM using SQL Integration Services (SSIS)

Today we welcome our guest blogger CRM MVP Darren Liu from the Crowe company.

Many Microsoft Dynamics CRM (MSCRM) implementations involved integration with other systems. When I think of integrations between systems, the common approaches pop up immediately in my mind are BizTalk, Scribe or to write a custom integration framework using the CRM Software Development Kit (SDK).

By working with Darren Hubert, Solution Architect from the Microsoft National Service Pursuit Team in my last project, I have discovered another approach that I encourage you to consider in the your integration project which involves using SQL Integration Services (SSIS) to integrate with Microsoft Dynamics CRM.

SSIS is a platform for building data integration solutions and it is a service that runs on the SQL Server. SSIS replaces the existing Data Transformation Services (DTS), which was introduced to the market as a component of SQL Server 7.0, and runs a unique package which stores the design of an ETL (Extraction -> Transformation -> Load) process.

Because SSIS in SQL 2005 was difficult to connect to Web Services by default, I did not spend much time into my research for my previous integration projects. Thanks again to Darren Hubert and his friends, who showed me a work around using a CRM proxy class in my last project. I was able to successfully integrate CRM 4.0 using SSIS. Here I would like to share with all of you on what I have learned so that you can leverage it on your next CRM integration projects.

Before we get started, here’s the list of requirements:

• SQL Server 2005 Standard/Enterprise Edition with SQL Integration Service Installed
• Microsoft Dynamics CRM 3.0/4.0
• Visual Studio 2005 Professional Edition
• CRM SDK , C# and VB.Net knowledge

In this blog, I will use a simple example to show you how to send contact data stored in a SQL database to MSCRM 4.0 via CRM Web Services using SSIS.

Source Data

The source data is from the data from the other system that you would like to send to the CRM system. You source data can be a text file, an Access database, an Oracle database, etc… In this example, I will create a simple Contacts table in a SQL database that’s already existed in environment.

Source Table: Contacts

   1: CREATE TABLE [dbo].[Contacts](

   2:     [ContactId] [int] IDENTITY(1,1) NOT NULL,

   3:     [FirstName] [varchar](50) NULL,

   4:     [LastName] [varchar](50) NULL,

   5:     [Phone] [varchar](50) NULL,

   6:     [Email] [varchar](50) NULL,

   7:  CONSTRAINT [PK_Contacts] PRIMARY KEY CLUSTERED 

   8: (

   9:     [ContactId] ASC

  10: )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

  11: ) ON [PRIMARY]

  12: GO

  13:  

  14: INSERT INTO Contacts (FirstName, LastName, Phone, Email)

  15: VALUES ('John','Smith','312-888-8888','jsmith@crowe.com')

  16:  

  17: INSERT INTO Contacts (FirstName, LastName, Phone, Email)

  18: VALUES ('Darren','Liu','312-999-9999','dliu@crowe.com')

  19:  

  20: INSERT INTO Contacts (FirstName, LastName, Phone, Email)

  21: VALUES ('Adam','Johnson','312-555-5555','ajohnson@crowe.com')

  22: GO

Create CRM Proxy Class

The SSIS framework provides a Web Service Task which executes a Web Service method, however it’s difficult to use. To reduce the complexity of the SSIS integration with CRM, generate a CRM Proxy class using Visual Studio. This will make the integration process much smoother and you will encounter less road blocks.

Start a New C# Class Library Project

• Create a project name “CRM.Proxy”

Sign the Project

• Right click on the project and select “Properties”.
• Click on “Signing” tab and check the “Sign the assembly” checkbox.
• Select “<New>” from “Choose a strong name key file” dropdown.
• Give it a name for the Key. In this example, I use “integration” as my key name.

• Click OK.

Add CRM Web Services

Add CRM Web Service and CRM Discovery Service to the CRM.Proxy project. Visual Studio will automatically run WSDL.exe in the background to create a proxy class for these two CRM Web Services which we will use later on in building the SSIS package.

• Right click on Crm.Proxy project in the solution pane, then select “Add Web Reference…”.
• In the URL text box, type in the CRM Web Service URL and give “CrmSdk” as the Web reference name. My CRM Web Service URL in this example is http://localhost:5555/mscrmservices/2007/CrmService.asmx