Understanding TableSet Controls in PeopleSoft CRM
This topic discusses:
TableSet control terminology
TableSet control scenarios
TableSet control example
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 PeopleTools: Application Designer Developer's Guide and PeopleTools: Application Designer Lifecycle Management Guide.
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.
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:
Image: Business units, SetIDs, and TableSet controls
This diagram illustrates the tables that manage the relationship between business units, record groups, and setIDs.
Image: Business units, SetIDs, and TableSet controls (continued)
This diagram illustrates the tables that manage the relationship between business units, record groups, and setIDs (continued):
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.