Setting Up PeopleSoft Customer Relationship Management Security and User Preferences

This chapter provides an overview of PeopleSoft Enterprise CRM security and discusses how to:

• Set system-wide security options.

• Implement self-service security.

• Define PeopleSoft Enterprise CRM application security.

Understanding PeopleSoft Enterprise CRM Security

This section discusses:

• Security building blocks.

• Security terminology.

• PeopleTools security.

• Application security.

• Distributed security.

Security Building Blocks

This diagram provides an illustration of the different layers of security that are delivered in the PeopleTools and Customer Relationship Management security infrastructure. This chapter will cover each of these security building blocks to assist you in implementing the security needed for your enterprise.

Security building blocks

PeopleTools security controls row-level access to transactions. For example, you would use dataset security to enable a sales representative to see leads as the lead owner, or to enable a sales manager to view leads as manager, and so on.

Application security provides three key elements of CRM security: memberships lists, view lists, and functional options. Membership lists can define the characteristics of one or a group of users (for example, partner users) whose system and data access must be secured. View lists can define the characteristics of one or a group of objects (for example, customers) that a member group has view privileges to. Functional options restrict the user to a set of allowable actions within a secured transaction.

Distributed Security or Delegated administration enables you to set up administrators that are external to your enterprise so they can give other users system access, within the confines of the permissions that you allow the administrator to grant.

Security Terminology

Before you can fully enable security, you must understand the security terms and functions at each level of the system:

PeopleTools Security

Use PeopleTools security to define roles and permissions. PeopleSoft delivers a set of roles out of the box that you can use to set up role-based access to PeopleSoft transactions. PeopleSoft provides a recommended set of roles and permissions with each of the products delivered. You can add or modify new or existing roles and permissions to fit your business requirements.

This section discusses

• Portal registry.

• Roles and permission lists.

• Dataset security.

• Business unit row level security options.

• Preferred markets and security.

Portal Registry

The portal registry is a set of dedicated PeopleSoft database tables that store every content reference, typically a URL, available through the portal. A portal registry has a tree-like structure in which content references are organized, classified, and registered. A portal registry contains folders and content references. Folders group and organize content references into a multilevel hierarchy. Except for the root folder, each folder has a parent folder, and each folder can contain content references as well as other folders. Content references are objects that have been registered in the portal registry.

There are several ways to access and maintain the portal registry:

• Use the registration wizard to register content references, assign security, and update.

• Use the Menu Import feature to upgrade custom menu group definitions.

• Use portal administration pages to add, change, or delete folders and content references from a portal registry.

• Use the portal registry application programming interface (API) for programmatic access to the registry.

• Use the security synchronization process to update the portal registry security based on the menu and script security.

  See Enterprise PeopleTools 8.45 PeopleBook: Internet Technology

Roles and Permission Lists

Permission lists are the building blocks of user security authorizations. You typically create permission lists before you create user profiles and roles. When defining permission lists, however, consider the roles and user profiles that you will use them with. Recall that roles are intermediary objects between permission lists and users. You use roles to assign permissions to users dynamically. Permission lists may contain any number of permissions, such as sign-in times, page permissions, and component interface permissions. Permission lists are more flexible and scalable when they contain fewer permissions.

Dataset Security

Dataset security controls row-level access to transactions. Dataset security is achieved by associating the definition of a dataset to the search definition for transactions that have multiple dataset rules. PeopleSoft dataset security framework may be used to build dataset rules and assign the dataset rules to PeopleTools roles.

PeopleSoft delivers a set of dataset security rules that may be used to secure transaction rows. PeopleSoft Enterprise CRM uses dataset security for data searches to restrict transaction rows.

It is also used in these applications and functions:

• PeopleSoft Sales and Mobile Sales (leads and opportunities).

• PeopleSoft Order Capture and Mobile Order Capture (quotes and orders).

• PeopleSoft Mobile Field Service.

• Calendar and Task Management.

• PeopleSoft Wealth Management.

• PeopleSoft Marketing (audience and marketing programs).

• PeopleSoft Partner Relationship Manager.

Business Unit Row-Level Security Options

You can implement security to prevent individual users or roles from accessing specific rows of data that are controlled by key fields. Likewise, you can restrict users so that they can access only a specific subset of rows. For example, you might set the user ID security for a call center agent in Paris so that the agent can access only the data that is for a particular European business unit. If you have a team of call center agents in Paris, you could add them all to a role and then use role security to give them all the same access to the system.

A user can belong to multiple roles and use the menu items that are assigned to all of those roles.

Note. You cannot define row-level security attributes by combining roles. In PeopleTools, you designate row-level security for a user by selecting a row-level security role. The row-level security attributes for the role that you select become the security attributes for the user.

This table describes the consequences of row-level security when you use different combinations of system security options and roles:

You must define the users or roles that have access to specific business units and setIDs. For example, you might give a particular role access to only one business unit. When a user in the role enters prompts for business units (for example, when entering data that has business unit as the primary key), the available selections include only the business units for which the user has been granted authority. The user's available data has been filtered through one or more levels of security.

The number of users that are assigned the same level of security is a key factor in determining whether you base security on user IDs or roles. If a large number of users have identical access requirements, consider using roles. By assigning the users to a single role, you can make subsequent changes to access requirements once rather than many times.

Preferred Markets and Security

The preferred market that is associated with a user ID controls the data and functions that a user can access. Preferred markets are of two types: industry and geographic.

If a user's preferred market is geographic, the user can only access functionality and data that are valid for business units in the geographic region or country. For example, a country might require certain information about imports that users in another country would not need to enter.

If the user's preferred market is by industry, the user is granted access to only the functionality and data that are implemented for those industries. For example, when financial market users define companies, they can specify financial account and contract data.

See Defining Overall Preferences.

See Also

