Topic: ‘Best Practices’

Want to know more about Dynamics CRM 2011 on a technical level? Want to download and peruse the 2011 SDK? Want to view some tecnical articles specifically geared towards Dynamics CRM 2011?

Microsoft TechNet has a library with technical information that is very helpful for any technical consultant working with Dynamics CRM 2011. Click here to navigate to the Microsoft Dynamics CRM 2011 section of the TechNet library.

This simplifies things – the MSCRM Team Blog has released a Microsoft Dynamics CRM 2011 Online Check-List (compliments of the Microsoft Dynamics CRM Technical Support Team) that you can review prior to going live, allowing you to ensure that your settings in both Internet Explorer and Outlook are set up properly.

It includes information on settings in Outlook 2010, 2007, and 2003. It also includes information those settings required inside of your Internet Explorer browser.

On the final few pages, there are some very useful links to Dynamics CRM 2011 Online resources, such as eTraining and the MSCRM Community, as well as links to support websites, such as the CRM Knowledge Base.

Click here to review the post and download the Check-List.

The concept of merging inside of CRM is immensely helpful, especially if you are taking data from multiple databases and placing them inside of one database, like Dynamics CRM. Merging allows you to select two records that are duplicates, transfer data from one to the other, and deactivate the secondary record.

While this is helpful, it can also be dangerous – no data will be truly lost, but it will no longer be searchable on the primary record, and it will be tedious and difficult to transfer. Also, without correct planning, you may end up doing more warranty work than you originally signed up for. Read the rest of this entry »

There are several different ways to create records inside of CRM – well, as you use the CRM application, you’ll find there are several different ways to do just about everything, which can be a bit overwhelming. Fear not – there is always a BEST way to do each (at least in my opinion).

In this specific article, I’ll chat a bit about the creation of new child records – for example, a new Contact record, or even a new Activity record. For some, the creation of a new record is easily done by using the Dynamics CRM toolbar in 4.0, located at the top of your interface below the Microsoft Dynamics CRM logo. Another location is on each of the listviews, located throughout the CRM application. HOWEVER – if the record you are creating is a CHILD record of another record currently inside of the system, there is a better way.

Best practices encourages the use of what’s called data mapping, the transfer of data from one record – i.e. a parent record – to another record – i.e. a child record. A great example of this would be the transfer of information from an Account to a new Contact. There’s never really a need to retype all the information that should transfer over.

To utilize data mapping and follow best practices, the correct location to navigate to in order to create a child record is the ASSOCIATED VIEW of the child records, located underneath the parent record. For example, the Associated View of the Account’s Contact records would be inside of the Account form. Once you click on Contacts on the left-hand side of the Account form, you will now be viewing the Contact’s Associated View underneath the Account. The Activities section would be the Activity Associated View underneath the Account, and so on and so on.

Click on the New button from inside of the Associated View. Once the window opens, you will see the data transfer. Now just to be clear, this is all contingent on whether or not the information is actually FILLED OUT at the Account level. As long as that information is filled out and SAVED on the form, the information will transfer based upon the mapping configurations.

During my time as a CRM Consultant, I’ve realized something very important. However troublesome the journey, there’s always a silver lining – experience. So even though I’ve only been in the game a short amount of time, I’ve come up with a few best practices that I prefer to follow when implementing Dynamics CRM. For those who know me, I tend to be…opinionated is a good way to put it. So, yes there may be other ways to utilize CRM and still get by.

It’s known that each process flow – sales, marketing, service, SOP – requires a different path, but these should provide you with broad and useful guidance inside of CRM. Do note that the list below is by all means incomplete (Oh yes, I have plenty more…). These statements are an example of the tips that have given my clients – regardless of industry and business practice – the ability to enjoy clean, useful, and more importantly, valuable, CRM systems.

• For DATA ENTRY…Before importing data into the CRM system, spending a little bit of time running through and shaping the spreadsheet. Cleaning up the rows and columns will save you hours of data cleansing down the road. CRM is only as good as the data that is placed into it. And who knows – you may have missed a column that you need inside of the system.
• For PROJECT MANAGEMENT…Document, document, document. There is no such thing as “documenting too much.” Clients love nothing more than to see a clean, printed, color document with their logo on the front (who doesn’t?) and all the CRM information they could need. Documenting too little, however? That (unfortunately) exists.
• For PROCESS FLOW…When converting to Customer records (in the situation where the Customer does NOT exist in the system yet), I always recommend converting to at least an Account and a Contact. This is not only a time saver, but it is proper structure. After speaking with and qualifying a Lead, you are always going to have a company and a person in the system (Who signed the Contract? What organization did you type into Hoover’s before meeting with them to do a demo?). The one exception may be the Opportunity. If there’s no potential revenue to begin working within the next 6 months (depending on your average sales pipeline time and size), you can probably hold off on the Opportunity until you see it in the pipeline and can properly document what is necessary.
• For ATTRIBUTE ADJUSTMENT…When renaming fields, rename from the Attribute level the majority of the time. The main time renaming from the Form level comes in handy is when you have more than one field that needs to be named the same. (Example, “Date”). You can rename them in a unique manner on the Attribute level, and make them uniform on the Form level. The reason for this is mainly due to Advanced Find search capabilities. If you name everything the same, you will have more than one field in the AF search on that particular entity (causes much confusion).
• When CREATING FIELDS…When creating a new field, once you save the record after creation, you CANNOT change the type. So always be sure that you have the correct field type selected, otherwise you will have to create another field. So after I create a Picklist, I cannot “change” it to a character field. Same thing with the schema name – once the field is created, the schema information set in stone. To “change” the field, you would only be able to create a new field and remove the old one. I always document exactly what I need to create BEFORE creating them in the system. If you’re working for a client, create a spreadsheet of the fields (Display Name, Field Type, Requirement Level, Number of Characters (for Nvarchar fields), Potential Values (for Picklist or Bit fields), and any additional information) – this is important for proper generation and understanding. Nothing’s worse than realizing you’ve made a dumb mistake and having to delete and recreate 100 fields. And then justifying (or more accurately, trying to justify) the additional work to the client…
• For WORKFLOW…Always map and plan your workflow first before building the structure: this will help you just in case you make a mistake in the structure. Plus, mapping it out allows you to understand exactly what needs to happen. You may need a wait condition instead of a check condition – you can’t change this after you build the workflow.
• For WORKFLOW…You can’t change conditions in the logic, so always make sure that you’re creating the workflow properly from top to bottom. This statement certainly ties in with the workflow best practice listed above. When adjusting the structure of a workflow, if you are removing/adjusting part of the basic structure, deleting one step will remove everything after it.
• For ADMINISTRATION & TROUBLESHOOTING…Never delete a used security role. I know, you have the ability to do it, but I wouldn’t. Especially if a CRM user (or more than one CRM user) currently has the role. Deleting a utilized security role will kick those respective users out of the system. If you do want to get it out of the system, do this. Copy the role and plan on using the new role. Rename the old one to say “UNUSED” or “OLD.” Spend some time making sure all of the users are not assigned that particular security role. Run reports, AF views, whatever will help you verify that no one currently has that particular role. Then remove it from the system. This will keep you from getting dozens of angry, frantic emails.
• A CRM/OUTLOOK TIME SAVER…Utilize CRM shortcuts from inside of an email. After you track an email or Contact from Outlook inside of CRM, there are two buttons inside of the individual Outlook record that will take you directly to the respective records inside of CRM: View Record and View Parent (this will take you to the actual CRM record). This is really handy if you’re converting an email to an Opportunity.

Do you have any tips or tricks that you use when implementing CRM? If you do, I’d love to hear them!