In our last blog, we discussed which of the CRM Entities to use and, just as important, which ones to avoid using. In this blog, we’ll continue the discussion on best practices for designing a low cost, low maintenance CRM system using a well thought out, systematic ‘Hierarchy of Easy’ method.

Use the Easiest, Most OOB Method to Solve a Problem First

Easy is good. Simple is good. But sometimes consultants think that if mere mortals can do something, they won’t get paid the high prices they deserve. So they do everything they can to complicate, confuse, and code when they could have just as easily used CRM components that do NOT require coding to solve the problem.

It also seems like some .Net developers have a hammer (C##), and see the entire world as a nail (plug-in).  They often disparage anything that isn’t .Net “because then all the code isn’t in one place”…  !  The implication is that bug finding, and therefore fixing, is going to be more expensive.

Well, I have news for you…   There IS going to be code (or at least things that code used to do) all over the place in CRM. But that doesn’t necessarily mean that bug finding and fixing will be more expensive.  All your team has to do is follow this basic rule:

 

 

IF you do that, and you agree on the “Hierarchy of Easy” I’ve defined below, then you know where the “code” is – and that’s wherever it made the most sense to put it!

The Hierarchy of Easy

The concept is simple – start with the easiest, most cost effective solution first, then work your way up to more difficult, more costly solutions as needed. Don’t just automatically jump into coding a solution – is there an easier way first that will accomplish the same thing?

This is how I would go about solving a problem:

• Document the Requirements, build the complete Rational Data Model, build the long-state model, and spec out just this phase.
• Think about how you might use Goals, and use the key OOB Entities (see previous post for my suggestions)
• Build Entities, Create Relationships, Populate Reference Tables, Build Filtered Lookups
• Add Fields. Use Calculated and Rollup fields to solve any problems those fields can solve
• Build Many Role-Based Forms and Views
• Use Dialog and Workflow (especially instantaneous) to make your forms more responsive.
• Use Business Rules to knock off the simple hide/show field and default value requirements.
• Use Third Party Tools to do what you can’t do OOB
• JavaScript, if you must. (CRM Rules can help if you don’t know Jscript)
• Use Scribe to Integrate systems
• Code .Net Plug-ins, if that is the only way to solve the problem (and it often is, don’t get me wrong… but not EVERYTHING needs a .Net solution!)

Here are the reasons why this works:

Uses Lowest Cost Solutions First.

While it may cost more upfront to think about the requirements, document them, get signoff, and then build a data model and identify phases before you even touch CRM, your overall cost will be lower if you can do more configuring and less coding, and more spec’ing than re-configuring.

Changes implemented faster, from bottom to top.

Not only is it lower cost, but if you are doing this internally, then doing things in this order will make your team faster, too.  Things always change.  Minimize your on-going investment by making it easy to make changes.  That isn’t done by hand-coding everything.

Uses the Power of the Tools.

CRM keeps getting better.  Why would you code a filtered lookup today when you can create one in seconds in the UI?   We use CRM because it is easier than starting from scratch and writing a bunch of CRUD (Create/Read/Update/Delete) code.  So, use the tool!    CRM allows us to build custom entities, but that IS using the tool (and cheap compared to coding)!

Allows for the use of third party tools.

Don’t discount third party.   If you have lots of Product Configuration, look at using Experlogix.  If you need 100 different form rules, check out CRM Rules.  Likewise, if you want to do any kind of email marketing, start talking to Click Dimensions.  If you are importing more than a few tables, or integrating two systems, or inserting a record into CRM that requires using the API, consider using Scribe. Third Party tools can be immensely helpful when used thoughtfully.

People know where to look for the code.

If I tell you I want to Hide this field unless the Type = Customer, I know the easiest way to do this is with a Business Rule, so I can go to that entity, open the form, and find my rule, and change what I need to.

Configure, configure, configure… then code

Here’s a real life example that illustrates the all-too common problem of coding a solution when a CRM configuration would do instead.

A Travel Agency wants to solicit business from area hotels.  First, they want the system to figure out which hotels have occupancy that date.  Secondly, they want to personally narrow down the list, then, select those hotels to be contacted to see if they will offer a discount.  Next, they want to review those responses, and finally, send the best one or two to the client from which to choose.   How would you design that solution?

What I actually came across was really a beautiful solution, and the users liked it.  I didn’t, and you’ll see why below.  (But I’ll give you a hint: Long term cost of ownership.)

The solution:  A plug-in found the properties in the desired city and state, and displayed them in a subgrid.  (requirement 1 handled, and I have no problem with this part of the solution.  Now, here’s where I start having a problem).

A (unsupported) button to the top of that grid says “Select Hotel”.  When they select a row in the grid and click the button, that hotel moves to the possible list, which is another sub-grid to the right of the fine “Desired Hotels” grid.  This is rather brilliant actually, as this is a N:N relationship between this reservation request and this supplier…  The same two entities linked by a 1:N relationship in the first grid.  The reason for this design was so they could delete a hotel from the “desired” list, but still have it remain in the “possible” list, for metrics, etc.

Then, they have another button on top of that grid that says “Send email for quote”, where they ask for a discount.  If they reply (thru the web, custom code to integrate back to this entity), then they show up in the third grid (another 1:N to another entity), and finally, one more button to select the options and email a quote to the client…

Phew!   Lots of code behind four custom buttons!     And it could have all been avoided.

I see this type of “state-full” design all the time, and the thing is, that actually could have been workable, and doable with workflow and not .Net.  But the design is unnecessary.

Let’s go back to the requirements.

• Enter City and State, get list of hotels.
• Manually pick, ask for discounts
• Manually pick, send to client

Now, each Reservation can have many potential hotels, and each hotel can be a part of many reservations so we have a classic N:N relationship here.  But do we implement that as an N:N in CRM?  Noooo, we do not.  In fact, I never use the N:N relationship, because you can’t modify the intersection table this is created…  Instead, create two 1:N relationships, then you can add fields to the intersection record.

So we create a Reservation entity, a Hotel entity, and a Reservation Hotel entity.  This intersection entity has a N:1 back to both Reservation and the Hotel.  Right now, it is just a form with two lookup fields on it, joining one reservation to one hotel.  Many of these can be linked to the Reservation.  And, if you create a new reservation, with the city and state, and save, that great plug-in can search our hotel info and match then up, and actually create new Reservation Hotel records, which we can display in a sub-grid on our Reservation form.

Now here is the key.    Each of these plug-in created records have a status of “Matching City and State and have vacancy”.  Now, the requirement was that the user wanted to select many of these to ask for discounts.  We don’t need another entity here.  We don’t even need another sub-grid.  We just need another status:  “Send Email for Discount”.  When that status is set, we don’t need code.  We just need a workflow that will send a previously built email template to that hotel.   (Actually, in this case, the easiest way to go is to create a Click Dimensions survey and have them go to the link page fill out the questions, and have that portal update CRM… very soon, CRM itself will have surveys… ) The workflow can also set the status to “Sent Email; Awaiting Discount Reply”, so it doesn’t send more than one.

Then, if we have a survey, we can run a workflow to update that status to “Discount Received”.  Or, with perhaps ADX portal and a web link.  Again, CRM surveys will be the preferred solution soon.

Finally, we can select one of our Reservation Hotel records, and update the status to “Send to Client”.  Workflow can then send an email with that Reservation Hotel info, Reservation Info, and Hotel info.

In short: requirements met, with no .Net code, and no unsupported buttons…

Bottom line

The bottom line is, CRM is so flexible that you can easily make some serious mistakes in your design.  While experience is the best teacher, one important key is to use the right (cheapest, easiest) tool for the job.  Another is knowing which CRM objects and features to use, and which ones you can (and in some cases, should) safely avoid.

Happy XRM’ing!