Enterprise PeopleTools 8.45 PeopleBook: Internet Technology, “Understanding Portal Technology”

Enterprise PeopleTools 8.45 PeopleBook: Security Administration

Application Security

This section discusses:

• Enterprise administration.

• CRM application security terminology.

• Application security framework.

• Security objects.

• Dynamic and static membership lists.

• Dynamic and static view lists.

• Implicit view lists.

• Functional options.

• Functional option groups.

• Functional options conflict resolution.

• Enabling functional options.

• Business object search system processing.

• Financial services industry security.

• Catalog security.

• How security is processed at runtime.

Enterprise Administration

Application Security consists of three main pieces: membership lists, view lists and functional options. Using PeopleSoft Enterprise CRM application security, enterprise administrators have the ability to:

• Define the community of participants for which security is restricted (membership list)

• Define a group or specific list of objects (for example customers) that a partner is allowed to view and transact with (view list).

• Define a set of business processes or actions that a participant in the membership group can perform (for example, what a partner can do).

CRM Application Security Terminology

This table lists terms related to security:

PeopleSoft Enterprise CRM Application Security Framework

PeopleSoft Enterprise CRM application security framework is a characteristic-based security framework that enables PeopleSoft customers to secure data and functions within a transaction.

For example, suppose you have a group of partner insurance agents that need access to a specific group of customers and you want this group of partners to only generate quotes, submit policy applications, and add customer addresses. Using the pages within the PeopleSoft Application Security component, you can create the security objects, lists, and profiles that you need to secure your PeopleSoft Enterprise CRM applications to accommodate this situation.

Use PeopleSoft application security to abstract partners and customers as security objects. The characteristics that define the group of partners or customers are called lists.

