Working with Business Units and TableSet Controls

This chapter provides overviews of business units and TableSet controls in PeopleSoft Customer Relationship Management (PeopleSoft CRM) and discusses how to define TableSet controls.

Understanding Business Units in PeopleSoft CRM

This section discusses:

• Business unit structure.

• Uses of business units in PeopleSoft CRM.

Business Unit Structure

A business unit represents an operational entity for an application. The structure of a business unit depends on the requirements of the PeopleSoft CRM application in which the business unit is defined. For example, you might structure a sales organization (and thus the PeopleSoft Sales CRM business units) on region lines but structure a support organization (and thus the PeopleSoft Support CRM business units) around different product lines.

Using business units enables you to group transactions for reporting purposes. Business units do not have predetermined restrictions or requirements. You can define business units to reflect departmental functionality, along product lines, or by location. An entire organization might have only one business unit if every department uses the same processing rules. Diversified companies, such as those that have multiple cost centers, divisions, or subsidiaries, usually have multiple business units.

PeopleSoft does not deliver predefined business units. You decide how to implement business units in PeopleSoft applications to reflect the structure of the enterprise. Business units are usually specific to individual applications: for example, you set up field service business units for the PeopleSoft Field Service application and Sales business units for the PeopleSoft Sales application. However, some applications can share business units. For example, PeopleSoft Support and PeopleSoft Help Desk are both call center applications and can use the same business unit because the nature of their applications is similar.

You can also relate business units across integrated applications. For example, you can associate call center business units with field service business units for service order integration and with sales business units for sales lead integration.

Warning! After you define a structure, you cannot delete a business unit—you can only inactivate it. Before creating and securing business units, think carefully about how you want to set up the organizational structure and about what information you want groups of users to access.

Uses of Business Units in PeopleSoft CRM

Transactional data in PeopleSoft CRM is associated with business units. For example, leads belong to PeopleSoft Sales business units, and service orders belong to PeopleSoft Field Service business units.

Business units can control the following types of processing:

• Business logic.

  Some features are enabled and disabled at the business unit level rather than at the application level. For example, PeopleSoft Field Service enables automatic receiving by business unit.

• Reporting and analysis.

  You can report and summarize information by business unit. For example, several reports that are in PeopleSoft Support and PeopleSoft HelpDesk filter data based on business unit.

• Default values.

  Values often appear by default for every transaction that is associated with a business unit. For example, the currency value appears by default for each Sales business unit.

• Filtering of values for prompt fields.

  Prompt fields on PeopleSoft transactions components are often populated differently based on business unit. For example, in PeopleSoft Support you might set up one business unit to handle software issues and another to handle hardware issues. The values that are available to each business unit for the case type and product fields differ depending on whether the business unit that handles the case is set up for software or hardware cases.

• Security.

  Business units enable you to control row-level security. You can control access to setIDs by user or permission list.

  See Setting System-Wide Security Options.

Use of Business Units by CRM Applications

You can use the same business unit across applications. You create the business unit in one application, then use each application's setup component to associate the business unit with each application that uses the business unit.

See Defining Business Units and TableSet Controls.

See Also

PeopleSoft Integrated FieldService 9.1 PeopleBook

Defining PeopleSoft Marketing Business Units

Defining Call Center Business Units and Display Template Options

Defining Order Capture Business Units

Setting Up Business Units for PeopleSoft Sales

Understanding TableSet Controls in PeopleSoft CRM

This section discusses:

• TableSet control terminology

• TableSet control scenarios

• TableSet control example

TableSet Control Terminology

The TableSet control architecture uses the following terminology:

TableSet

TableSets are groups of control tables that enable you to share the same control values among multiple business units. This reduces data redundancy by enabling multiple business units to access shared information while keeping information such as departments decentralized. You can use business units and TableSets to associate a business unit with individuals in the enterprise or to specify default values for a business unit's transactions.

TableSets also enable you to limit data access by associating the business unit with a list of record groups, each of which is associated with a setID. The setID in turn is associated with one or more values that are in a control table.

SetID

SetIDs are the labels that identify a TableSet. SetID functionality in PeopleSoft CRM provides a higher business level for rollup of business unit data in reports and for other purposes. Just as business units organize the company or organization, setIDs organize data within the system.

