Print      Open PDF Version of Online Help

Administering Oracle CRM On Demand > User Management and Access Controls > Book Management > About Designing Book Structures

About Designing Book Structures

To set up an efficient book structure, you must plan your book hierarchies carefully. Consider the following guidelines when you design and refine the book hierarchies for your company:

• Do not create custom books that replicate user books.
• Determine the organization and access policies for your business data.
• Determine whether the corporate structure is relevant to data management.
• Determine the data affiliations in your company.
• Design your books based on user needs, and consider the tasks where users most commonly use books.
• Design your books so that the functionality provided by the Manager Visibility Enabled check box on the company profile is used as little as possible.
• Keep the number of levels in your book hierarchies to a minimum.
• As far as possible, reduce the amount of cross-listing in the book structure. Cross-listing is the practice of duplicating records across multiple books.
• Use workflow rules to automate book management. Also, when designing your book names, consider the feature that allows you to use a single workflow action to assign a different book to different records, by using an expression that resolves to a book name.

User Books

The disadvantage of creating custom books that replicate user books is that the data in the custom books and in the default user books must be synchronized. This additional task increases server-processing time, and affects the speed at which records are retrieved.

NOTE: One reason why a company might consider replicating user books is to give a user temporary access to another user’s data. A better way of meeting this need is to add the user who wants to access the data as a delegate for the user who owns the data.

Data Access Needs

Your book structure does not have to reflect your company’s corporate hierarchy. Instead, it is recommended that your book structure should closely reflect how your company organizes its data. Parts of your business can be organized by geography, while other parts can be organized by product line or industry. Pay special attention to cases where:

• Two (or more) departments must not be able access data belonging to the other department
• Two (or more) departments must be able to access data belonging to the other department

Relevance of Corporate Structure

In many companies, a parent organization has complete access to all data in the child organizations. Members of such a parent organization typically have global access to data across all child organizations.

If your organization is structured in this way, it is recommended that you do not to set up books that reflect organizational structure at the parent organization level. However, consider the following:

• Setting up books that reflect the organizational structure at other levels (such as child organization level)
• Setting up other book hierarchies at parent organization level. For example, at parent organization level, you can create a book or book hierarchy that allows users at parent organization level to view opportunities that have significant revenue potential, across all child organizations.

Data Affiliations

Examine the procedures that your company follows when a user transfers from one department to another. For example:

• If the data that the user manages always moves to the new department with the user so that there is continued affiliation of data, it is best to manage your data through record ownership and teams. Typically, appointments and tasks move with the user at all levels. In some sales environments, all customer data moves with the user. This data affiliation is true for small and medium businesses and for businesses that focus on low volume, high-value sales.
• If the data usually stays in a fixed organization, such as a geographical organization, so that there is organizational ownership of data, it is best to manage the data through books that reflect the organizational structure.
• If both continued affiliation and organizational ownership continue to exist for some time after the user moves to another department, the two hierarchies can coexist.

User Needs and Tasks

When designing your book structure, consider the task where users most commonly use books, including working through lists, searching for records, and creating and using reports.

Working Through Lists

To help you to identify the lists that users need, determine the types of lists that are most frequently used, and the ideal lists for your users. Ask the users in your company for input to help you to do this. If no book in your book structure contains all the necessary records for an ideal list, the book structure is probably missing a hierarchy. For example, you can set up both a geographic hierarchy and a product-oriented hierarchy.

If users spend a lot of time working in a specific subset of one book, create a subbook for the subset. Name the subbook in a way that allows users to recognize it. The subbook can also be set as the default for the Book selector, so that users do not have to select the appropriate book every time. For more information about setting the default for the Book selector, see Enabling Books for Users and User Roles.

Searching for Records

To determine the search needs of the users in your company, ask the users about scenarios where they look up particular records. Your book structure and book sizes should reflect the searches and search criteria that users perform most frequently.

NOTE: If you already have a book structure in place, and are further refining it, ask users if they can typically identify that a particular record is part of a particular book in the hierarchy. If the users consistently say that they can be certain only about a book at a higher level, ask them if another subdivision of the book structure would allow them to narrow their search further. Users should be forced to search higher-level books only as an exception to their normal searches.

The fields that are used in a search also affect the speed of the search:

