Topic: ‘Dynamics CRM’

 

New E2 Whitepaper: Connectivity and Firewall Port Requirements in On-Premise Deployments

Posted January 20th, 2010 by Kristen O'Connor / No Comments

The E2 team at Microsoft has released another informative whitepaper: Security and Authentication in Microsoft Dynamics CRM: Connectivity and Firewall Port Requirements in On-Premise Deployments. You can download the document here at the Microsoft Download Center.

The Microsoft Dynamics CRM Team Blog has posted a great summary of the article. You can view the post here.

Continue Reading

 

Dynamics CRM 4.0: Workflow Best Practices

Posted January 19th, 2010 by Kristen O'Connor / No Comments

Workflow is one of the most desired functionalities inside of CRM implmentations, and one of the driving forces behind the utilization of CRM. The Microsoft CRM Team Blog has posted some great information regarding workflow best practices on their blog.

Click here to read the article.

Continue Reading

 

Microsoft Dynamics CRM 4.0: Advanced Find Search Functionality

Posted January 7th, 2010 by Kristen O'Connor / No Comments

When working with clients, I get plenty of questions surrounding Advanced Find, especially from companies that are utilizing SSRS Reports. “What can it do for me?” or “How do I do this?” or “I don’t want to have to run this every day. Can I save it?” All of these questions are great for many reasons, including educating the client on things that they can do on a day-to-day basis in terms of informal “reporting,” and generating personalized views to see on a daily basis for personal or group utilization.

Advanced Find, which in my opinion is kind of like an informal BI tool, allows you to manipulate the data in numerous ways, giving you ad-hoc insight into the data you have in your system without having to shell out the big bucks for a SSRS Report. This is something that end users can do anytime of the day without the need for a technical consultant. I am going to highlight a few questions that I am usually asked as well as answers to those questions, and I will also provide some AF ideas for you to use inside of your system.

First of all, here is a quick Q&A:

1. What can it do for me? AF can manipulate the data contained in your system by allowing you to create what are called “clauses.” You can create AND/OR clauses to display conglomerate or mutually exclusive results, or you can create one single clause to display a large amount of data with less specific properties. How many Leads have been created in the past week? Month? Year? How many of these have not been modified in 7 days? 14 days? How many customers do I have in Atlanta, GA? New York, NY? Miami, FL? How many Leads do I have without an email address? As you can see, you can find all of this information easily by adding one or two clauses to the AF query. After you have the results, you can do a number of different things with it: save it as a personal view (or share that view with related parties who are CRM users), export it to Excel, perform a mail merge, etc.

2. Is it easy to use? Yes, it’s very easy to use. Once you get used to the language of the Advanced Find criteria queries, you’ll be fine. But it does take some time to get used to. If you’re a technical user, you may understand it and how to use it the first time. However, some others may find that they need to spend about 20 minutes trying a few different queries before fully understanding it. All I can say it – do not give up if it is frustrating. The value you get from utilizing this ad-hoc search feature is priceless.

3. Can I choose what fields I want to see in the results view? Yes, the columns are completely customizable. Before you click Find to pull the query results, you simply click Edit Columns on the main criteria window view. This will allow you to add or remove columns as you wish. You can add columns from related entities as well (for example, if you’re searching for Contacts, you can add a field from the Parent Customer (or the Account) related to those particular Contacts).

4. What if I don’t want to run this every day? You can save it as a personal view for yourself (it will appear as an option in that entity’s listview options), or you can create it as a personal view and share it with other users. This is handy for regional views – you can create one for each region and share it with the respective users.

I use Advanced Find extensibly on every project, so I’ve been exposed to many view types and criteria. I’ve generated some great view ideas that users can easily generate themselves and use on a day-to-day basis:

1. Lead turnover query: Open Leads created more than 1 month ago
 01

Leads should be in the system no longer than one or two weeks (one if you have a large amount of Leads coming in, two if you have a large amount of Leads coming in). Sometimes Leads may slip through the cracks, and going back and seeing which Leads are past due may not be on your priority list. Having this quickly accessible view on hand will keep you from having to do unnecessary research.

2. Opportunity pipeline queries: Open Opportunities closing in the next three months

02

There is already an Opportunity view that displays all Opportunities closing in the next month; however this new view allows you to look at a kind of “quarterly” opportunity pipeline. It may not be the exact 1st, 2nd, etc. quarter, but looking at a three month pipeline will give you a good view of future income without looking too far into the future. You can add additional clauses if you would like, or adjust the months.

3. Prospect list: Active Accounts that have an Account Type of Prospect
 03

The out of the box environment does not have views that separate the different Account Types. This view allows you to see all of the current Prospects in the system. You could also streamline this into all of the current prospects that YOU own.
 04

This allows you to easily access an exhaustive, real-time Prospect list within seconds. You could manipulate this view to look at any other Account Type in the system, as well.

As you can see, Advanced Find has the ability to allow you to manipulate data inside of the CRM system. You can create these ad-hoc “reports” almost instantly and without much effort, and the amount of value you can gain from utilizing this functionality is exponential.

Continue Reading

 

Microsoft Dynamics xRM Plans: Taking Dynamics CRM to “a New Competitive Level”

Posted December 31st, 2009 by Kristen O'Connor / No Comments