Business units are used to group and filter transactions, and setIDs are used to group and filter the setup data. To create logical groupings of values, you associate setIDs with each value.

For example, you might have two call center business units, one for U.S. operations and one for European operations. If you sell different products in the U.S. and Europe, then you use two setIDs with the products: one for U.S. products, and one for European products. You can associate these different product setIDs with the two call center business units to ensure that call center agents in each geographic region see only products that are sold in that region. You can also use setIDs to group the different case types that are handled by the call centers.

Some PeopleSoft tables (control tables and prompt tables) use a setID as a high-level key to identify and retrieve data from system databases. The setID segregates the data in the control tables, which enables many business units to share the same set of data on the physical table in the system by grouping values for filtering purposes.

SetIDs are shared across applications. For example, all PeopleSoft CRM business units have TableSet controls that determine valid products for each business unit. Therefore, when you establish product setIDs, you need to consider how products appear in each PeopleSoft CRM application that you plan to implement.

Control (or Setup) Table

Control tables enable you to establish values for fields that are in transactional pages. For example, the Case Type control table contains all the valid case types. When a support agent opens a case, the Case Types table supplies the list of valid types from which the support agent can select.

Record Group

Record groups contain similar setup tables. For example, some record groups are specific to call center setup tables. There is one record group for the tables that contain problem attributes (case type, category, and so forth), another record group for tables that contain impact attributes (priority and severity), and so on. Additional record groups control setup tables (for example, products and solutions) that are shared with other applications.

Setup components in the same record group must use the same setID for a given business unit. For example, suppose you have two different business units with two different setIDs and you also want to separate case type by setID. Because case type is in record group RC-03 and category, type, and details are also in that record group, you must also assign different setIDs for category, type, and details if you have different setIDs for different case types.

When a record is in a given record group, views that contain the record are also in the record group if the views are keyed by setID. Related language records do not necessarily appear in the record group.

PeopleSoft-delivered setup tables are already organized into record groups. Not all record groups are relevant to all business units. For example, case attribute record groups are relevant to call center business units, but not to sales business units. You can look at the TableSet definition for an existing business unit to see which record groups are used by which application.

TableSet Controls

TableSet controls associate business units with record groups and setIDs. Each business unit has its own TableSet control, which is stored on the TableSet Record Group Control table. You can associate a setID for each individual record group to a business unit.

You can use either a business unit or a setID to set up PeopleSoft CRM TableSet controls. For example, if you are in the product component (in which case, the underlying record is keyed by setID) and you prompt on a field that is also keyed by setID, PeopleTools actually looks for the setID of the prompt record by passing in the product setID.

Note. The pages where you set up and review setIDs, record groups, and TableSet controls are part of PeopleTools. Because PeopleTools supports TableSet controls based on attributes other than business unit, the PeopleTools documentation uses the generic term set control field.

Since PeopleTools doesn't always use business unit, it is important that you set up both the setID and the business unit.

See Also

PeopleTools 8.52: PeopleSoft Application Designer Developer's Guide

PeopleTools 8.52: PeopleSoft Application Designer Lifecycle Management Guide

TableSet Control Scenarios

Not every organization needs to use the more complex TableSet control capabilities. Consider these scenarios as you decide how to use TableSet controls:

• You have only one business unit.

  All of the setup data is valid for that business unit. Therefore, you only need one setID. When you create the business unit, specify this setID as the default. The system creates the TableSet control.

• Multiple business units use all the same setup data.

  All of the setup data is valid for all business units. Therefore, you still only need one setID. When you create business units, specify this setID as the default for all business units, and the system creates TableSet controls.

• Multiple business units use separate sets of setup data.

  In this scenario, you have one set of setup data for each business unit. Therefore, you need one setID per business unit. As you create each business unit, you specify its default setID. Once again, the system creates TableSet controls for you.

• Multiple business units use some shared setup data and some unique setup data.

  This is the only scenario in which you have to configure the TableSet controls. The business units use different setIDs for different record groups, and therefore the default setID is not valid for all record groups. You still specify a default setID when you create each business unit, but you must override the default later.

