Unitek Microsoft CRM Blog

One of Microsoft’s strongest selling points of Microsoft CRM 3.0 was its integration with Outlook. Microsoft correctly deduced that many Users were used to managing their day to day activities through Outlook. This not only included email activities but contacts, appointments and other tasks as well. Many Users had become dependent on Microsoft Outlook’s calendar as their primary visual tool for managing their appointments and tasks. In Microsoft CRM 3.0 emails and appointments could be synchronized in CRM but not other activities (the biggest complaint was the lack of synching of phone calls). But my experience in teaching CRM 3.0 Applications to end users has been User frustration about not being able to fully use Outlook to manage all of their day to day tasks. They did not like having to go in and out of Microsoft CRM to schedule common tasks such as phone calls. They had grown used to scheduling phone calls as tasks in their Outlook Calendars and getting convenient pop-up reminders.

Well Microsoft has addressed this in CRM 4.0 with the ability to synch not only emails, but phone calls, faxes, letters and tasks. Users can now function primarily through their familiar Outlook interface using the Outlook Calendar to schedule tasks in CRM. They also get the benefit of being able to schedule useful pop-up reminders that Users have grown use to (or in some cases dependent upon) to remind them to do daily tasks. When a task is scheduled, the “Track in CRM” box gives the User a Drop Down option to select which type of task to be tracked in CRM. CRM tasks are viewed in the Outlook Calendar as all other tasks in Outlook. When tasks are scheduled within CRM they are automatically pushed out to the User’s Outlook Calendar. There is only one drawback to scheduling tasks directly in CRM and that is inability to schedule a pop-up reminder within Outlook. An Outlook pop-up reminder will still occur for those tasks directly scheduled in CRM but it will be for whatever the Outlook default pop-up reminder setting is set for. This new feature should make Outlook Users much happier and more comfortable using CRM.

KE
Microsoft CRM Consultant
Unitek Microsoft CRM Services

One of the unusual quirks with Microsoft CRM 3.0 is the hard-coded default Views. For example, while in a Contact form and you click History, the default view is for “Last 30 Days”. This has been one of the most disliked features of CRM 3.0 and we are sad to report the same condition exists in the new CRM 4.0 version. The good news is we’re going to show you how to change these Views.

Let’s start with the CRM 3.0 method . The code we’re going to use was borrowed from Michael over at stunnware. He has a great explanation of how we build the code, but we’ll just get straight to the code and enhance it a little. Our adjustment will modify 3 related entities, Activities, History and Opportunities. For each one we will make the default View “All”.

Assuming it’s the Contact’s View that you want to alter, in the Customization area, open the Contact form. Go into the Form Properties and then the OnLoad event. Copy this text and paste it into the OnLoad window:

Continue Reading »

One of the most desired and long awaited features for Microsoft CRM is duplicate record detection. In Microsoft CRM 4.0 (formerly Titan), Microsoft has added duplicate detection capabilities at multiple levels. One of which is Duplicate Detection Rules which can run automatically to safeguard the system from users entering duplicate records. Duplicate detection can take place only if duplicate detection is enabled in Duplicate Detection Settings and if at least one duplicate-detection rule (A rule that specifies criteria for identifying a record as a duplicate.) exists for the record type. Rules interact differently depending on if they are grouped together or separately.

We can take a look at how this works by using an example that I’ve found many clients have desired which is duplicate detection of Leads to existing Contacts. The criteria I use in this example are to check for identical email addresses, first name and last name. In the Duplicate Detection Rules area (located in the Data Management area in Settings) we start a new rule and choose Lead as the Base Record Type and Contact as the Matching Record Type. Then we select the email, first name and last name attributes in both of the records and set the criteria to “exact match”. We have created one rule for all of these criteria which will cause duplicate detection to detect a possible duplicate Contact record when a new Lead is entered if ALL criteria are met. So if a Lead is entered with a different first name but the same email address and last name are correct, duplicate detection will NOT detect the possibility of a duplicate Contact record.

Let’s try two rules that involve both entities. Again the Base Record Type will be Lead and the Matching Record Type will be Contact. In this case we will create two separate rules. One with criteria matching exact email addresses and one rule that matches exact first and last names. When we run both of these rules together, duplicate detection will detect if a newly entered Lead has an email address that matches an existing Contact OR if BOTH the first AND last name of the newly entered Lead matches a Contact.

The way I think of this is similar to groupings in the Advanced Find. When using one rule with multiple criteria it’s like grouping your criteria with an “AND” grouping in the Advanced Find. When using multiple rules on the same entity(s), it’s like using an “OR” grouping in the Advanced Find. One last thing to consider is that there is a maximum of up to 5 rules per entity in Microsoft CRM 4.0

KE
Microsoft CRM Consultant
Unitek Microsoft CRM Services

While it is best to keep the name of the Microsoft CRM system entities such as Account, Contact, Lead, etc the same, sometimes the benefit of doing so out ways the negatives. One of the benefits of changing the entity name is that it helps users understand its function/use better and cuts down on confusion. Also it would be useful to adopt Microsoft CRM to fit the terminology used by the organization. Most of the time the name change is required for the following two entities:

• Account
• Contact

In Microsoft CRM Account is used to store information about companies an organization interacts with. These could be customers, partners, resellers, distributors, etc. Contact is used to store information about people. They too could be customers, partners, resellers, distributors, etc.

A common name change for the Account entity is “Company”. A possible name change for Contact is “Individual”. Renaming a Microsoft CRM entity requires a number of manual steps to ensure that all references to the entity are consistent. Following are the areas that need to be changed:

