Today we introduce our new “Five Things” format for the podcast. Robert and I will discuss five things you need to know about one of our favorite CRM On Demand features – Books of Business. Look for “Five Things” in the title of future podcasts. When you see it, you’ll know you’re going to get some concrete advice that you can put to work right away.

Books were introduced in Release 14 as a flexible way of segmenting data. Really something we didn’t have before in CRM On Demand, and it was a welcome addition. As we talked about previously, Books are flexible containers of data that can be defined as a hierarchy. These can represent anything from geographical territories to product groupings to functional divisions and really just whatever you can think of.

And, as my uncle Ben once told me, with great power comes great responsibility – or something like that. Books are a big topic, but here are five things you really need to know.

1. Know Your Limitations

As Robert’s friend Dirty Harry is fond of saying, a man’s got to know his limitations.

Get educated on the feature. There’s documentation and training available, so do your homework before even deciding that Books of Business are necessary. The forums and My Oracle Support are great resources.

As you do so, keep in mind the limits. Books are great for some things, not so great for others. For example, in the current application Books work a bit differently in Analytics and reporting than they do elsewhere in the UI. If you aren’t sure of the limits, test them yourself – set up a dummy account and play around with it.

2. Plan It!

Failure to plan is a plan to fail, as we all know, so it goes without saying you should devote ample time to planning your Books implementation. Well, I guess we’re saying it anyway.

Books are pretty easy to set up but have a big impact on usability and can be harder to change once deployed. Good planning is the key here. Take the time to plot out your Book structure and validate it BEFORE implementing. Also remember that Books is another maintenance item and will add to your administrative overhead. So be sure to have a good business justification for it.

When planning, recognize that your Book structure should closely reflect how your company organizes data. Pay special attention to cases where: two different departments cannot see each other’s data or two different departments must share each other’s data. Then organize the information based on these hierarchies and assign end users to the relevant books.

Find the patterns - we’re talking about usage patterns here. How do users work? Where do they spend most of their time in the application? Are they constantly searching or do they work against lists? Do they access reporting all the time?

Considering these questions at design-time should inform the Book structure and data shape. For example, if users work against defined lists every day, we should try to define books that capture the data for that list, possibly just a subset of the data a user may have access to.  Putting those records into a Book, with a recognizable name, will improve usability.

3. Keep it simple!

A mantra we come back to again and again here. Sketch out your Book hierarchy then question every layer. Scale down to the simplest, flattest possible structure. Remember that each additional level in the hierarchy can negatively impact performance and usability.

Each user is, in effect, a Book. You can see this visually in the look-in selector. Beware of scenarios that end up replicating these. The down side of creating custom books that look like user books is in their maintenance, added server processing to maintain the synchronization and resulting degradation in data retrieval efficiency.

Resist the urge to over-complexify! Just because you can do it, doesn’t mean it’s a good idea.

While Books can be defined really by any criteria, obviously choose a structure that makes sense for your organization. And think about scale in a couple of ways. First, think about rules that will get you to less than 50,000 or so records per book. That’s a general rule of thumb, not a hard limit. Higher numbers will see a performance slow down in searching and lists. If your books grow to, say, 100k, then it may be time to consider sub-dividing them 

4. Leaf It!

Imagine your Book hierarchy as a tree with several branches. Each ends in a nice green leaf. Maple leaf.

So the leaf is your data. Nice green data. Every other part of your tree is wood. No data. The key here is the “Can Contain Data” checkbox on each Book. If the Book is a branch, DON”T check the box. If it is a leaf, check the box.

This has a very real impact on performance. When you are in a top level Book and run a search or list, the application is going to traverse all the child levels where this box is checked. Imagine the query that gets generated to hit every node up and down a tree structure. So you don’t want a lot of unnecessary time spent in books where there is no data. In line with this, you shouldn’t put data in those branches, just at the end (leaf) nodes.

5. Automate it!

Books have an advantage over other access schemes in the amount of automation that you can employ. One simple mechanism you can use to manage books, often overlooked, is lists. When you create a list of Accounts, Contacts, etc, you’ll find a menu option to Batch Assign Books. This can really come in handy when you’re initially setting up your books or rearranging things

One of the biggest benefits of Books as a segmentation tool is the ability to automate record assignment through workflow scripting. This gives you incredible flexibility and control. Use it

Along with that, keep in mind that workflow rules are based on record attributes (field values). So when you are designing the books, be thinking about what attributes will form the basis for your workflow rules. Again, simplicity is best. If you find that you are relying on numerous fields and combinations to derive the book assignment, consider how you might add a field or flag to simplify assignment.

Think about the number of rules your Book scheme will require. Most companies end up with two rules per book, per record type. So that’s a “new” and “update” rule for Accounts in each book, ditto for Opportunities, etc. Do the math, it can add up quickly! Don’t be scared away by this – but do be aware of it and think about what you can realistically manage

Five things

So there are your five things for today: Know your Limitations, Plan It, Keep it Simple, Leaf It, and Automate It. Now go put that to work!

Share and Enjoy:
  • Digg
  • LinkedIn
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitter
  • StumbleUpon
  • Technorati

Comments are closed.