How much do you know about Microsoft Dynamics xRM? If you’re a Dynamics CRM Consultant or Partner, I’m sure you’ve heard some exciting rumors about the growth of the concept and potential that xRM has to offer. Click here to view a new article on MSDynamicsWorld.com regarding the urge by Microsoft to take xRM “to a new competitive level.”

Continue Reading

 

Social Networking Accelerator for Dynamics CRM 4.0

Posted December 22nd, 2009 by Kristen O'Connor / No Comments

In a generation where social networking is climbing off the charts in popularity, technology companies are adapting to the changing needs of their current and potential customer base. In October, Microsoft released the Social Networking Accelerator for Microsoft Dynamics CRM 4.0. This accelerator, one of many accelerators released in a new series of add-on solutions, allows you to utilize social networking solutions in partner with your Dynamics CRM 4.0 environment. Download it here from the CodePlex site to see how it can be beneficial to you. If you want to see the most recent news regarding the CRM Accelerators, click here to go to the post on the MSCRM Team Blog.

Continue Reading

 

More CRM Online Functionality: New Record Type & Field Creation with Import Data Wizard

Posted December 21st, 2009 by Kristen O'Connor / No Comments

Are you interested in learning how to create new record types or new fields in CRM Online? Check out this post on the MSCRM Team Blog by Veera Bansal – it describes how to utilize the Import Data Wizard inside of CRM Online to create new record type and new fields in the system. This enhanced feature of the Import Utility is explained in more detail in the November 2009 Service Update for CRM Online. Click here to view a previous post on this information.

Continue Reading

 

Update Rollup 8 Available for Dynamics CRM 4.0

Posted December 17th, 2009 by Kristen O'Connor / No Comments

Microsoft has just released Update Rollup 8 for download. Click here to download it from the Microsoft Download Center. If you want to read the respective knowledgebase article, click here to go to the Microsoft Support article.

Continue Reading

 

Quick Post on Pre-Filtering Data in Dynamics CRM 4.0

Posted December 16th, 2009 by Kristen O'Connor / No Comments

There’s an interesting post on the MSCRM Team Blog by Inna Agranov that verbalizes how to pre-filter your data in CRM, allowing you to query results much quicker. The post also contains a link to another article, located in the MSDN library. It describes in more detail how to filter CRM reports through SQL Reporting Services.

Click here to go to the Team Blog and read the post, or click here to go directly to the MSDN article.

Continue Reading

 

Want to know more about importing information into Dynamics CRM Online?

Posted December 11th, 2009 by Kristen O'Connor / No Comments

Microsoft has a blog post on their MSCRM Team Blog that provides information towards importing more than one entity type (in this case, both Accounts and Contacts). The post contains numerous screenshots, which allows for a higher level of understanding towards the process flow to follow.

Continue Reading

 

Renaming Fields Directly on the Form: When It’s Beneficial and When It’s Detrimental

Posted December 9th, 2009 by Kristen O'Connor / No Comments

For the most part, I try to steer people away from renaming fields directly from the form POV. This usually creates a more disorganized environment (and believe me, disorganized environments are my “nails on a chalkboard.”). If javascript is desired on the form sometime down the road, the code is usually difficult to understand and read if schema names do not accurately reflect the purpose of the code. Additionally, and most importantly, the information will be nearly impossible to understand from an Advanced Find POV (searching for SSN information by selecting Anniversary seems strange to me…). However, sometimes this comes in handy, and is almost beneficial from a form cleanliness standpoint. So I like to go by a certain “A or B” rule when renaming fields. This helps the environment I’m working on stay user-friendly and organized.

Situation A: I have a new field I want to put on the form, but I have fields on the form that I don’t use. Should I recycle a field or create a new one?

Solution A: Remove the unused field from the form, and CREATE A NEW FIELD. This will reduce the amount of confusion down the road, and it also leaves open the possibility of using that particular field sometime in the future. Business processes change, and the existing fields in the system may become useful sometime down the road. Always leave this possibility open by creating new fields for new needs.

Situation B: I have 4 different fields with the exact same name, let’s say Monthly Fee. I want them all to say “Monthly Fee” on the form, but I want to be able to run AF queries off of each of these data points.

Solution B: From an Advanced Find standpoint, it will be difficult to know which Monthly Fee field you’re selecting. If you’re looking for a specific one, they would need to be renamed to something else. When encountering this situation, I RENAME the field from the FORM LEVEL. I make sure each field name is unique from the attribute level (e.g. when I’m creating the fields, before saving them), and input an attribute name like Monthly Fee (Q1). Inside of the field properties on the form, there is a Display Name area. Rename the field here. Doing this keeps the form  clean (no parentheses), and keeps Advanced Find searchable.

Here’s a rough example:

FIELD 1: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q1)

FIELD 2: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q2)

FIELD 3: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q3)

FIELD 4: Monthly Fee would be the display name on the form, but the attribute’s true display name would be Monthly Fee (Q4)

The best way to accomplish the above example would be to plan for it – map it out before you create it. This will be much easier than fixing something that’s already built (mostly from a confusion standpoint rather than a time standpoint). However, if you already have an environment in place where this is an issue, the best way to do it would be to follow this process flow:

1. Rename the fields from the ATTRIBUTE level to a unique name (do this on all of the fields in question before moving onto step 2).

2. Rename the fields from the FORM level to a uniform name.

Continue Reading