Today we’re going to dig into one of the fundamentals of CRM On Demand system design – really one of the first things you are going to be thinking about (or should be) when kicking off a project.

And no, we’re not talking about where to hold the launch party or who will cater it.  We’re talking about the data model – the real meat and potatoes of your CRM application. It’s deciding what goes where and how it all gets tied together.

 But “Wait” you say, “isn’t that simple? I mean, On Demand has all of that right out of the box – Accounts connect to Contacts, Accounts and Contacts link to Opportunities, Opportunities have product revenues… What’s there to decide?”

You’re right. Short episode, I guess. But hold on – maybe, just maybe, some folks have a slightly different way of looking at their data – maybe they have completely different kinds of data types that On Demand doesn’t have out of the box. Should you recycle and rename one of the existing data elements? Create a new custom object?

So let’s talk about some things to consider when designing your own data model.

The nice thing is, you’ll find a whole chapter on this very topic in the CRM On Demand Deployment Guide. So go there for the detail, but we’ll cover the highlights here!

First, what are we talking about?

The data model – we’ll sometimes refer to it as the object model – is the business objects and their relationships to each other. So again, Accounts have a particular relationship or link to Contacts and Opportunities, etc.

At a simplistic level, there is a general parent-child set of links. But many objects also support what we might call “secondary” relationships. A simple example of this is Contacts. Contacts can be linked to multiple Accounts, but only one of them is the “Primary” Account.

Know what you’ve got

OK, now we know what we’re talking about. Next thing to do is get a good understanding of what you have before you start customizing it.

Again, this is something that is covered in depth in the Deployment Guide. Diagrams and everything in Chapter 5.

But if you are too cheap to buy the book, you can get an idea of what’s there just by clicking through the application. What’s harder to grock from this approach is the inherent relationships, and the key features each object possesses. Let’s look at Accounts as an example.

CRMOD has set up Accounts to represent the companies you do business with, compete with and partner with. As such, we’ve put some special purpose fields in there, like Account Type and the Reference checkbox. These fields are refered to in pre-built lists. Type in particular will drive dynamic layouts.

Accounts are a “top level” object, so they can have many children including Contacts, Opportunities, and Assets. Being the parent has some priveleges – certain traits are “inherited” by the children, such as currency and, in the case of Contacts, the company Address.

Each of the CRMOD oob business objects has similar special purpose fields and relationships. Get to know them.

Repurposing objects

Repurposing is the idea that you are going to use an object intended for one purpose to represent something else. So perhaps that could mean renaming Accounts to Inventory and tracking your stocks there.

Bad example, true. Is repurposing good or bad? As in most things, it depends. As a general rule, you should strive to map your business objects to the CRMOD objects that are the closest fit – even if they aren’t perfect.

Where repurposing can be a problem is when you lose that embedded functionality that oob objects provide – or worse, it gets in the way of your new object.

Service Requests are a good example. They might look like good candidates for repurposing – they connect to a lot of other record types, and if you aren’t doing a service deployment, what the hey?

But SRs have special Type and Status fields that drive pre-built lists. Status in particular is used in Analytics to do some really nice metrics calculations for you, like SR aging. If you repurpose SRs then you may sacrifice this functionality if you ever need it.

So the net here is use caution when repurposing. Investigate those “special” fields and relationships and analytics tie-ins and make an informed decision.

When to use Custom Objects?

Custom objects are a great choice when you have a business requirement that isn’t represented in the oob object model. For example, let’s say you want to track more detail about customer office sites – beyond just an address.

We really don’t have anything that does that, so you could hook up a custom object.  But just like anything else, you need to know what you are getting. Custom objects are very flexible in how they can link to other objects, but are currently limited to Real-time reporting. Also, you don’t have an infinite number available so you’ll want to make sure you are using them wisely.

As you do your investigation of the object model, you should also consider Vertical Objects. These will need to be provisioned upon request by Oracle Support and, as the name implies, are built with very specific vertical applications in mind – such as financial services, life sciences, and insurance. But you may just find a good match for your needs – again, the key is to do your research!

Wrapping it up

Hopefully we’ve given you some food for thought here – clearly there’s a lot to consider when designing the object model. And of course there is a great reference available in the Deployment Guide (have I mentioned that before?).

Let’s wrap it up with a few “best practice” nuggets:

1.  Don’t get hung up on names: You may call accounts something else or call something else accounts. Match on the functionality and relationships, not the labels. They are easy to change.

2. Think about the relatives: Relationships are everything in data model design. Not just what links you need but also HOW they link – parent-child, many-to-many, extended, etc.

3. Pay close attention to the OOB fields and picklists before you create your own. As we pointed out, some of those have special powers.

4.  Start Simple: Start with the simplest object model design that most closely matches the business need. Layer and expand with care.

5. Plan and document: This should go without saying, but I’m going to say it anyway. Write this stuff down. Spend more time documenting your design and you’ll spend less time fixing it later.

Happy Data Modeling!

Share and Enjoy:
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitter
  • StumbleUpon
  • Technorati

Comments are closed.