• Entity Name
• Entity Form Labels
• Entity View Names
• Entity Attribute Display Names
• System Messages
• Online Help Content
• Reports

Some areas where the entity name cannot be changed are:

• Platform error messages and messages that are displayed in Trace or the Event log.
• Strings in “Add Users Wizard” for adding multiple users at one time.
• Strings in “Environment Diagnostics Wizard”

Tip #1: Sub-Account and Sub-Contact

The steps that one would have to go through to make the Microsoft CRM entity name changes have been outlined by number of sites and I will not go through them here. However, I want to make sure to point out that if you decide not to make the name changes in System Messages and Online Help Content in the interest of saving development time and cost, do make sure to change Sub-Account and Sub-Contact strings. These strings show up in the left pane of An Account or Contact record. These strings are in the System Messages section. So if you don’t change any of the systems message do this one

RM
Microsoft CRM Consultant
Unitek Microsoft CRM Services

The recommendations that follow are among some of the first suggestions I make to my customers in order to make using Microsoft CRM 3.0 easier for their users. While the recommended customizations are simple and easy to implement, they contribute greatly toward making the Microsoft CRM easier to use and can potentially have big payoffs in terms of user acceptance. So be a friend to your users and implement these recommendations.

Tip #1: Stop confusing your users.

Microsoft CRM’s Advance Find uses attribute’s Display Name to list each entity’s searchable fields. Having a label on a form that is different from the Display Name of the field can become very confusing and can create unnecessary frustration for your users.

1. This mismatch between Form Labels and attribute Display Names exists in the standard installation of Microsoft CRM 3.0. So my recommendation to you is that the first chance you get, go through your Microsoft CRM installation and change either the Display Name of the attributes or the Label on the Entity Forms so that they match. In most cases you will be changing the Display Name of the attributes to match the Labels on the Entity Forms than the other way around.
2. When creating new customized attributes to be used on the Forms, keep this tip in mind and make sure the Labels and the Display Names for fields, used on the Forms, match.

Continue Reading »

There are times that we need to access and use data in CRM that we don’t want the users to see. For example we might want to make sure a Contact entity item enters a particular Workflow only once. This can be a tricky proposition when you have Contacts that need to be in Workflow both from the Create action and the Assign action. Utilizing a hidden field in CRM will be our method.

First off, let’s understand the concept of hidden fields. We can add an attribute to an entity and never add that attribute to the form. That in essence is a hidden field. Depending on our usage, we might also make the field Unsearchable. If we don’t then the field appears in the Advanced Find view and we may not want our users to see the data in this hidden field.

Let’s assume our custom, hidden attribute is named “InWorkflow”.

We now have a field that will hold the info we require. In this example we’re discussing how to utilize this field for Workflow. Since our Contact entity has the same rule set for Contacts that are created and assigned, we’ll set up 3 Workflow rules:

1. On Create – Call the Manual Rule
2. On Assign – Call the Manual Rule
3. The Manual Rule – The rule that holds all our logic

It’s possible that a Contact might enter this Workflow more than once and that’s what we’re trying to avoid. In the Manual Rule we’ll use the Check Entity Condition & we’ll check the status of “InWorkflow”.

• If the status is Yes, then we choose the action Stop. We do this because we know the Contact is already in this Workflow rule.
• If the status is No or Null, then we Update the Entity to set “InWorkflow” to Yes.

Now we continue about the Workflow, adding our conditions and actions. If at any point we need the Contact to leave Workflow, make sure you Update the Entity to mark the “InWorkflow” to No.

As Microsoft CRM consultants, we are usually called upon to come up with a solution to a tricky problem. Our customers love it when we come up with creative solutions to what first seemed an impossible task.

While teaching a custom Microsoft CRM 3.0 class for a company, I had a number of students who were asking me about the phone number format in the Account and Contact forms. The issue is that Microsoft CRM accepts multiple formats including dashes, parenthesis and other format combinations and variations. The ability to auto-format various phone number formats that users entered into a common format had been present in their previous CRM software. However the out of the box, Microsoft CRM 3.0 does not auto-format phone number fields in the Lead, Account and Contact forms.

Continue Reading »

Many customer relationship applications provide the users an automated process to populate City & State after the user enters a Zip Code, but CRM sadly does not. If your business needs this functionality the following tutorial was written with you in mind.

Using the following methods, we’ll add a new entity in CRM, populate it with zip code, city & state info and then we’ll show you how to make CRM fill in a Contact or Lead’s City & State after a user enters a zip code.

Step 1 - Create the Custom Entity

• Name the Entity “Zip Code”
• Choose “Organization” as the Ownership type
• Unselect Notes and Activities (do we need an activity for a zip code?)
• Choose the Areas to display the entity. (I chose none but you may want to display it initially for any troubleshooting)

Click over to the Primary Attribute tab.

• Make the display name & schema name “zipcode”.
• Change the max length to 20. This should be plenty for most of us.

Continue Reading »

Here’s an easy to implement customization that can save users time & clicks. We’re going to force CRM to put a Contacts phone number in the form Title bar, enabling users to view History, Activities, Opportunities, etc., all the while having a view of the phone number:

Continue Reading »

Reporting is a vital portion of CRM that is often overlooked. Many reports are needed on a regular basis by CRM users and if we stick with the pre-defined methods, users must go to the Reports section of CRM.

We’ve implemented a more user friendly method that you too may like. We design and deploy our SRS reports in Visual Studio.

Once deployed we modify the Site Map, adding links to the reports on the CRM main navigation bar. Since we’re using Site Map, we can put the same link in multiple sub-sections like Workplace and Sales. With a single click, the report opens in CRM’s main window.

Our customers love this easy method for reporting!

Continue Reading »