TableSet Control Example

The following diagram illustrates the most complex TableSet control scenario: multiple business units use some shared setup data and some unique setup data.

The diagram represents the business units and setIDs that are established by an organization with three call center business units, one for its U.S.-based help desk operations, one for its U.S. support operations, and one for its European support operations.

The organization has these requirements for sharing setup data:

• There are two sets of case problem attributes (record group RC_03): one for the two support business units and one for the help desk business unit.

• There is one set of case impact attributes (record group RC_04); all three business units share the values.

• There are two sets of communication channel attributes (record group RC_07): one set for the U.S.-based business units and one for the European business unit.

This diagram illustrates the tables that manage the relationship between business units, record groups, and setIDs:

Business units, SetIDs, and TableSet controls

Business units, SetIDs, and TableSet controls

Notice the following details in the diagram:

• Values that are valid for more than one setID are entered for each setID for which they are valid.

  For example, both the help desk business unit and the support business units have a case type of Problem. The different business units cannot share this value because they are associated with different setIDs. Therefore, the problem case type is set up twice in the Case Type table: once under the HDESK setID, and once under the SUPRT setID.

  Setting up case types is simple, involving only a setID, a unique identifier, and descriptive information. But for more complex setup tables (for example, the product table), duplicate data becomes difficult to maintain. The more complex the setup tables are, the more you have to gain by sharing values across business units.

• The Case Type table is part of the record group for case problem attributes (RC_03). Therefore, the values for all tables that are in the RC_03 record group are split into help desk values (associated with the HDESK setID) and support values (associated with the SUPRT setID).

• The preceding diagram illustrates two different ways of handling setIDs when values are shared by some, but not all, business units:

  • You can have setIDs that correspond to the specific groups of values, as the setup for the record group for case problem attributes (RC_03) illustrates: there is one setID for the support business unit and another setID for the help desk business unit.

  • You can use a general-purpose setID, such as SHARE, for shared values and use other setIDs on an exception basis, as the setup for the communication channels record group (RC_07) illustrates.

• The system uses the default SETID table to determine default values for the setIDs that are associated with each record group in a new business unit. For example, a setID US100 might use US100 for most setIDs but use SHARE for departments. If you define US100 as the default setID for the a new business unit, then the new business unit also uses US100 for all setIDs except departments, for which it uses SHARE.

Defining Business Units and TableSet Controls

To define tablesets, use the TableSet ID (SETID_TABLE) component.

This section provides an overview of the TableSet control setup process and lists the pages used to define TableSet controls.

TableSet Control Setup

When you create a new business unit, the system creates a setID with the same name as the business unit. The newly created TableSet control associates all record groups with that setID. This is a convenient shortcut when you have multiple business units with identical or similar TableSet controls.

This diagram illustrates the TableSet control setup process.

TableSet control setup process

To define a business unit's TableSet control:

1. Create the business unit on the appropriate application-specific page.

   The system creates a default setID corresponding to the business unit name.

   If the business unit uses only its default setID, you are finished; continue to the next step only if the business unit uses setIDs that are other than its defaults.

2. Use the TableSet Control page to create additional setIDs.

3. Use the Record Group page (in the TableSet Control component) to map setIDs to record groups.

If necessary, use the Record Group page (in the Record Group component) to review which records are in each record group.

In addition to setting up business units and setIDs, you must set up appropriate security.

See Setting Up Security and User Preferences.

Note. The pages where you set up and review setIDs, record groups, and TableSet controls are part of PeopleTools. Because PeopleTools supports TableSet controls based on attributes other than business unit, the PeopleTools documentation uses the generic term set control field.

You can use either a business unit or a setID to set up PeopleSoft CRM TableSet controls. For example, if you are in the product component (in which case, the underlying record is keyed by setID) and you prompt on a field that is also keyed by setID, PeopleTools actually looks for the setID of the prompt record by passing in the product setID.

Since PeopleTools doesn't always use business unit, it is important that you set up both the setID and the business unit.

See Also

PeopleTools 8.52: PeopleSoft Application Designer Developer's Guide

PeopleTools 8.52: Getting Started with PeopleTools

Pages Used to Define Business Units and TableSet Controls