• Using indexed fields to search for records in books results in optimal performance. (Indexed fields are shown in green text in the search sections.)
• When nonindexed fields (rather than indexed fields) are used to search for records in books, searches are slower, and performance is affected by the volume of records that are searched. (Search fields that are not indexed are shown in black text in the search sections.)

For example, if you determine that users typically search contact records based on indexed fields, the number of records for the lowest-level book (called the leaf-node book) might be up to 100,000 for each record type. However, if users typically search contact records based on nonindexed fields, you can restrict the size of your leaf-node books to between 20,000 and 30,000 records for each record type.

Data configuration varies from company to company. As a result, there is no recommended number of records for books. You must manage book size continuously. Books facilitate faster searches by reducing the number of records that are searched.

Creating and Using Reports

All users except administrators are subject to data-visibility rules for reports. When a user book or custom book is specified in the Book selector for reporting, the data considered for the reports is as follows:

• All content in historical analyses (including historical analyses accessed from the Reports and Dashboards tabs, and reports embedded in record Homepages) is restricted to the book and includes all sublevels of the selected book. Records that the user owns, or where the user is a member of a team, are not included unless those records are also in the selected book or one of its subbooks.
• Real-time reporting is restricted to data directly associated with the book (custom book or user book) selected in the Book selector. If the selected book has subbooks or subordinates, the data in the subbooks or subordinates is ignored in real-time reports.

NOTE: Although you do not typically need to change your book structure after you set it up, you can do so. No downtime is required to make such changes, and the changes are applied immediately. However, the changes are not immediately reflected in the data in real-time reports.

For more information about visibility to records in reports, see Reports.

Manager Visibility

When you are designing your book hierarchies, base your designs on the following principles:

• The functionality provided by the Manager Visibility Enabled check box on the company profile is used as little as possible.
• The Include Sub-Items option is seldom or never used in searches of large data volumes. (The number of records that constitutes a large data volume differs from company to company and according to search patterns.)

  There are cases where it is necessary to use the Include Sub-Items option. For example, managers need to run lists on user books that include their subordinates, because their subordinates cannot share data with each other. If the volumes are large, then the search time increases. However, for optimal performance, select the Include Sub-Items option only when necessary.

Hierarchy Levels

Book hierarchies that have large numbers of levels, with records at every level, behave in a similar way to the team functionality where manager visibility is enabled. Such hierarchies perform well with small data sets. However, as data volumes grow, books with fewer levels in the hierarchy (or with no hierarchy levels) perform far better than team functionality.

If one level of your book hierarchy provides no additional value to data security or data organization, merge the redundant book and its subbooks. Ask book users if they can typically identify whether a record is in one subbook or another subbook of the same parent book; if they cannot, it indicates that the best option is to collapse the two subbooks into the parent book.

A simple method of reducing the number of levels in a book hierarchy is to prefix subbooks with the name of the parent book. For example, if you have a subbook called North with a parent book called North America, remove the parent book, and rename the subbook as NA – North.

Cross-Listing

Cross-listing is the practice of duplicating records across multiple books. Cross-listing has an administrative overhead for users, because synchronization is required, resulting in many read-write operations that affect the server's performance. Keep cross-listing to a minimum.

Automated Book Management

Typically, book assignment criteria are mapped to one or more fields in a record type. You can create workflow rules to automatically reorganize the book assignment when one of those fields changes.

For example, if you have a book hierarchy called Territory, you can create a workflow rule to monitor a field in a record type (for example, the Territory field on accounts), and then create an Assign a Book action on the rule to update the Territory book on the record with a new book when the Territory field value on the account changes.

When you design your book names, consider whether you want to use Assign a Book workflow actions in such a way that a single workflow action can assign a different book to different records, based on an expression that resolves to a book name.

For example, assume that you have accounts in North America, and you also have accounts based in EMEA. You might want to set up two separate books for the different locations, and assign the appropriate book to an account depending on the location of the account. To set up this configuration, you can create two books, one named North America and the other named EMEA. You can then create a custom picklist field called Sales Location, with the values North America and EMEA, and add the custom field to the page layout for the Account record type for the appropriate roles. Then, you can create an Assign a Book workflow action that does the following when an account record is updated:

• Evaluates an expression to determine the value that is selected in the Sales Location field on the account record.
• Associates the account record with the book whose name matches the value returned by the expression.

Related Topics

See the following topic for related information:

• Creating Workflow Actions: Assign a Book