|
Oracle Customer Hub (UCM) Master Data Management Reference > Configuring Oracle Customer Hub (UCM) Privacy Management >
Privacy Vocabulary
Oracle Customer Hub (UCM) Privacy Management solution business rules are developed using English language sentences. These sentences are made using concepts (nouns), relations between concepts, phrasing for those relations (verbs, adverbs, adjectives, prepositions and sentence fragments), and table type definitions that have been predefined in the sample knowledge base. These form the conceptual role model. This topic describes the key components of the conceptual role model that you use and customize. The sample knowledge base is named, Siebel_UCM_PrivacyMgmt.akb, and it is in the following directory: Tools/Rule/KnowledgeBase
For more information on customization, see Customization Methods. About the Conceptual Role Model
The sample conceptual role model included with Oracle Customer Hub (UCM) Privacy Management solution was developed using input from several sources:
- Language used in privacy policies across various industries
- Privacy vocabulary research summarized the W3C's Platform for Privacy Preferences (P3P) project
- Terminology used by some U.S. financial services industry customers of Siebel CRM
The conceptual role model is intended to cover a broad set of U.S. financial services requirements as well as be a starting point for privacy-policy management for other industries and geographical areas. You must modify the conceptual role model to support the mapping of additional elements from Oracle Customer Hub (UCM), to customize instances of communication message types. About Entities
Entities are concepts that have attributes. In Oracle Customer Hub (UCM) Privacy Management solution, there are two types of entities:
- Generated entities from Siebel Object Importer. They come directly from definitions in Siebel business components. The main generated entities are: FINCORP Account, FINCORP Account Contact, UCM FINCORP Account Contact Address, UCM FINCORP Account Contact Garage Address Source Data and History, UCM FINCORP Account Contact Privacy, and UCM FINCORP Account Privacy. For more information about these entities, see Siebel Business Rules Administration Guide, version 8.1.
- Abstract entities. They are built on other entities or value concepts for convenience when using the Authority. The abstract entities in Oracle Customer Hub (UCM) Privacy Management solution include:
- Abstract entity-privacy flag. This abstract entity is a named collection of privacy attributes for which an option is selected. The default instances of privacy preferences reflect the standard elections for U.S. financial services companies: affiliate flag, telemarketing flag, nonaffiliate flag, and channel flag for dealer sharing. The privacy preferences can also be mapped to Platform for Privacy Preferences Project (P3P) privacy statements to maintain preferences that are consistent with P3P privacy policies.
- Abstract entity-privacy flag source. This abstract entity is a choice that indicates whether a privacy flag is allowed, denied, or pending, and whether the privacy flag was elected by default or by request based on customer direction. Typically, this entity has the following values: Opt in default, Opt in request, Opt out default, Opt out request, Pending default, and Pending request.
- Abstract entity-state code. This abstract entity indicates which state out of all the states that come with all the financial account contacts on the financial account is the most restrictive state for that financial account. Some states such as California, Puerto Rico, and Vermont increase the privacy regulatory requirements set by the Graham-Leach-Bliley Act (GLBA) or FCRA. They are listed as separate instances. The other states are listed as one generic instance. For any state code other than the fifty states or DC or Puerto Rico, this code is set to XX. Note that XX represents invalid states; that is, state codes that do not apply to the 50 U.S. states, DC, or Puerto Rico. This practice is common for managing U.S. state legislation and policy. For example, a customer can have one of the following practices:
- One state code corresponds to one state.
- One state code corresponds to all states under the same federal law such as GLBA law.
About Value Concepts
Value concepts are created by Siebel Object Importer, using field definitions of the Siebel object model business components. To simplify the handling of strings in tables, string instances generally have the same instance name and string value, by convention. For more information about Siebel Object Importer, see Siebel Business Rules Administration Guide. Relations and Phrasings
Siebel Object Importer can create entity or value concepts, as well as establish the relations between these two and generate simple phrasings such as an entity has a value, and so on. Oracle Customer Hub (UCM) Privacy Management solution also contains a library of privacy-related complicated relations and phrasings. Oracle Customer Hub (UCM) Privacy Tables
The following tables are used in Oracle Customer Hub (UCM) Privacy Management solution.Table 102 shows details of the Privacy Option with Source Ranking table.
Table 102. Privacy Option with Source Ranking
|
Standard Phrasing to Retrieve Values |
|
Privacy option with source hierarchy |
A privacy flag source has a rank |
This table maintains the relative priority of privacy flag sources when rolling up privacy elections to the financial account level. This table uses the entity, privacy flag source, and a manually created integer value concept, rank. NOTE: An opt-out request must always be ranked number 1.
|
Table 103 shows details of the State Code Cover Letter Table and State Code Notice Type table.
Table 103. State Code Cover Letter Table and State Code Notice Type
|
Standard Phrasing to Retrieve Values |
|
CUST.1 Owner type tables |
A state code with an owner type determines whether a cover letter or privacy notice is sent. |
These tables store the cover letter and privacy notice type codes based on the state code and owner type, or communication message type. |
Table 106 Table 104 shows details of the Owner Type State Code Change Cover Letter Table.
Table 104. Owner Type State Code Change Cover Letter Table
|
Standard Phrasing to Retrieve Values |
|
CUST.2 Address changes the tables |
A cover letter type is determined after a second state code changes from a first state code. |
These tables store the cover letter type codes based on the original state code and the new state code. These tables are instances of the same table type. The correct table is selected by the applicability condition on the parent module based on the owner type. |
Table 105 shows details of the State Restrictiveness Ranking Table.
Table 105. State Restrictiveness Ranking Table
|
Standard Phrasing to Retrieve Values |
|
U.S. country rules |
A state has a rank. |
This table ranks states by their restrictiveness and is used to determine which state must be the privacy state code for a financial account when there are multiple states that come with all the financial account contacts on the financial account. |
Table 106 shows details of the Default Privacy for Privacy Flag table.
Table 106. Default Privacy for Privacy Flag
|
Standard Phrasing to Retrieve Values |
|
U.S. FS.1 Default privacy option tables. |
A state determines a privacy flag. |
These tables determine the default privacy flag options for each privacy flag based on the state code. |
|