You can predefine the objects and lists as either membership or view to differentiate viewers (partners who are members with a security profile that have access to specific objects and data) from the target transactions or data objects (which can be customers that are secured within the partner's view privileges).

Note. Application security is used only to secure objects (person, partner, customer, financial accounts, product catalog, hold codes, performance metrics, and so on) and not transactions (orders, leads, opportunities, cases, and so on). Objects in this context mean setup data or data that is used to create a transaction.

Application security involves setting up and defining:

• Membership lists

  Membership lists define the characteristics of one or a group of users (for example, partner users) to whom system and data access and functional permissions and privileges are granted. Users in a security membership list definition are associated with a security profile.

• View lists

  View lists define the characteristics of the viewing object (for example, customers, accounts, product catalogs) that are secured from the membership list.

• Functional options

  Functional options define the functions (for example, order submission) that can be carried out by members of a membership list.

• Security profiles

  Security profiles define the combination of view lists and functional options that make up a specific profile of view and function access. Security profiles are given to members belonging to a membership list.

This illustration represents a high-level view of a security profile using PeopleSoft Enterprise CRM Application Security.

Security profile definition

Security Objects

PeopleSoft delivers a number of security objects that you can use to implement security. You should not, however, change them in any way. Any changes that you make to the security objects delivered by PeopleSoft impact the security profiles and the security list tables. PeopleSoft recommends that you limit the number of security objects that you create and are careful how you use them.

PeopleSoft delivers these membership type security objects out of the box:

Dynamic and Static Membership Lists

A dynamic membership list is a saved query of characteristics that result in a list of members for a membership list object. The queries are saved using the dynamic criteria definition that is linked to the membership list object.

If the domain type is dynamic, you can edit the membership criteria using the appropriate dynamic criteria definition. You can also view the results of the membership list.

You may associate the membership list to any security profile currently available in the system. Once you associated the membership list with a security profile, that security profile appears in the security profile list for the membership list. When needed, you can remove the association of the membership list to the security profile.

Static membership lists contain a specific list of members that you may associate with any security profile currently available in the system.

Dynamic and Static View Lists

A dynamic view list is a saved query of characteristics that results in a viewable list of objects. You set up a view list object similar to the way you set up a membership list object. After you establish a view list, you may grant one or more view list objects (dynamic or static) to a security profile.

Note. Not all objects can be used as view list objects.

View List Security Objects that are delivered as system data:

Implicit View Lists

A dynamically defined view list can contain a bind variable or a criteria that is not resolved at the time of creation of the query but is resolved at runtime This is called an implicit view list.

A business scenario that is supported by implicit views lists would enable partners to view customers with whom they have previously done business with, where orders have been submitted with the partner identified.

For example, ABC Insurance (ABC1), during the creation of a home insurance policy, wants to use quick create to enter a new customer called John Smith (JS1). From this point onwards ABC Insurance would want to have access to John Smith's information.

If ABC Insurance (ABC1) creates an auto insurance policy, they would want access to John Smith (JS1) in the lookup table. The presence of both the partner (ABC Insurance) and the customer (John Smith) on the same transaction enables future partner access to that customer.

To create an implicit view list that would give ABC Insurance access to John Smith's account information, you would create a dynamic view list by selecting the bind search criteria for the Partner on Order field and then selecting Partner.

When you associate an implicit view list to a security profile and run the list refresh process, the system creates a new security profile for each member of the membership list that is associated to that security profile.

To set up an implicit view list, you must use the Configurable Search Setup - Search Fields page to select the bind variable for the security components and fields that you want to use on the Add View List or Add Membership List pages.

You can modify the Customer Search (RSEC_CUSTOMER_SRCH) component to use bind variables and create implicit view lists.

See Configuring Search Pages.

Functional Options

Functional options are defined independently of security objects and domains. Functional options let you determine what a user you can do within an application. For example, you can create functional options that enable users to submit orders or add new customers. To group view lists and functional options, you define a security profile. The security profile is then granted or associated to one or multiple membership lists.

Functional Option Groups

Functional option group is a grouping of functional options, which you can be associated with a security profile. Using functional option groups can make maintaining security profiles easier and more efficient. Enterprise administrators that must make wholesale changes to security profiles can simply change the functional option group associated with the security profiles that must be changed or updated.

Example:

In the world of financial services you have consumer account holders. All consumers by default get a functional option group that enables them to withdraw money up to 200 USD from an ATM, transfer balances and so on. At the same time there is also a special consumer called Don Smith whose account number is 123456. Account 123456 is in a view list that is associated to Don's security profile. On this account you can create a specific functional option called Withdraw Money and let him withdraw money up to 300 USD. The general functional option group gives him default access to a group of functional options. But the specific functional option can be applied on his account by attaching a view list to his security profile. Based on the conflict resolution that is set up to override the first optional group, he can withdraw 300 USD from the ATM.

Functional Option Codes

Functional options enable the enterprise administrator to define the functions that users can access within a transaction. Functional options codes are evaluated at run time by the transaction that is evaluating the functional option.

PeopleSoft delivers these functional options codes out of the box when you install and implement PeopleSoft Enterprise CRM:

Functional Options Conflict Resolution

Conflicts can happen due to the granting of the same functional options within a single security profile or multiple security profiles. To resolve conflicts the system uses these rules:

• If one functional option group grants an option and another revokes it, the revoke takes precedence. If the options are not in the same scenario, the option is granted. Revoke is for the functional option itself. (for example, do you have authorization for transfer money). If one functional option group says yes and another no, conflicts are resolved based on how the revoke options are set up.

• For amounts there is a conflict resolution called max amount wins. This means that if one functional option group gives a user access to 2000 USD and another functional option group give a user access to 3000 USD, and the max amount win option is selected, the user gets access to 3000 USD.

Here are two scenarios and the resolution mechanisms that are used to resolve the conflicts originating in the functional options:

1. Single Security Profile Functional Option Conflict Resolution:

   • Bob is a financial account holder with the account number of 2001.

   • Bob is associated with a single security profile (PROFILE_1).

   • The security profile is associated with a functional option that allows him to transfer money up to 300 USD.

   • Bob's account (2001) allows him transfer money up to 1000 USD.

   • The conflict resolution option on the Transfer Money functional option is set for maximum amount always to win.

   • Resolution: Bob can transfer up to 1000 USD.

2. Multiple Security Profile Functional Option Conflict Resolution:

   • ABC Warehouse is a partner to the enterprise.

   • ABC Warehouse is explicitly associated to a security profile (PROFILE_2) either through a dynamic membership list domain or a static membership list domain.

   • There is also a generic security membership list for all partners (PROFILE_1), which means it includes the Partner ABC Warehouse.

   • There are no functional options attached to the view list for both security profiles.

   • For PROFILE_1, the administrator has specified functional options so that users can submit orders for amounts up to 5,000 USD.

     The ability to add addresses has been revoked.

   • For PROFILE_2, the administrator has specified functional options so that users can submit orders for amounts up to 10,000 USD.

     The ability to add addresses has been granted.

   • The conflict resolution option on the Order Submit functional option is set for the maximum amount always to win.

     The Add Address functional option is set so that the revoke option does not win.

   • Resolution: The ABC Warehouse Partner can submit orders up to 10,000 USD and add addresses.

Enabling Functional Options

The display template framework allows you to configure functional option security for your pages. By referencing the functional option on a button or field within the display template, the functional option security is enabled.

See Configuring Display Templates.

Business Object Search System Processing

The transaction adapter determines, based on the transaction, what fields appear on the customer information subpage and the criteria definition that defines the advanced search page. The criteria definition determines what criteria fields appear on the advanced search page, how they appear, and the search definitions to invoke.

The search definition determines the roles to search for the criteria fields, the fields that appear in the search results, how the search results appear, and the quick create definition that the user accesses to create a new business object.

For each role that is searched, the search role determines the security that is applied, the relationships for the role, and whether fields appear in the search criteria or results set for the role. The field definitions determine how the search fields appear on the page, the database records that are searched for each field, and how the user can search for the field.

See Adding and Modifying BO Search and Quick Create Definitions.

Financial Services Industry Security

Access to plans and templates is secured by dataset rules. Once a plan or template is activated, no further changes can be made in the active status. Edit control security limits edit privileges to designated individuals who can change the status from active to draft status and make modifications.

To ensure consistency between account plans, account managers define account planning templates containing a default set of objectives and goals. They can attach a list of template editors who have security access to make changes and activate a template. Once a template has been moved from draft to active, and its date range is active, account managers can begin creating account plans from a template. Tasks can be attached to an account plan. These tasks appear when you view the tasks for the associated company.

A plan has two types of application security in addition to the PeopleTools security using the permission list. The row level application security is implemented by using dataset rules. Plan edit control security ensures that the user has been granted appropriate access before any status changes can be made to the plan.

With PeopleTools role security, when a user requests access to a page, the system checks the role of the user, and then checks the permission list belonging to the role to decide if the user can access the page. Certain component items can also be disabled by using the navigation security feature. Throughout the application, certain security measures target two roles: Administrator and Agent. If you define your own PeopleTools roles, you must map the roles with either the Administrator or Agent role to get the security features for the new roles.

See Defining and Maintaining Security.

Catalog Security

Catalogs are a single group of products or services that are marketed and displayed together because they share common criteria. PeopleSoft enables you to define the layout and content of online catalogs for internal and external use. You define the look and feel of catalogs by creating display templates, and then define the contents that you want to organize and present according to your template definitions. You can designate products for inclusion in a catalog either by direct association (using product IDs) or by creating business rules to dynamically build product content based on the selection criteria that you define. Similarly, you can control user access to catalogs by associating a Security Membership List with specific catalogs.

Security Memberships allow you to specify which users or groups of users can have access to certain catalogs. For example, a company can have a Membership List called All Persons that includes all of the people that have a person record in the system. This Membership List is then associated with a catalog.

This means that all of the people on this list can view this catalog. If a catalog called the Premier Catalog was for Premier Customers, a company can create a Membership List that contains all of their Premier Customers and the Premier Catalog would provide special pricing and recommendations for this group of users.

See Defining Catalog Content and Permissions.

How Security Information is Processed at Runtime

PeopleSoft Enterprise CRM application security uses several Application Engines and APIs (application programming interfaces) at runtime to help ensure that the customers and partners to whom you have granted security have access to the correct information and customers.

Here are the elements of runtime security that are activated when a partner, user, or customer attempts to access the PeopleSoft Enterprise CRM applications that you have secured.

• Application Engines

  • RSEC_DAEMON

    Polls for application updates (for example, when a customer is added or updated) and triggers the RSEC_BUILDER

  • RSEC_BUILDER

    Handles the writing of secure objects to list tables.

• Runtime API

  • Determines security memberships and view lists.

  • Generate SQL filters for calling applications

  • Determines functional options, and functional option resolution.

• Definitional API

  Provides application programming interface to add and update security framework metadata.

PeopleCode Application Classes and SQL views provide the API to the security framework. This API is provided for impacted applications to access and update the application security framework. The API is used at runtime to evaluate membership and view privilege result sets, but there are some access methods that are provided to update the framework keys, membership, and view privilege tables directly. The API encapsulates all functionality and structure related to the security framework, so that calling applications do not need to understand the inner workings of the framework.

These access methods are an overview of how each of the impacted applications requirements are satisfied through the API.

• API Based Direct Data Access

  This access method is provided for instances where the membership tables contain all of the relevant data for the calling application. This method produces a result rowset based on the underlying security object definition. In this usage there are three known values and one unknown value. The three known values consist of a membership security object type, a view list object type, and either a membership object ID, and or a view list membership object ID. Based on the ID that is provided, the API determines the security profiles that are associated to the known entity, and from the profiles determines the data that is to be provided as a result set. The API returns this data in a rowset based on the security object’s list record.

• API Based SQL Data Access

  This access method is provided for instances when the results in the membership table need to be merged or joined in a larger SQL statement that is being constructed by the calling application. The known values and the method of data retrieval are the same as the direct data access method, the result of this call is a SQL select statement that returns the keys of the rows of the security object’s table. This SQL statement can be used in a SQL IN clause or correlated sub query to limit the results of the calling application’s constructed query.

• SQL/Query Based Data Access

  There may be instances in which the API cannot be used. An example of this is any time where the logic to determine a result set does not have the ability to run a PeopleCode based API, such as a standard PeopleTools prompt, a view, or a PeopleTools query. For these use cases the design provides example SQL that can be used to join the security data model.

• Functional option Conflict Resolution

  In instances where a key resolves the same functional option multiple times with different properties, the conflict needs to be resolved. Gathering the functional options and privilege overrides is possible using a SQL UNION, but the resolution of the rules is not possible within a single SQL select statement. This requires impacted applications to be in an environment where it is possible to run PeopleCode to determine the applicable functional options. Because of this functional options are not be determined or executed in a view or query type access method.

• Executing Functional Options

  An abstract class/interface is provided to model functional option classes. This class is used by the runtime application to run the functional option logic. The runtime class provides access to the logic that is relevant to the application and coded in the attached application class. The class also provides the ability to access the functional option amount value, operator, base currency, and perform currency conversion if required. The runtime API provide a method to pass multiple functional option codes, and execute them. A calling application’s framework could leverage this to provide data driven execution.

• Update to Data Cache

  Applications that are responsible for the security objects’ secured data require access to update the security cache when a change is made. Since it is possible that a configurable search definition references any data for a given object, all additions and updates to these objects trigger a cache refresh. The known values in this case are the security object type, and security object ID. The API triggers the data caching process providing the known values as parameters. These parameters trigger the caching process to deal only with data that is relevant (for example, the specific object ID).

• Update to Security Framework

  This access method is provided for instances where it is required to update the security framework data directly in a batch or EIP type mode. The API provides access to create membership, view privilege, functional option, and security key objects. The system provides methods to create the associations between the various security objects, and keys. Security Object types (for example, partners and customers) cannot be created through the API. Since there is not a lot of business logic tied to the security setup components, the API uses SQL objects to update the framework tables directly rather than building component interfaces.

Note. To improve runtime performance, the result sets for static and dynamic membership and view privilege domains are cached into database list tables. Dynamic implicit domains are cached by spawning security keys for each member in the domain. An Application Engine process provides the mechanism for creating the cache tables that store the membership and view privilege lists.

Distributed Security

This section discusses:

• Delegated administration.

• Role can grant hierarchies.

• Creating security groups.

Delegated Administration

Distributed security, or delegated administration, is the ability to securely delegate administrative responsibility to multiple administrators and managers in an organization (within or external to the enterprise). If you have a large number of partners and high turnover among partner users that you don’t manage directly, it is very time consuming to keep track of partner user IDs and access in a centralized administrative function. Delegated administration enables you to set up partner administrators so that they can keep track of partner user access, within the confines of the permissions that you allow the partner administrator to grant

Role Can Grant Hierarchies

PeopleSoft delivers roles within PeopleTools that give administrators the ability to grant roles to other users in a logical way that represents a hierarchy. For example, when the enterprise administrator and the partner administrator are setting up partner users, they can only grant roles for which they are authorized. Partner administrators, in turn, can access the partner organization tree (sales territory tree), define the partner organization, and create partner users only using roles that the partner administrator can grant.

Creating Security User Groups

PeopleSoft Partner Relationship Management (PRM) supports the use of a territory tree for partners. In distributed security, territory trees are referred to as user groups.

An enterprise can implement user groups in PeopleSoft Partner Relationship Management to set boundaries and limits around what partners can do with territory configuration. A partner manager or partner administrator can modify their own territories to show only their own partner nodes and add and delete individual partner representatives to different nodes of a territory tree managed by the partner administrator.

To implement security user groups, an enterprise completes these setup tasks:

• The enterprise administrator creates the partner territory tree initially.

• For partner organization, the enterprise administrator creates a user group.

  For example, you may create a user group called Channel to hold all channel partners and add the enterprise channel manager as primary owner of the user group.

• The enterprise channel manager creates a user group.

  For example, you may create a user group called ABC Warehouse with the IBM Channel user group as the parent for the partner company IBM. In addition, you create a partner administrator called Sally Smith as the owner. On completion of the task, the system sends an email notification to the Sally Smith, the partner administrator.

See Also

PeopleSoft Enterprise CRM Partner Relationship Management 8.9 PeopleBook, “Defining Partner Registration”

Enterprise PeopleTools 8.45 PeopleBook: Security Administration, “Understanding PeopleSoft Security”

Setting System-Wide Security Options

To setup system-wide security options, use these components

• Security Options (SECURITY_OPTIONS).

• Security View Names (SECURITY_VIEW_NAMES).

• Apply Security (APPLY_SECURITY).

• Security SetID Class (SEC_SETID_CLS).

• Security SetID Operator (SEC_SETID_OPR)

• Security Business Unit Class (SEC_BU_CLS)

• Security Business Unit Operator (SEC_BU_OPR)

• Operator Defaults (OPR_DEFAULT)

• Role Worker (RB_ROLE_WORKER).

• Security Views (SECURITY_VIEWS)

This section provides overviews of row-level security views, sensitive worker information, and predefined security roles and sample users and discusses how to:

• Select system-wide security options.

• Activate security options.

• Define view security.

• Define business unit security by permission list.

• Define business unit security by user ID.

• Define tableset security by permission list.

• Define tableset security by user ID.

• Define overall preferences.

• Define call center preferences.

• Define sales preferences.

• Define change management preferences.

• Define account preferences.

• Define roles with access to sensitive worker information.

Understanding Row-Level Security Views

Business units and setIDs are maintained in edit tables and can be used as primary keys throughout the system. When a field uses an edit table to select values, you are limited to the values that are defined for the edit table. With PeopleSoft row-level application security, you can specify which values in the edit table are available in a particular view.

Views enable you to access data horizontally for multiple tables. Views are Structured Query Language (SQL) statements that filter out data rows. Users with permission to access particular setIDs or business units see only a subset of the values in the edit tables.

After you set up views, you can specify which users or roles can access the pages that contain secured field values. Within each page, you can also hide specific fields from particular roles.

Security View Names

PeopleSoft delivers applications with security views that apply to key fields in the system. You can alter these views or build views of your own. View names include suffixes that reflect the type of security for the view. This table lists the view name suffixes and describes the corresponding security type.

Row-Level Security for Users

After you select security options and set up security view names, define the security-controlled field values that each user or permission list can access. When you secure key fields in the application, the pages that you use depend on the level of system security that you select. If you select user-level security, use the user security pages. If you select role-level security, use the permission list security pages.

Understanding Sensitive Worker Information

PeopleSoft uses enterprise integration points to transmit worker data from PeopleSoft Human Resources Management (PeopleSoft HRMS) to PeopleSoft Enterprise CRM. Most of the data that PeopleSoft Enterprise CRM subscribes to from PeopleSoft HRMS is sensitive.

Some users, however, should not have access to this data. To give users access to sensitive and semi-sensitive data, you must select the roles that are associated with the users and then indicate what type of information is available to them—either confidential or home contact information.

Users who have sensitive (confidential) data access defined in the Secured Worker Role setup page, can view date of birth, age, national ID, gender, and employee status fields in the Worker component; otherwise, the system hides this information. Users who have semi-sensitive data (home contact) access can view home address, home phone, home email, and home pager fields for a worker.

If a role doesn't have access to sensitive or semi-sensitive data, then all users belonging to the role cannot view the associated fields on the pages in the Worker component.

Warning! When users have access to sensitive or semi-sensitive data, the system enables them to edit some pages. If a user modifies a field in PeopleSoft Enterprise CRM, the changes could be overwritten the next time that a PeopleSoft HRMS message is transmitted to PeopleSoft Enterprise CRM because the information comes to PeopleSoft Enterprise CRM through a one-way transmission from PeopleSoft HRMS.

See Also

Workforce Management

Predefined Security Roles and Sample Users

PeopleSoft provides several roles with predefined user profiles and permission lists in the demonstration database. You can use these sample security configurations as they are delivered, or you can modify them to meet your specific security requirements. The roles and permissions are part of the system data, and the users are part of the sample data delivered in the demonstration database.

This section discusses:

• PeopleSoft Enterprise CRM system IDs.

• PeopleSoft HelpDesk and PeopleSoft Support user IDs.

• PeopleSoft Integrated FieldService user IDs.

• PeopleSoft financial services industry user IDs.

• PeopleSoft communication industry user IDs.

• PeopleSoft high tech industry user IDs

• PeopleSoft government industry user IDs

• PeopleSoft Marketing user IDs.

• PeopleSoft Sales user IDs.

• PeopleSoft Order Capture and Services Management user IDs.

• PeopleSoft Order Capture Self Service user IDs.

• PeopleSoft Real-Time Advisor user IDs.

• PeopleSoft Quality user IDs.

• PeopleSoft insurance industry user IDs.

• PeopleSoft energy industry user IDs.

• PeopleSoft multichannel applications user IDs.

• PeopleSoft Partner Relationship Management user IDs.

• PeopleSoft Strategic Account Planning user IDs.

• PeopleSoft Wealth Management user IDs.

PeopleSoft Enterprise CRM System IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Enterprise CRM:

PeopleSoft HelpDesk and PeopleSoft Support User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft HelpDesk and PeopleSoft Support:

PeopleSoft Integrated FieldService User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Integrated FieldService:

PeopleSoft Financial Industry User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Financial Services:

PeopleSoft Communication Industry User IDs

This table lists the predefined user IDs, passwords, and associated roles for the PeopleSoft communication industry

PeopleSoft High Tech Industry User IDs

This table lists the predefined user IDs, passwords, and associated roles for the PeopleSoft high technology industry.

PeopleSoft Government Industry User IDs

This table lists the predefined user IDs, passwords, and associated roles for the PeopleSoft government industry.

PeopleSoft Marketing User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Marketing:

PeopleSoft Sales User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Sales:

PeopleSoft Order Capture and Services Management User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Order Capture and Services Management:

PeopleSoft Order Capture Self Service User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Order Capture Self Service:

PeopleSoft Real-Time Advisor User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Real-Time Advisor:

PeopleSoft Quality User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft Quality:

PeopleSoft Insurance Industry User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft insurance industry:

PeopleSoft Energy Industry User IDs

This table lists the predefined user IDs, passwords, and associated roles for PeopleSoft energy industry:

PeopleSoft Multichannel Applications User IDs

This table lists the predefined user IDs, passwords, and associated roles for users implementing PeopleSoft multichannel applications:

PeopleSoft Partner Relationship Management User IDs

This table lists the predefined user IDs, passwords, and associated roles for users implementing PeopleSoft Partner Relationship Management:

PeopleSoft Strategic Account Planning User IDs

This table lists the predefined user IDs, passwords, and associated roles for users implementing PeopleSoft Strategic Account Planning:

PeopleSoft Wealth Management User IDs

This table lists the predefined user IDs, passwords, and associated roles for users implementing PeopleSoft Wealth Management:

Pages Used to Set System-Wide Security Options

Selecting System-Wide Security Options

Access the Security Options page.

Type of Security

Secured Fields

Activating Security Options

Access the Apply Security page.

Select the language that you are using to apply security and then click Run to load the security views that you created.

Defining View Security

Access the Security View Names page.

Search Text

Displays the view name prefixes supplied by each application. When you run the Apply Security Setups process, the system searches for view names that begin with these prefixes. If a view name begins with a prefix from this list, the process changes the view name extension to match the security type that you selected in the security options. The system stores the list in the SEC_VIEW_NAMES table, where you can review or update this information. You can also configure new security views for the system on this page. Note. There is no need to access this page unless you want to implement customized security views.

Type

Select the type of field (setID or business unit) that the security view affects.

Defining Business Unit Security by Permission List

Access the Business Unit Security by Permission List page.

Select the business units to which you want the permission list to have access.

Defining Business Unit Security by User ID

Access the Business Unit Security by User ID page.

Select the business units to which you want the user ID to have access.

Defining TableSet Security by Permission List

Access the TableSet Security by Permission List page.

Select the setIDs to which you want the permission list to have access.

Defining TableSet Security by User ID

Access the TableSet Security by User ID page.

Select the setIDs to which you want the user ID to have access.

Defining Overall Preferences

Access the Overall Preferences page.

Note. User preferences are associated with user IDs. When you create user IDs for implementation team members and PeopleSoft users, define preferences for each user.

See Also

Setting Up Alternate Characters

Setting Up PeopleSoft Mobile Order Capture

Defining Call Center Preferences

Access the Call Center page.

Business Unit Defaults

Frequently Used Solution

See Also

Defining Call Center Business Units and Display Template Options

Defining Sales Preferences

Access the Sales page.

Sales Defaults

See Also

Setting Up Sales Security and Personalization

Defining Change Management Preferences

Access the Change Management page.

Select the values that you want the system to appear by default for the user on to the Change Request page in PeopleSoft HelpDesk.

See Also

Using Change Management

Defining Account Preferences

Access the Account page.

Select the values that you want the system to use when it assigns accounts to the user.

See Also

PeopleSoft Enterprise Bill Presentation and Account Management 8.9 PeopleBook

Defining Roles with Access to Sensitive Worker Information

Access the Secured Worker Role page.

Role Access to Data

See Also

Defining EIP Options for Integration to PeopleSoft HRMS

Implementing Self-Service Security

To implement self-service security, use the Security Privilege (RB_SRTY_PRIV_DELTA), Guest Registration (RX_GUEST_REG_TMPLT), Customer Registration (RX_CUST_REG_TABLE), Representative Registration Table (RX_REP_REG_TABLE), Security Privilege (RB_SRTY_PRIV), and Registration Text Setup (RX_REGTXT_SETUP), components.

This section provides overviews of privilege codes and custom privilege codes and discusses how to:

• Establish privilege codes and custom privilege codes.

• Assign privileges to users.

• Assign privileges to roles.

• Set up existing customer user registration templates.

• Register business users.

• Set up guest users.

• Set up terms and conditions for self-service users.

• Set up terms of service for self-service users.

• Set up privacy policies for self-service users.

Understanding Privileges Codes

The self-service functionality within PeopleSoft Enterprise CRM applications includes a predefined set of privilege codes. Assign these privilege codes to users or roles to provide security for particular types of transactions, as defined in the usage column in this table:

Understanding Custom Privilege Codes

You can define your own privilege codes and associate them with transactions on the User Privileges page and Role Privileges page. After you define the privilege codes, you must add the custom code to the transaction that has the custom security level.

To define a privilege code that prevents consumers from ordering more than 100,000 USD worth of goods:

1. Define the Order Amount privilege code (CUSTORDAMT).

2. On the Role Privileges page, assign the privilege code to the individual consumer role and specify that the amount must be less than 100,000 USD.

3. On the FieldChange event of the Order Submit button, add the following code:

   Declare Function IsTransactionAuthorized PeopleCode FUNCLIB_RB.SRTY_PRIV_CD Field?
   Formula;
   
   Local number &output_msg_set_nbr, &output_msg_nbr;
   
   If Not IsTransactionAuthorized(&roleType, &strPersonID, &numBOIDCustomer,?
    ?CUSTORDAMT?, &numAmount, &output_operator_cd , &output_amount_qty ,  &output_msg_?
   set_nbr, &output_msg_nbr) Then
      If All(&output_msg_set_nbr, &output_msg_nbr) Then
         Error MsgGet(&output_msg_set_nbr, &output_msg_nbr, "Message Not Found.");
      End-If;
   End-If;

In the preceding code example, pass &roleType as 9 (the Individual Consumer role). Pass &strPersonId as the person ID, and pass &numBOIDCustomer as the customer's business object ID. The privilege code is CUSTORDAMT, which is your defined custom privilege code. &numAmount is the amount of the customer's order. The remaining parameters are output parameters that you do not need to pass.

Use the delivered PeopleSoft Enterprise CRM self-service code as an example to customize security of other transactions.

Pages Used to Implement Self-Service Security

Establishing Privilege Codes and Custom Privilege Codes

Access the Security Privilege Code Setup page.

Enter a description of the privilege code that you are adding.

Assigning Privileges to Users

Access the Assign User Privileges page.

Define user privileges by associating a person with a business contact and assigning privilege codes. The business contact is typically a customer that the person represents. The user privileges enable you to define self-service security more specifically than the role privileges.

For example, suppose that a contact's role privileges do not enable the contact to update customer address information. If you need to enable a particular contact to update addresses, you could do that by assigning the user privilege to that contact. Conversely, suppose that a contact's role can submit a quote, but you want to revoke a particular contact's privilege to submit quotes. You do that by adding the privilege for submitting quotes and then selecting the Revoke check box.

PeopleSoft Order Capture Self Service is delivered with two privilege codes that are built to use privilege amounts: View All Orders (VIEWALLORDRS) and View All Quotes (VIEWALLQUOTS). These privileges are associated with an amount that further restricts access to order or quotes over a certain dollar amount.

Assigning Privileges to Roles

Access the Assign Role Privileges page.

Only two business object roles (as defined in the Customer Data Model) are supported with PeopleSoft Enterprise CRM self-service. These are consumer and contact. View the sample data for the role privileges and follow the sample as a guideline. If you have transactions for which data filtration is based on an amount, use the Amount field.

Setting Up Existing Customer User Registration Templates

Access the Existing Customer User Registration Setup page.

Use this page to set up templates for the fields and records that you want to use for customer registration. Once you save the template, you can select it from the Template field within the Customer Registration Fields group box on the User Registration Setup page.

When you set up existing customer user registration, you specify the information that customers enter to verify their status as existing customers. The system uses this as a template that appears for customers to enter the information

Note. For security reasons, set up at least two keys that are known only to the user.

Registering Business Users

Access the Business User Registration Setup page.

To administer self-registration as a business user (a contact of a company), use the Business User Registration Setup page to establish a company code and password (company key).

The company name is the company for whom you are setting up the registration keys. When a self service user or external company administrator uses the company key to register, the user that is created by the system is tied to the company defined on this page.

Setting Up Guest Users

Access the User Registration Setup page.

Self-service security is controlled by privileges that you establish and assign to guest user IDs. When a user registers, the system clones the currently active guest ID, with all its access privileges, to create the new user ID, and then creates the necessary customer or consumer record in the CRM database.

See Setting Up Guest IDs to Access Self-Service Sites.

To administer registration through PeopleSoft Enterprise CRM self-service, you must set up a guest user ID. The guest user acts as an administrator and provides the defaults that are necessary to establish new users.

See Also

Setting Up Customer Self-Service

Setting up Terms and Conditions for Self-Service Users

Access the Terms and Conditions - Self Service Registration page.

Enter the text for the terms and conditions that you want users to see during self-service registration.

Setting up Terms of Service for Self-Service Users

Access the Terms and Conditions - Terms of Service page.

Enter the text for the terms of service that you want users to see during self-service registration.

Setting up Privacy Policies for Self-Service Users

Access the Terms and Conditions - Privacy Policy page.

Enter the text for the privacy policy that you want users to see during self-service registration.

Defining Application Security

To define application security, use these components:

• Security Profile Definition (RSEC_PROFILE_DEFN).

• Security Membership Definition (RSEC_MEMBER_DEFN).

• Security View Definition (RSEC_VIEW_DEFN).

• Security Function Definition (RSEC_FUNC_DEFN).

• Security Function Group (RSEC_FUNC_GROUP).

• Security Object Definition (RSEC_OBJECT_DEFN).

• Security Builder (RSEC_BUILDER_RUN).

• Security Static Transfer Menu (RSEC_STAT_MENU).

This section discusses how to:

• Define security objects.

• Add membership list names and descriptions.

• Select membership objects and object members.

• Select the membership type.

• Add members to a static membership list.

• Choose the dynamic criteria for the membership list.

• Add view list names and descriptions.

• Select view objects and options.

• Select the view type.

• Add members to static view list.

• Choose the dynamic criteria for the view list.

• Define functional options.

• Define functional option groups.

• Add functional option groups and view lists to the security profile.

• Add membership lists to the security profile.

• Set run controls for the list build process.

• Enter static member transfer paths.

Pages Used to Define Application Security

Defining Security Objects

Access the Security Object page.

Object Type

Select either Membership or View Privilege. The Object type determines whether the Security Object is used for defining Membership List or View List.

Adding Membership List Names and Descriptions

Access the Membership List page.

Enter a name for the membership list that you want to create. Select the Active status. Enter text that describes the type of membership list that you are creating.

Selecting Membership Objects and Object Members

Access the Add Membership List page.

Security Object	Select the security object that you want to use for your membership list: Customer Partner Partner Contact Person Role Note. You can also create your own security object and select it from this list. You would, however, need to call the delivered security APIs at runtime to access security.
Membership Applies To	Indicate to whom you want the membership list to apply. Select: All: Select if you want to the membership list to apply to all members associated with the security object. Multiple Members: Select if you want the membership list to apply to select group of members that are associated with the security object. When you click Next, the system displays the next Add Membership List page, where you can select the membership type that you want to use (either dynamic or static). Single Member:Select if you want the membership list to apply to a single member associated with the security object. When you click Next, the system displays the page that is associated with the security object (either customers, partners, partner contacts, persons, or roles).
Next	Click to go to the next page. The system displays a new page based on the selections that you have made on the previous Add Membership List pages.

Selecting the Membership Type

Access the Add Membership List page.

Membership Type	Select from these values: Dynamic: Select to choose a dynamic list of members. When you click Next, a search page appears based on the security object that you selected on the second Add Membership List page. Static: Select to choose a static list of members. When you click Next, a page appears based on the security object that you selected on the second Add Membership List page.
Next	Click to go to the next page. The system displays a new page based on the selections that you made on the previous pages.

Adding Members to a Static Membership List

Access the Add Membership List (static) page.

This page displays different fields based on the security object you selected on the previous page. Selected the setID (if this field appears) and the role, customer, partner, partner contact, or person that you want to add to the membership list. Click the Add button to add new members.

Choosing the Dynamic Criteria for the Membership List

Access the Add Membership List (dynamic) page.

Select or enter the criteria that you want to use to create a membership list. The system uses the criteria that you select to create a dynamic membership list. To view the results of the criteria that you enter, click the Preview button. When you are satisfied with the results, click the Finish button at the bottom of the page.

Adding View List Names and Descriptions

Access the View List page.

Enter a name for the view list that you want to create. Select the Active status. Enter text that describes the type of view list that you are creating.

Selecting View Objects and Options

Access the Add View List page.

Security Object	Select the security object that you want to use for your view list. Choose from one of these delivered values: Catalog Customer Hold Codes Performance Metric Financial Accounts Note. You can also create your own security object and select it from this list.
View Applies To	Select one of these values to indicate to whom you want the view list to apply: All: Select this value if you want the view list to apply to all members associated with the security object. Multiple Members: Select this value if you want the view list to apply to select group of members that are associated with the security object. When you click Next, the system displays the next Add View List page, where you can select the view type that you want to use (either dynamic or static). Single Member:Select this value if you want the view list to apply to a single member associated with the security object. When you click Next, the system displays the page that is associated with the security object (either hold codes, catalogs, performance metrics, or customers.
Next	Click to go to the next page. The system displays a new page based on the selections that you made on the previous Add View List pages.

Selecting the View Type

Access the Add View List page.

View Type

Select one of these values: Dynamic: Select to define criteria for a dynamic list of members that you want included in your view list. When you click Next, a search page appears based on the security object that you selected on the second Add View List page. Static: Select to choose a static list of members. When you click Next, a page appears based on the security object that you selected on the second Add View List page.

Next

Click to go to the next page. The system displays a new page based on the selections that you made on the previous pages.

Adding Members to Static View List

Access the Add View List (static) page.

This page displays different fields based on the security object you selected on the previous page. Selected the setID (if this field appears) and the catalog, customer, hold code, or performance metric that you want to add to the view list.

Choosing the Dynamic Criteria for the View List

Access the Add View List page.

Select or enter the criteria that you want to use to create a view list. The system uses the criteria that you select to create a dynamic view list. To see the results of the criteria that you enter, click the Preview button. When you are satisfied with the results, click the Finish button at the bottom of the page.

Defining Functional Options

Access the Functional Options page.

Functional Option and Description

Enter a name for the functional option and then enter a description.

Defining Functional Option Groups

Access the Functional Option Group page.

Use functional option groups to group functional options. You may then associate the functional option groups with security profiles. Creating functional option groups and using them with security profiles can help make security maintenance faster and more efficient.

Functional Option Tab

Amount Related Tab

The fields that appear on this page are used if the functional option is associated with an amount field.

Adding Functional Option Groups and View Lists to the Security Profile

Access the Security Profile page.

Defining security profiles involves the granting of view lists and/or functional options. You then grant or associate one or multiple membership lists with the security profile. An enterprise administrator or enterprise channel manager should know how to create and maintain security profiles, as well as understand how security is impacted when a security profile changes.

Warning! Inactivating a security profile removes the associated membership and view lists

Adding Membership Lists to the Security Profile

Access the Security Profile - Membership page.

Add Membership List	Click to access the Add Membership List page, where you can select the membership lists that you want to include in the security profile.
	Click to access the Refresh Dynamic Lists page, where you can set up a process to periodically refresh the lists that you have associated with the security profiles that you created. View lists and Membership lists that are built based on dynamic criteria are refreshed.

Setting Run Controls for the List Build Process

Access the Refresh Dynamic Lists page.

Use this page to refresh the lists, security objects, and profiles that you have created to implement security for your PeopleSoft Enterprise CRM environment. If the content of the lists, objects, and profiles changes frequently, you can set up this process to run daily, every few minutes, or every few hours.

Entering Static Menu Transfer Paths

Access the Static Menu Transfer page.

Use this page to create static menu transfer paths for entering or viewing static list data that is either dynamically created or manually entered. The static list navigations that you create on this page appear in the Static List Navigation drop-down list box on the Security Object page. Static list navigation is used when you create a security profile.