In my previous blog I concluded that we typically make our solutions to hard to use and non-intuitive for our users. I also told that I have over engineered many solutions and I guess I could blaim my accounting degree for that. I just wanted to make sure we collect everything that we might need in the future. Guess what, people just don’t care about that requirement of they do not get any benefit of it. If you present a “metadata card” or list of 10 items they have to pick, they will just not do it. They much rather brake the rules than spend time filling in things. I also told in my previous iteration that I decided to take another route this time when implementing both my Dynamics CRM 2013 and SharePoint 2013 solution: minimal time spent in putting in data. Let’s just focus on what we really need for finding things and also categorizing things for different purposes. As we work with many clients and 0ne of our roles is to do outbound marketing/channel development, we need to make sure that we know what solution we have promoted to what company and what the result of the has been. We are known to present and help ISVs to build channels so our ecosystem also expects us to present solutions that might benefit solution partners in the Microsoft ecosystem.
In this blog entry, I will be focusing on the “kernel” or core of our company, which is our CRM solution. Every company/contact and lead are collected in the database and we maintain and nurture it every single day. It really is about making sure that all of our customers and contacts are kept up-to-date and informed about what is going on in the ecosystem. In the past, I used to customize both the account and contact entity within our CRM to the extent that I did not even know what each field meant anymore. I just wanted to be on the safe side that we would collect everything. That was a mistake. We ended up having lots of fields that were not used and many that did not make sense in the end of the day. I also confused before what to put on the account entity and what should go into the contact entity in respect to custom fields and sometimes I ended up replicating the fields. Not good. This time around if I have to reuse a field I am using “option sets” that can be regarded as “centralized metadata” that you can share across your Dynamics CRM 2013 entities. They are powerful and in my previous round of development I did not understand to use them. Having a centralized repository for your terms is powerful and helps you with your maintenance. In fact, I learned this from my 20 years in business intelligence/analytics/data warehousing. If you can centralize some thing, you should do it. There are of course some exceptions, but for the most part this approach has worked for me. In my future blog posts, I will explain how I used SharePoint 2013 term store as they are unbelievably powerful when used in the right way.
As you probably have heard about “app model”, Microsoft Dynamics CRM 2013 has a powerful concept of “solutions” which I find extremely useful and exciting. In the past, I did not realize that I should have created a solution from the beginning so any change that I made was made as part of my solution and if I created something useful, I could even potentially resell my solution. The inheritance structure and the way the solution works is in my mind one of the crown jewels of Dynamics CRM 2013.
You might now ask how much customization did I do for my account/contact entity. Not much.
If you look at the picture of my custom fields, you can see that my fields relate to very basic things such as ” Account Type”, “Lead Quality”, “Lead Source” and “Target Segment”. I also have two special fields, “movetodms” is a field that enables the user to tell CRM if the company information should be moved to SharePoint lists and the second one “Unique Import ID” is a field that is used when reading in data sets and they are tagged with the import identification. A good example is if we go to a conference, the conference id will become the ID for the data set. Data set is treated differently that “Lead Source” whereby the “Unique Import ID” will never change while the “Lead Source” can be edited. Another important factor that you can see from the picture is the prefix “tellus” which is automatically attached to the field name as I have defined a solution with the name “tellus”.
The “contact” entity has also custom fields that I have created and in this case there are more in this entity (contact) as most of our actions/tracking relate to specific contacts in companies. We do use lead entity every now and then and I was really struggling with the lead concept initially and we came to the conclusion that every name of a person could potentially be important for us so most of the lists are important as accounts and contacts. Keep in mind that we serve many companies and a solution/offering might not interest this company but another solution we are soliciting might be interesting in the future. If there is a “bulk list” of some sort, then I would definitely start by importing it as a lead list, but in our case and business model, account/contacts are what we track and are interested in.
In future posts, I will explain further how I keep and categorize things within these entities (account/contact) and how we know what offering/solution has been solicited for a specific contacts (I am using custom activity entities).
The picture of our contact entity has a bit more fields, but most of the fields are self-explanatory. I have added some social footprint fields such as LinkedIn and Twitter as they are not part of the “out-0f-the-box” Dynamics CRM 2013 entity. Some of the fields are the same as for the account entity, but they are needed as the data import is typically run as separate run and I want to keep track of each data import and it is very handy also for search and other classification initiatives.
As you can see, I have used mostly the “out-of-the-box” entities within Dynamics CRM 2013 and just added a few fields that we need for our own tracking. I have also removed aggressively sections from both account and contact forms that have no relevancy in our management consulting and channel development business. In future posts, I will explain some of the additional custom entities such as “ecosystems” and “solution types” are part of the account form and how they are used.
The contact form has a bit more information that I felt was important to collect. The two additional fields of interest are “Contact Profile” and “Target Ranking”. The first one lists the options that the end user can select and in our case they are things such as ” TELLUS Customer”, “Channel Lead” and in fact anything that let’s use list different types of contacts easily. What I have found out during the years is that end users are reluctant to create views and queries so I have tried to make some fields to act as filters for some of the information we are collecting.
In summary, it has taken me years to come to this simplistic approach, but when I look back at all of the companies that I have worked with in the management or as a consultant, people have always said that “lets keep it simple”. I am proud of this iteration of development and once you get to see the entire solution scenario, I am sure you can agree that we try to minimize the data entry and maximize the output. Keep in mind, my intention was NOT to use programming in our solutions as I want this to be maintainable without heavy-duty maintenance. My company does not have special needs and our business model is very simple, but we need to execute marketing an outreach for many companies so our CRM really has become the centerpiece of it.