Setting Up and Administering HRMS Security

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

• Implement data permission security.

• Set up and assign tree-based permission.

• Assign role-based data permission security to permission lists.

• Refresh security join tables.

• Query data permission security.

• Create data permission security for managers.

• Create and lock user IDs.

• Set up security for Recruiting Solutions

• Set up security for local functionality.

• Modify data permission security.

Note. Self Service transactions use both data permission security (discussed in this chapter) and security features unique to Self Service, depending on the transaction.

See Also

Setting Up and Working with Self-Service Transactions

Understanding PeopleSoft Security

PeopleSoft security is based on permission lists and roles. This diagram illustrates how permission lists and roles combine to create user security profiles:

Permission Lists and Roles Create a User's Security Profile

To administer security:

1. Create permission lists.

2. Create roles and attach permission lists to roles.

3. Create user IDs and attach permission lists and roles to user IDs.

Create Permission Lists

Create permission lists and assign to them access to menus, components, component interfaces, pages, global functionality, along with other information. Permission lists are assigned to roles; however, some permission lists are assigned directly to the user.

Create permission lists using the Permission Lists component (ACCESS_CNTRL_LISTX) and Copy Permission Lists component (PERMISSION_SAVEAS).

Create permission lists on the Permission Lists component and Copy Permission Lists component.

Note. Assign data permission to permission lists on the Security by Dept Tree page (SCRTY_TABL_DEPT) and the Security by Permission List page (SCRTY_CLASS).

See Enterprise PeopleTools PeopleBook: Security Administration, “Setting Up Permission Lists”

Create Roles

Create roles and assign permission lists to the roles. The access you granted to the permission lists combines under the role. For example, you would assign the permission lists required by your workforce's managers to the role of Manager which, combined, give your managers security access to all elements of the system that managers need. Roles are assigned to the user.

Create roles using the Roles component (ROLEMAINT) and Copy Roles component (ROLE_SAVEAS).

Assign permission lists to roles on the Permission Lists page (ROLE_CLASS).

See Enterprise PeopleTools PeopleBook: Security Administration, “Setting Up Roles”

Create User IDs

Create user IDs and assign to user IDs roles and permission lists to give them access to the system as appropriate.

In addition to the permission lists assigned to roles, the following four specific permission lists are assigned directly to the user on the User Profile - General page (USER_GENERAL). Unlike the permission lists assigned to roles, users can have only one each of these four permission lists:

• Navigation Homepage

  Navigation homepages are used by PeopleSoft Workflow.

• Process Profile

  Process profiles contain PeopleSoft Process Scheduler authorizations.

• Primary

  Primary permission lists grant global security.

• Row Security

  Row Security permission lists grant data-permission security based on a department security tree. Assign data permission to permission lists on the Security by Dept Tree page.

  Note. On the Security by Permission List page you can assign data permission to permission lists that you attach to roles.

Create user IDs on the User Profiles component and Copy User Profiles component and assign the Navigator Homepage, Process Profile, Primary, and Row Security permission lists directly to the user profile on the General page.

Roles and permission lists combine under the user ID to give users their security access. For example, the HR Training Manager would have the roles of manager, instructor, and employee to meet her access needs as a manager, instructor, and employee. Managers in different departments would have the same manager and employee roles, in addition to other roles that meet their needs.

Assign roles to users using the User Profiles - Roles page (USER_ROLES):

Assign roles to user IDs on the User Profiles - Roles page

This diagram illustrates how a user's security profile is made up of an assigned role, and the permission lists assigned to that role, and permission lists assigned directly to the user:

User security profiles are made up of the combined permissions of the roles and permission lists assigned to them.

See Enterprise PeopleTools PeopleBook: Security Administration, “Administering User Profiles”

See Also

Enterprise PeopleTools PeopleBook: Security Administration

Understanding Data Permission Security for HRMS

Data permission security refers to controlling access to the rows of data in your system. In PeopleSoft HRMS, you can control access to the following types of data:

• People

  • Employees.

  • Contingent workers.

  • People of interest (POIs) with jobs.

  • People of interest (POIs) without jobs.

    Note. The data of people of interest without jobs is secured differently than the data of people with jobs.

• Recruiting job openings.

• Departments.

  Note. Row security for departments secures department budgets and positions, if you are using Manage Positions. The Departments component is not secured by data permission so control access to department definitions by restricting access to the component or change the search record to DEPT_SEC_SRCH.

See Also

Human Capital Management Row Level Security in HRCS 8.9 White Paper

Understanding Organizational Relationships, Employment Record Numbers, and Multiple Jobs

Data Security and Data Retrieval

The system enforces data permission security with security search views. To understand how this is done it helps to understand how the system retrieves data when you access a component.

When you open a component in PeopleSoft HRMS the system displays a search page. The search page represents the search record and the fields that appear are the search keys and alternate key fields that uniquely identify each row of data. The system uses the information that you enter in the key or alternate key fields to select the rows of data that you want to view or manipulate (except for the Add action, where you enter a key and the system creates a new data row). For example, a search page may have EmplID as a key field and Name as an alternate key. If you enter Smith in the Name field, the system retrieves all data rows with Name field data that matches Smith.

The system also uses search records to enforce data permission security. Search views for components that contain sensitive data also contain a security view to control data access.

The system adds the user's security profile, including their user ID and the values of the permission lists attached to their user profile, to the SQL (Structured Query Language) select statement along with the values that the user entered on the search page. The system retrieves the data that matches the criteria from the search page and the user's data permission lists. The system doesn’t retrieve data for people to whom you haven’t granted the user's permission lists data access.

Using the above example, if you enter Smith in the Name alternate key field, the system retrieves data only for the people with the name Smith to whom you have access.

This diagram illustrates the data retrieval process:

User profile information, search criteria, and the security view enforce data permission security

Note. Security for process and queries is enforced in much the same way.

Not all PeopleSoft HRMS components require data permission security. Their security requirements can be met using application security (restricting access to the entire page, component, or menu). Only components containing sensitive information, such as salary information, use the security search views. If necessary, you can add data permission security to any component that accesses person data, as long as the search records are defined as SQL views (some search records are defined as SQL tables).

A component can have only one search record. To associate more than one search record with a component (for example, data level security for some users and not for others), you reinstall the component on different menus, one for each search record, and grant access to the appropriate component using application security.

Core Security Views

PeopleSoft delivers the following core security views for components tracking people:

See Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer

Security Data

Data permission is controlled on two sides: transaction and user.

Transaction Security Data

Transaction data is the data that is being secured. Certain transaction fields on a transaction data row are used to secure access to that row. The data in these fields is called transaction security data. When the value of the transaction security data matches the value that a user can access (user security data), the system makes the entire row of data available to the user.

When the user accesses the component search page the security search view filters the data rows, displaying only the rows of data with the same transaction security values that the user has access to.

This diagram shows the Department field being used as transaction security data to secure the data of people in the organization.

The department field is the transaction value securing the data rows.

This table lists where you enter and maintain transaction data, to which record the transaction data is saved, and which fields can be used as transaction security data:

Note. All people, regardless of type, are first entered in the Add a Person component (PERSONAL_DATA), where you enter their personal information and assign them an ID. These pages do not capture any transaction security data. Transaction security data is captured on the components that you use to enter details about the person’s relationship to the organization.

Note. If you create a person but do not create a job data record or POI type record for them the system will save the person as a POI without job with a POI Type of Unknown. Somebody in your organization must have data permission access to unknown POIs in order to access their data and create either a job data or POI type record for them, otherwise the data is inaccessible.

Make sure that users who enter people into the system understand the consequences of not creating and saving a Job Data or POI type record for new people at the time the person is entered in the system.

When a transaction record is successfully completed and saved for the person on the Add an Employment Instance component, Add a Contingent Worker component, Add a POI Instance component, or Add a POI Reltn. component, the system deletes the Unknown POI instance for that person.

See Adding a Person.

See Controlling Data Access for POIs Without Jobs.

See Adding Organizational Instances for Employees, Contingent Workers, and POIs.

User Security Data

User security data is the data about a user’s security access. It enables the system to ensure that users have access only to that which you have granted them access. User security data for HRMS data permission is the data permission that you assign to permission lists and the roles and users to whom you assign the permission lists.

Data permission is granted to row security permission lists (ROWSECCLASS) and regular (role-based) permission lists (CLASSID). Both permission lists are created using the Permission Lists component and Copy Permission Lists component.

When you create a permission list on the Permission Lists component you can assign security to a number of different aspects of the application. Data permission is assigned separately on the Security by Dept Tree page and Security by Permission List page.

Note. When you add a permission list to the Security by Dept. Tree component, the system saves it as ROWSECCLASS.

This diagram shows how permission lists are created, assigned data permission, and assigned to users:

Create permission lists, assign to them data permission, and assign them to users.

This table lists the key differences between role-based permission lists with data permission and row security permission lists:

Note. You can use the same permission list as a row security permission list and a role-based permission list by adding it to both the Security by Dept Tree component and Security by Permission List component and then adding them to the user on the User Profile - General page and by way of roles.

Note. The system recognizes non-tree based security associated with row security permission lists. Customers who modified the system to use non-tree based security in previous releases only have to import the customized table capturing the row security permission lists and security definitions into SJT_CLASS. You can continue to assign the permission lists to users in the Row Security field on the User Profile - General page.

New customers, or customers using non-tree based security for the first time, should use role-based permission lists. This will provide you much greater flexibility.

This diagram shows the search page determining which permission lists a user has and what data permission the list gives the user.

The system determines which permission lists a user has and what data permission is granted by the permission list before retrieving the matching data rows.

This table lists where you enter and maintain user security data and to which record the user security data is saved:

See Understanding PeopleSoft Security.

See Setting Up and Assigning Tree-Based Data Permission.

See Assigning Role-Based Data Permission Security to Permission Lists.

Security Join Tables

The system stores security data in transaction and user security join tables (SJTs). When you access a transaction component with a security search view, the security view references the security join tables to determine how the data is secured and what access the user has.

This graphic shows the search page determining which permission lists a user has and what data permission the list gives the user using the security join tables. The transaction security join table is determined by the type of data stored in the component.

The core security view uses the security data stored in the security join tables to determine which rows of data the user can access.

Transaction Security Join Tables

Each transaction security join table stores the transaction data required to secure each row of data. The security join tables store one row of data for each unique combination of key fields.

There are four transaction security join tables:

The key fields are:

• SCRTY_TYPE_CD (security access type code)

  Security access types indicate which field is used for transaction security data. For example the security type 002 enables you to secure person data by location.

  Security access types are unique to a security access set.

• SCRTY_KEY1, SCRTY_KEY2, and SCRTY_KEY3 (security keys)

  The key security fields uniquely identify the security transaction data securing a row of data. The system determines the key fields by the security access type. For example, if person data is secured by location, then the key security fields are BUSINESS_UNIT (the prompt value for location) and LOCATION (the third key field isn’t required for this example).

• EMPLID

  A person’s unique identifying number that is assigned to them on the Personal Data pages.

• SETID and DEPTID

  A department’s setID and department ID.

• HRS_JOB_OPENING_ID

  A job opening’s unique identifying number, which is assigned to it on the Job Opening page.

Each table stores additional fields depending on the type of security you are using.

For example, if you are securing the data of people with jobs using the security access type Job Department Tree (001), the key fields of the security join table SJT_PERSON looks like this:

If you used two security access types, for example Job Location (002) and Job Department Tree, SJT_PERSON looks like this:

Note. Locations and departments do not need three key fields to uniquely identify them so the third security key field isn't necessary for this example.

When you first enable a security access type load the transaction data into security join tables using the SJT Refresh process. After the initial load, the system updates the tables using SavePostChange PeopleCode when you make a change to the transaction security data in the transaction components. You can also capture any changes the PeopleCode misses by running the SJT Refresh process as needed or the Nightly Refresh process.

Note. The SavePostChange PeopleCode on the transaction component subpage SCRTY_SJT_SBP updates the security join tables.

This graphic illustrates how the transaction security join tables are kept up to date:

Keeping the transaction security join tables up to date.

See Running the Nightly Refresh Process.

See Running the Transaction Security Join Table Refresh Process.

User Security Join Tables

The user security join tables store the user security data required to determine users' data permission. The security join tables store one row of data for each unique combination of key fields.

There are two user security join tables:

In addition to the security access type field and security key fields, the user security join tables store the following fields:

• SCRTY_SET_CD (security set code)

  A security set is a set of data secured in HRMS. For example, PPLJOB is the security set for the data of people with jobs and DEPT is the security set for the department data. Each security set has security access types.

• OPRID

  The user’s user ID.

• CLASSID

  The ID of the role-based or row security permission list.

  Note. The security join tables store row security permission lists (ROWSECCLASS) as CLASSID permission lists but identify them using a row security flag.

The permission list data in SJT_CLASS_ALL comes from two sources:

• SCRTY_TBL_DEPT

  When you add tree-based data permission to a permission list, you use the Security by Dept Tree page and the system saves the permission list information to the SCRTY_TBL_DEPT record.

• SJT_CLASS

  When you add non-tree based data permission to a permission list, you use the Security by Permission List page and the system saves the permission list information to the SJT_CLASS record.

For example, if you are securing the data of people with jobs using the security access type Job Department Tree (001), the key fields of the SCRTY_TBL_DEPT table look like this:

To load the data from the SCRTY_TBL_DEPT table, you need to run the Refresh SJT_CLASS_ALL process. In SJT_CLASS_ALL, the Refresh SJT_CLASS_ALL process:

• Creates a row of data for each enabled, tree-based security access type (and it's security set) with the data permission you set up on the Security by Dept Tree page.

  For example, if you enable security access type 012 (RS Dept Id) and security access type 001 (Job Department Tree) and grant the row security permission list TRAIN data permission to department 123, the process will create a row for each security access type and the permission will have access to people with jobs in department 123 and job openings in department 123.

• Saves the row security permission list as a CLASSID permission list.

• Saves the department setID as SCRTY_KEY1 and the department ID as SCRTY_KEY2.

If you are securing the data of people with jobs using the security access type Job Location (002), the key fields of the security join table SJT_CLASS look like this:

When you save your changes on the Security by Permission List page, SavePostChange PeopleCode automatically updates the data to the security join table SJT_CLASS_ALL.

If you are using both security access types, SJT_CLASS_ALL looks like this after you have run the Refresh SJT_CLASS_ALL process and the PeopleCode has updated it:

This graphic illustrates how the permission list user security join tables are kept up to date:

Keeping the operator security join table up to date.

See Running the Refreshing SJT_CLASS_ALL Process.

The security join table SJT_OPR_CLS stores the relationship between User IDs and permission lists with data permission. The data in SJT_OPR_CLS comes from three sources:

• PSOPRDEFN

  This record contains the relationship between the User ID and row security permission list from the User Profile - General page.

• PSROLEUSER

  This record contains the relationship between the User IDs and roles from the User Profile - Roles page.

• PSROLECLASS

  This record contains the relationship between roles and permission lists from the Roles - Permission Lists page.

To update SJT_OPR_CLS with the data from PSOPRDEFN, PSROLEUSER, and PSROLECLASS, run the Refresh SJT_OPR_CLS process whenever you add a permission list with data security to a user profile (either by adding a row security permission list on the User Profile - General page, adding a role with data permission on the User Profile - Roles page, or by adding a role-based permission list with data permission to a user-assigned role on the Roles - Permission Lists page) or delete one from a user profile.

This graphic illustrates when to update the user profile security join table:

Run the Refresh SJT_OPR_CLS process to keep the SJT_OPR_CLS up to date.

Note. You can enable the USER_PROFILE message and the local subscription HCM_Refresh_SJT_OPR_CLS and the ROLE_MAINT message and the local subscription HCM_Role_Refresh_SJT_OPR_CLS to automatically update SJT_OPR_CLS. PeopleSoft does not deliver the system with these messages enabled.

See Using HRMS EIPs that Subscribe Locally.

The Refresh SJT_OPR_CLS process loads the OPRID and ROWSECCLASS values from PSOPRDEFN directly into SJT_OPR_CLS, saving the row security permission list as CLASSID.

To establish the relationship between user profiles and role-based permission lists, the process first loads the OPRID and ROLENAME from PSROLEUSER and the ROLENAME and CLASSID from PSROLECLASS into a temporary table and then loads the OPRID and CLASSID, and the relationship between them, into SJT_OPR_CLS.

This diagram illustrates the data stored in SJT_OPR_CLS and their source:

SJT_OPR_CLS stores the relationship between user profiles and permission lists.

Note. The SEC_RSC_FLG field indicates if the CLASSID was originally a ROWSECCLASS permission list by flagging it with a value of Y.

See Running the Refresh SJT_OPR_CLS Process.

Security Sets and Security Access Types

A security set is a grouping of data that is being secured. The sets differ by the origin of the transaction security data. For example, people of interest without jobs have a separate security set from people with jobs because the transaction data used to secure them does not come from the JOB record, but from the PER_POI_SCRTY record.

PeopleSoft delivers the following five security sets:

Note. PeopleSoft has delivered all the security sets you are likely to need. If you add new sets, it is considered a customization.

See See the security white paper posted on Customer Connection:Human Capital Management Row Level Security in HRCS 8.9

See Viewing Security Sets.

Security access types are ways of securing the data within a security set. Each security set has a number of security access types that you can choose to enable. Among other things, security access types determine:

• The security transaction data.

• If there is data security for future-dated rows.

• If the access type uses a department security tree.

  Note. You can only set up department hierarchies on security trees and you can only grant security access by department tree to row security permission lists.
  
  Security access types that don't use a department security tree do not have a hierarchical structure and require that you list each field value individually for each permission list.

The following table lists the security access types by security set:

Note. PeopleSoft has delivered all the security access types you are likely to need. You can add new types but it requires a very good knowledge of the application and of SQL.

Security administrators can only assign data permission using the security access types that you enable.

See Enabling Security Types.

Enabling and Using Multiple Security Access Types

When you grant a permission list access to data in a security set using more than one security access type the security access creates a union, not a join or an intersect, with the two types. For example, if you enable the Job Company and Job Business Unit security access types for the PPLJOB security set and grant a permission list access to people in company A and people in business unit B, users with the permission list can access people in company A or people in business unit B; their access is not restricted to people in both business unit B and company C.

Note. See the security white paper posted on Customer Connection for information about creating security access types that join transaction fields to secure data.

HRMS Security Process Flow

When you set up HRMS data permission security you will follow this process flow:

Setting up PeopleSoft HRMS data permission security.

To set up HRMS data permission:

1. Set up permission lists in the PeopleTools pages.

2. Set the security installation settings on the Security Installation Settings component.

3. Review security sets on the Security Set Table component.

4. Enable security access types on the Security Access Type component.

5. Assign data permission to permission lists:

   • If you are using security tree-based security access types, set up a security tree, assign data permission on the Security by Dept Tree component, and refresh SJT_CLASS_ALL.

   • If you are using non-tree based security access types, assign data permission on the Security by Permission List component.

After you assign permission lists to roles, and the roles and row security permission lists to your users, refresh SJT_OPR_CLS.

Example of HRMS Data Permission

Grant the following security to these permission lists:

Grant the permission lists to the following roles:

Grant the following row security permission lists and roles to users:

Implementing Data Permission Security

To implement data permission security, use the Security Installation Settings component (SCRTY_INSTALL), the Security Sets component (SCRTY_SET_TBL), and the Security Access Type component (SCRTY_TYPE2_TBL).

This section discusses how to:

• Install HRMS security.

• View security sets.

• Set up update groups.

• Enable security types.

• Enter SQL statements.

Understanding Future-Dated Security

The Security Installation Settings page enables you to select actions that, when used on the Work Location page (JOB_DATA1), trigger the SavePostChange PeopleCode to create a future-dated row in SJT_PERSON.

The system normally secures data using the current transaction security data. Only users with data permission access to the transaction security data on the current row can access the person's data

When you include future-dated transaction security data rows the system uses both the current data and the future-dated values to secure the data. This gives users with data permission access to the transaction security data on the current row and users with data permission access to the transaction security data on the future-dated row access to the person.

The system only creates future-dated security rows in SJT_PERSON when you:

1. Select one or more actions on the Security Installation Settings page.

2. Enable future-dated rows for the security access type.

   Note. This enables you to use future-dated security with some types but not others.

3. Create and save a future-dated row in a component that uses the JOB record using one of the actions you selected on the Security Installation Settings page.

If you have selected the action of Transfer in the Actions that trigger Future Dated Security Rows grid, then when you create a future-dated Job Data row with the action of Transfer for a person, the system will add a row to the SJT_PERSON with the transaction data from the new row. Users with data permission to the future-dated transaction security data will have access to the person's data.

Note. Only component security views use future-dated security rows.

For example, as of January 1, 2005 Kenny Wong works in department 42000. Starting July 1, 2006 he will transfer to department 44000. On April 15, 2006, in anticipation of the transfer, the HR administrator enters a future-dated job data row for the transfer.

Julie Sparrow manages department 42000 and Barry Deere manages department 44000 and each has data permission to the people in their departments.

As of April 15, 2006 Kenny Wong has the following two job data rows:

The data permission depends on if you are using future-dated security for that security access type and if you have selected the action of Transfer on the Security Installation Settings page:

• If you have not selected it:

  • The SavePostChange PeopleCode does not update SJT_PERSON with the new department information from the future-dated row because it is not yet effective.

    Note. When the transfer row does become effective, the Nightly SJT Update process updates SJT_PERSON, overwriting the old row with the new row.

  • Julie can access Kenny's data until June 30, 2006 and Barry can access it starting July 1, 2006.

• If you have selected it:

  • The SavePostChange PeopleCode creates a new row in SJT_PERSON with the future-dated transaction security data. The system identifies this row as future-dated.

    Note. When the transfer row becomes effective, the Nightly SJT Update process updates SJT_PERSON, removing the old row and making the future-dated row current.

    Note. Search views that don't use future-dated security will not use the future security row when enforcing data permission.

  • Julie can access Kenny's data until June 30, 2006 and Barry can access it starting April 15, 2006.

Understanding Special Job Security Options

Without special job security options, the system creates a single transaction security data row for each unique combination of ID and employment record number. When you use special job security options, the system creates additional rows in SJT_PERSON with different security key values to enable access to rows to which a permission list would normally not have access.

For example, if you are securing data by department and have enabled people with access to the home job data record to view the host job data record but are not allowing people with access to the host job data record to view the home job data record, the system will create the following three rows of data in SJT_PERSON (only the relevant columns are shown) for a person whose home job data record (employee record number 0) is in department 25000 and whose host job data record (record number 1) is in department 20000:

The system creates the row marked Home-Host to grant the special job security option. By creating a row for the host record with the department value of the home record, people with data permission to the home record can access the host record.

The system works the same way for the other special security options, creating an additional row and inserting the key values that enable the access.

Pages Used to Implement Data Permission Security

Installing HRMS Security

Access the Security Install Settings page.

Special Job Security Versions

The options you select here will be available for your installation but will not be enabled unless you select them again for the security access types you are using. This enables you to use the security versions for some security access types and not others.

Actions that trigger Future-Dated Security Rows

Select the actions that will trigger the SavePostChange PeopleCode in the components using the JOB record to create a future-dated security row in SJT_PERSON when they are used in a future-dated row in the Job Data pages. The system will not create security rows for future-dated rows with actions other than those listed here.

To create future-dated rows, you need to select the Include Future Dates check box on the Security Type Table. This enables you to use future-dated security for some security access types and not others.

Viewing Security Sets

Access the Security Set Table page.

Object Owner ID	Security sets with a PeopleSoft Object Owner ID are system data and not available for modification on this page. You can still modify the Security Update Groups of delivered security sets.
Transaction Sec. Join Table	The security join table that stores the transaction data for this security set. Note. If you are creating a new security set, you must have created this table in Application Designer before creating the security set. Creating a new security set requires modification of the system. Please refer to the Security white paper on Customer Connection for directions.
SJT Temp Table (for AE process)	The temporary record used for PeopleSoft Application Engine. It is a copy of the transaction security join table and also contains the Application Engine process fields. This table updates the transaction security join field using the Application Engine process.
SQLID for Value Field List	The list of fields (not including the key fields) that are in the transaction security join table.
Generate SQL	Click to generate the SQL and SQLID for the value field list.

Security Access Types for this Set

The system lists the security access types for this security set and indicates which ones are enabled. Enable or disable security access types on the Security Type Table page.

See Enabling Security Types.

Setting Up Security Update Groups

Access the Security Update Groups page.

Select which refresh options to make available when updating the security set using the SJT Refresh process. The system makes the options you select here available for this security set on the Refresh SJT page, enabling you to select portions of the security join table to update.

For example, you could refresh all the rows for external instructors by selecting the refresh option Person of Interest Type and the POI Type External Instructors.

Enabling Security Types

Access the Security Type Table page.

You can enable more than one security access types for a security set and you can assign data permission access to a permission list using more than one access type.

Note. PeopleSoft has delivered the most asked for security access types and you should not need to create new types. Enable or disable the types your installation requires.

Please refer to the Security white paper on Customer Connection for directions on how to create new security types.

Note. The more security access types you enable and options you use, the more rows of data the system stores in the security join tables. This affects system performance. PeopleSoft advises you to enable only the security types and options required to manage your data permission needs.

Refreshing the Transaction Security Join Tables

You should refresh the transaction security join tables whenever you:

• Enable or disable a security access type.

• Enable or disable a future-dated security for an enabled security access type.

• Change the special job security versions for an enabled security access type.

See Running the Transaction Security Join Table Refresh Process.

Entering SQL Statements

Access the Security Type SQL page.

The Application Engine uses the SQL fragments on this page to build the update and insert statements to update the transaction security join table.

You can use any SQLID but when you click the Generate SQL buttons, the system generates unique IDs based on the security set and/or type.

Warning! This page should only be used by users with a strong understanding of SQL joins and the table relationships.

Setting Up and Assigning Tree-Based Data Permission

To set up and use tree-based data permission, use the Tree Manager component (PSTREEMGR), Security Tree Audit Report component (RUNCTL_PER506), Security by Dept Tree component (SCRTY_DATA), and Refresh SJT_CLASS_ALL component (SCRTY_OPR_RC).

This section provides an overview of the data permission security by department security trees and discusses how to:

• Create and modify security trees.

• Audit security trees.

• Assign tree-based data permission to row security permission lists.

• Refresh SJT_CLASS_ALL with tree and row security permission list data.

Note. After you assign a row security permission list to a user, you must run the Refresh SJT_OPR_CLS process.

See Running the Refresh SJT_OPR_CLS Process.

Understanding Data Permission Security by Department Security Trees

Each security set has a tree-based security access type. Tree-based security access types use department security trees to set up a hierarchy of your departments and enable you to use this hierarchy to simplify data assignment.

You use PeopleSoft Tree Manager to build a hierarchy of department security for an organization. A security tree provides a graphic means to grant and restrict access to data. The security tree doesn’t have to represent your organization's hierarchy exactly, although it is usually very close.

To grant a row security permission list access to a group of departments, you grant access to the department to which all of those departments report. You can restrict access to individual departments or to a group of departments if you need to. This is an example of a department security tree for the SHARE setID:

Portion of the SHARE department security tree

Using this security tree you could, for example, grant a row security permission list access to department 13000 and the system includes department 13000 and all the departments that report to it, giving the permission list access to everyone in all fourteen finance departments.

You can also restrict access to one of the branch entities. For example, if a row security permission list needs access to everyone in Finance except for Business Services, grant access to department 13000, but restrict access to department 15000, giving access to departments 13000, 20000, 22000, 25000, 27000, and 31000.

Note. You can only grant tree-based data permission to row security permission lists.

Before you work with data security and PeopleSoft Tree Manager, make sure that human resources data is defined in the PeopleSoft HRMS control tables.

Warning! Before you create or modify a security tree, we recommend that you review the Enterprise PeopleTools PeopleBook: PeopleSoft Tree Manager for a detailed discussion of using PeopleSoft Tree Manager because this section does not provide a complete overview of the application. Security is an important component of your system, and it is crucial that you understand all aspects of PeopleSoft security and its tools before you implement it.

See Setting Up and Assigning Tree-Based Data Permission.

See Assigning Role-Based Data Permission Security to Permission Lists.

See Enterprise PeopleTools PeopleBook: PeopleSoft Tree Manager

Security Trees and Departments

For the purpose of building department security trees, PeopleSoft defines all entities in an organization—from companies to departments—as departments. The department data is created and stored in the Departments component (DEPARTMENT_TBL), which you can access from PeopleSoft Tree Manager or the Set Up HRMS menu. You assign security access based on these departments so define each entity in your organization in the Departments component so that you can add its department ID code to the security tree.

Trees are built with levels and nodes:

• Levels are the levels of the hierarchy.

• Nodes, representing organizational entities, are added at different levels to indicate their place in the hierarchy.

For example, the first level of your tree might be the company level. The second level might be the regional level. A node that is added at the first level is a company-level node and represents the company department. A node that is added at the second level is a regional-level node and represents a regional department, such as an office. The first node in your organization is the root node. This is the highest node in the hierarchy. All other nodes (departments) report up to the root node.

Access to data is based on the hierarchy that you create. If you grant access to a department, you also grant access to each department that reports to that department.

Note. You should include inactive departments on your security tree; otherwise, data for retired, terminated, or transferred people who used to be in inactive departments will be inaccessible.

See Maintaining Departments.

Security Trees and Effective Dates

All security trees are called DEPT_SECURITY. Security trees are uniquely identified by their setID and effective date.

You can create future-dated trees to reflect a change in your reporting structure and you may want to grant access using the newer tree (or, perhaps, to a historical tree).

When you assign data to a permission list on the Security by Dept Tree page select the date as of which you want the trees to be effective. When you add a row in the Define Security Profile grid on the Security by Dept Tree page and select the setID of the security tree, the system references the security tree that is effective as of the date you selected in the As of Date for the Trees field.

For example, it is now April, 2005 and you have created a future-dated security tree for the SHARE setID dated January 1, 2006. You wish to try out the data permission using the new tree. On the Security by Dept Tree page, enter January 1, 2006 (or a higher date; the date does not have to be the exact effective date of the tree) in the As of Date for the Trees field. Add a row in the Define Security Profile grid and select the SHARE setID. The system displays January 1, 2006 in the Effective Date field in the grid and uses the future-dated tree to enforce data permission for that permission list.

When the future-dated tree becomes effective, the system does not automatically update the security profiles of permission lists referencing the old tree. For example, on January 1, 2006, the system continues to use the previous SHARE tree to enforce data permission for all the permission lists that were referencing it.

To update the permission lists so that they reference the new tree, enter the Security by Dept Tree page, enter the date January 1, 2006, and click the Refresh Tree Effective Date button. The system will update the effective dates of all the trees referenced by that permission list to the dates the trees effective as of January 1, 2006.

Pages Used to Set Up and Assign Tree-Based Permission

Creating and Modifying Security Trees

You can create a security tree automatically or manually.

Creating Security Trees Manually

The steps for creating a tree manually are described in the Enterprise PeopleTools PeopleBook: PeopleSoft Tree Manager. When you create a security tree, enter the following data on the Tree Definition and Properties page (PSTREEDEFN):

Once you’ve created the basic tree structure, you begin to add nodes. In a security tree, each node represents a business entity in your organization. You define nodes on the Departments component, creating a department for each business entity in your organization.

You must have a node for every department in the setID. You can add nodes to your trees as you add departments to your organization.

To add a new, future-dated departments in order to maintain data security for people added to the new departments, create a future-dated security tree. This will enable you to add people to the new department before it becomes effective and still be able to control access to their data in the present.

Creating Security Trees Automatically

You can create a security tree using an existing organizational structure. Use the following Structured Query Report (SQR) procedure to import the existing hierarchy and build your security tree. You import your department data into a temporary Department Table, and the system uses that data to build the security tree.

To set up a hierarchy of departmental entities and build your data security tree automatically:

1. Import the entity data.

   Import the entity data into the temporary table R_PER507 using the PeopleSoft Import utility, a Structured Query Report (SQR), or another batch facility. You load department data into this temporary table, so before you use this utility, you must establish the reporting hierarchy for all the departments in your organization. To do this, use the REPORTS_TO_DEPT field in the R_PER507 temporary table. R_PER507 is included with PeopleSoft HRMS; it looks like DEPT_TBL, but it includes the following additional columns:

   New Column	Description
   SETID_RPDEPT	Specifies the setID of the department that a particular department reports to. In addition to the other Department Table data, you must load data into this column.
   REPORTS_TO_DEPT	Specifies department that a particular department reports to. In addition to the other Department Table data, you must load data into this column.
   ORGCODEFLAG	Indicates whether the department is selected for processing as of a particular date. The system populates this column based on your department data and the REPORTS_TO_DEPT field values.
   ORGCODE	Designates the position of the department in the hierarchy. The system populates this column based on your department data and the REPORTS_TO_DEPT field values.
   TREE_LEVEL_NUM	Temporary work column.
   PARENT_NODE_NUM	Temporary work column.
   TREE_NODE_NUM	Temporary work column.
   TREE_NODE_NUM_END	Temporary work column.

2. Set up the reporting hierarchy.

   Run PER507 to set up the reporting hierarchy of your tree. This utility determines whether a department is active or inactive as of the date that you enter when you run the utility, and populates the ORGFLAG column in R_PER507 accordingly. The utility creates a structured organization code based on the REPORTS_TO_DEPT field values that you loaded and populates ORGCODE accordingly. This utility uses the ORGCODE values to set up the department hierarchy.

3. Build the department security tree.

   Run PER508 to build your DEPT_SECURITY tree. The effective date of the tree is the latest effective date of the departments that were processed in step 2.

   Note. To set up multiple trees to represent security or organizational structures at different points in time, perform step 2 for each tree, setting the As of Date each time, and perform this step again.

4. Transfer department data into the department component.

   Run PER509 to transfer the information that you set up in R_PER507 into DEPT_TBL. You can’t view or update the Department component until you run this utility.

5. Renumber and insert numbered gaps in the security tree.

   Run PTUGAPTR.SQR to renumber the nodes in your tree and insert numbered gaps between the nodes.

Modifying Security Trees

You can modify an existing tree by changing either the nodes or the levels. When you modify a security tree, the tree node numbers usually change, so you need to refresh the numbers. You also need to run the Refresh SJT_CLASS_ALL process to update the data access profiles and security join tables.

See Refreshing SJT_CLASS_ALL with Tree and Row Security Permission List Data.

Renumbering Gaps in Security Trees

PeopleTools assigns each node a number and reserves a series of unused numbers, called gaps, which the system uses to make changes to sections of a security tree. When you move a node, the system renumbers the nodes that appear to the right of the node that you moved (the children of the node that you moved). When you save changes to a tree, the system saves only the parts of the tree that have changed.

To refresh the unused numbers in the gaps between nodes, run the PTUGAPTR.SQR utility. Refresh unused numbers when:

• You load your security tree structure.

• You modify your security tree.

• An error message tells you to gap your tree.

Auditing Security Trees

After you build your security tree, we recommend that you run an audit (PER506.SQR) to determine which department IDs are in the Departments component, but not in the security tree, and which IDs are in the security tree, but not in the Department component. You cannot implement tree-based security for new departments until you add them to your security tree. This audit ensures that you add each department in your system to the security tree.

Assigning Tree-Based Data Permission to Row Security Permission Lists

Access the Security by Dept Tree page.

As of Date for the Trees	The system will reference the trees that are effective as of this date when you select a tree setID in the Define Security Profile grid. Select a date in the future to reference a future-dated tree. For example, to use the department security trees that are current as of today's date, enter today's date in this field.
Refresh Tree Effective Dates	Select to refresh the trees listed in the Define Security Profile grid to trees that are effective as of the date in the As of Date for Trees field. Note. To ensure that your row security permission lists use the current trees you must enter the appropriate as of date and click this button whenever you create a more recent version of a setID's security tree.

Define Security Profile

Refreshing SJT_CLASS_ALL with Tree and Row Security Permission List Data

Whenever you add or modify a tree or add or modify a row security permission list on the Security by Dept Tree component you need to run the Refresh SJT_CLASS_ALL process to update SJT_CLASS_ALL with the new user security data.

You can access the new or modified tree on the Security by Dept Tree page before you run this process so if you are creating a tree and then using it on a new or existing permission list you only need to run the process once, as long as you refresh the appropriate rows.

See Running the Refreshing SJT_CLASS_ALL Process.

Assigning Role-Based Data Permission Security to Permission Lists

To assign data permission security to role-based permission lists, use the Security by Permission List component (SCRTY_CLASS).

This section discusses how to assign data permission security by field value to permission lists.

Page Used to Assign Role-Based Data Permission Security to Permission Lists

Granting Data Access to Permission Lists by Field Value

Access the Security by Permission List page.

Security Set

Select the security set whose data you want to secure with this permission list. To secure the data of more than one set, add more security set rows.

Security Type

For example, to give this permission list data permission access to people with jobs in location UK1, select the security set PPLJOB and the security access type Job Location. To select a location, you first must select a business unit, so in the Key 1 field, select the business unit GBR01 and in the Key 2, select the location UK1.

Add more rows to select more locations.

To use more than on access type, enter a row and select a different access type and select the field values for the type's security keys.

Note. Security types are not cumulative; they have an or relationship.

Refreshing Security Join Tables

To refresh security join tables, use the the Nightly SJT Refresh Process component (SCRTY_SJTDLY_RC), Refresh Trans. SJT tables component (SCRTY_SJT_RC), the Refresh SJT_CLASS_ALL component (SCRTY_OPR_RC), and the Refresh SJT_OPR_CLS component (SCRTY_OPRCLS_RC).

This section describes when to use the refresh processes and discusses how to:

• Run the nightly refresh process.

• Run the transaction security join table refresh process.

• Run the Refresh SJT_CLASS_ALL process.

• Run the Refresh SJT_OPR_CLS process.

Understanding When to Run the Refresh Processes

PeopleSoft HRMS core row level security has four refresh processes. Use the refresh processes to keep your security data up to date so that the system is enforcing data permission using the most current information.

Nightly Refresh SJT

Run the Nightly Refresh SJT process nightly to refresh the transaction security join tables. The nightly refresh process:

• Updates the transaction security join tables with any changes to transaction security data that bypassed the SavePostChange PeopleCode.

  The system automatically updates the transaction security join tables when you make and save a change on the transaction components, either by manual entry or a mass update that triggers the component interface. If you bypass the PeopleCode, you will need to capture the changes using a refresh process.

• Updates the security join table with future-dated security rows that have become current (when the current calendar date matches up with the effective date of the transaction record) because SavePostChange PeopleCode is not triggered when a future-dated row becomes current..

• If you are using future-dated security rows deletes the old security row and makes the future-flagged row the current row.

Run this process nightly for every security set you are using.

See Running the Nightly Refresh Process.

SJT Refresh

Run the SJT Refresh process to refresh the transaction security join tables.

You will need to refresh the tables using this process when you:

• Enable or disable a security access type.

  When you enable a security access type, you need to load the transaction security data for that type into the security join table.

  You need to run it when you disable a security access type in order to clear the security join table of the transaction security data. You won't compromise your security if you don't run it but you will improve performance by removing the unnecessary rows.

• Update the transaction components using a process that bypasses the component interfaces.

  The Nightly Refresh SJT process also captures this data but you may want to refresh the tables immediately rather than waiting for a scheduled run.

You can run this process for all security sets at once, individually, or by a smaller grouping of data.

See Running the Transaction Security Join Table Refresh Process.

Refresh Row Security Operator

Run the Refresh SJT_CLASS_ALL process to refresh SJT_CLASS_ALL.

You will need to refresh SJT_CLASS_ALL using this process when you:

• Modify a security access type.

  Modifications include selecting to use future-dated security rows or changing the job data security options.

• Create or modify a department security tree.

• Create or modify a row security permission list on the Security by Dept Tree component.

  Modifications include adding or removing data permission and refreshing the effective dates of trees.

See Running the Refreshing SJT_CLASS_ALL Process.

Refresh SJT_OPR_CLS

Run the Refresh SJT_OPR_CLS process to refresh SJT_OPR_CLS.

You will need to refresh SJT_OPR_CLS whenever you create or change the relationship between a user profile and a permission list with data permission. Run the process when you:

• Clone a user profile that has data permission.

• Add a row security permission list that has data permission to, or delete one from, a user on the User Profile - General page.

• Add a role with permission lists with data permission to, or delete one from, a user.

• Add a permission list with data permission to, or delete one from, a user-assigned role

Note. SavePostChange PeopleCode on the Security by Dept Tree component and the Security by Permission List component updates SJT_OPR_CLS when you add a permission list to either component for the first time. If you add a permission list to the user first, either in the Row Security field or by way of a role, and then add it to the Security by Dept Tree page or Security by Permission List page, you do not need to run the process.

See Running the Refresh SJT_OPR_CLS Process.

Pages Used to Refresh Security

Running the Nightly Refresh Process

Access the Nightly SJT Update page.

Set up this process to run every night shortly after midnight using a recurring schedule and leaving the As Of Date field empty. By running the process shortly after midnight, you capture the formerly future-dated rows that have just become effective.

Running the Transaction Security Join Table Refresh Process

Access the SJT Refresh page.

Refresh All Sets?	Select All Security Sets to refresh all security sets. Select One Security Set to refresh one security set.
Security Set and SJT Table	If you are refreshing one security set, select the set. The system displays the transaction security join table associated with the security set.
Refresh All Rows?	Select to refresh every row in the security join table. Clear to refresh select rows in the security join table. The system displays the Rows to Update field and grid.
Rows to Update	Select the rows to update. The options available are the ones you selected for the security set on the Security Sets component.

Rows to Update

The fields and buttons in the Rows to Update grid will vary depending on the rows you select to update in the Rows to Update field. Enter the rows of data you want to update.

For example, if you select Security Type in the Rows to Update field, select the security types whose transaction data you want to refresh.

Running the Refreshing SJT_CLASS_ALL Process

Access the Refresh Row Security Operator page.

Row Level Security Refresh

Running the Refresh SJT_OPR_CLS Process

Access the Scrty Oprcls Rc page.

Note. You can enable the USER_PROFILE message and the local subscription HCM_Refresh_SJT_OPR_CLS and the ROLE_MAINT message and the local subscription HCM_Role_Refresh_SJT_OPR_CLS to automatically update SJT_OPR_CLS. PeopleSoft does not deliver the system with these messages enabled.

See Using HRMS EIPs that Subscribe Locally.

The Refresh SJT_OPR_CLS process refreshes SJT_OPR_CLS as of the system date.

Querying Data Permission Security

To query data permission security, use the Security Data Inquiry component.

This section discusses how to:

• Find search views.

• Search security data.

• Search user security data.

• Search transaction security data in SJT_PERSON and SJT_PERSON_USF.

• Search transaction security data in SJT_DEPT.

• Search transaction security data in HRS_SJT_JO.

Understanding Data Permission Queries

The Security Data Inquiry component enables you to quickly and easily query aspects of your data permission setup in the event that you have questions or concerns about the implications of the access you've set up. The component consists of seven pages, each querying a different aspect of HRMS data permission:

Pages Used to Query Data Permission Security

Finding Search Views

Access the Find Search View page.

To review the view and SQL text used in a security search view indicate which search view to search by entering the:

• Component name.

• Market

• Menu name

For example, the security search view for the Personal Data component on the Administer Workforce menu, when accessed in Update mode, is PERALL_SEC_SRCH. This search view uses the security sets PPLJOB and PPLPOI and the transaction security join table SJT_PERSON. The view text has a special selection criteria to not return rows where the APPT_TYPE (appointment type) is equal to 1.

You can use this information to review the security data in greater detail. Perhaps to see what data is secured in security set PPLPOI or if the record a user is trying to access in this component has an appointment type value equaling 1 and that is why the record is unavailable.

See Also

Enterprise PeopleTools 8.45 PeopleBook: PeopleSoft Application Designer

Searching Security Data

Access the Display Security Data page.

Click the Clear All Entries button to clear the search value fields.

Enter Search Values

Note. If you want to review date permission security data for more than one security access type or for more than one of the additional parameters below, down the results in the Show Security Definitions and View the Transaction Data grids to Microsoft Excel and add to them as you perform your search.

To further refine the search within the selected security set or security access type, enter one or more values in these fields:

Expand the Show SQL group boxes in the Show Security Definitions group box and the Viewing Transaction Data group box to review the SQL used to query SJT_CLASS_ALL table and transaction security join table for this query.

See Understanding Data Permission Security for HRMS.

Show Security Definitions

Click the Show Security Definitions button to display the user security data that meets the search criteria.

The grid displays the permission list and the security key values that the permission list can access.

View the Transaction Data

Click the Show Transaction Data button to display the transaction data stored in the transaction security join table of the selected security set. The rows in the grid vary depending on which security set you are querying.

Searching User Security Data

Access the User Security Data page.

User ID

Select the User ID of the person whose data permission access you want to query. The system displays the user’s name and his or her row security permission list.

Click the Show Security Definitions button to populate the grids on the page.

User’s Data Security Roles and Classes – SCRTY_OPR_ROLE

Displays the roles assigned to the user and the permission lists with data permission assigned to those roles.

Note. The SCRTY_OPR_ROLE table only stores the roles that have permission lists with data permission. The grid does not list roles that do not have data permission .

User’s Data Security Definitions by Role Class – SJT_CLASS_ALL

Displays the data permission of the role-based permission lists associated with this user’s roles.

User’s Data Security Definitions by ROWSECCLASS – SJT_CLASS_ALL

Displays the permissions of the row security permission list assigned to this user.

See Also

Security Data

Searching Transaction Security Data in SJT_PERSON and SJT_PERSON_USF

Access the Find in SJT_PERSON page or Find in SJT_PERSON_USF page.

Note. The Find in SJT_PERSON_USF page does not have the option to search for POIs.

Select the EmplID of the person whose transaction security data you want to review. To limit the search to a single job data record, enter the employee record number. To limit the search to a specific person of interest type, select the type.

Click the Show Security Definitions button to populate the Security Data - SJT_PERSON grid with the transaction security data securing this person's record or records.

Security Data – SJT_PERSON

Click the Show Security Definitions button to populate the Security Data - SJT_PERSON grid.

The system lists the rows in SJT_PERSON that match the search criteria you entered. Review the security keys on the Security Key Data tab. Click the Special Job Flags tab to review special security job option data, such as if a row is a future-dated row or if it was created to enable home/host access or additional assignment access.

To review which permission lists have data permission access to one or more of these rows, select the rows and click the Show Permission Lists button.

Permission List Data

Click the Show Permission Lists button to populate this grid

For each security set and security access type, the system lists the permission lists that can access the transaction rows you selected.

To review which users are assigned to one or more of these permission lists, select the rows and click the Show Users button.

Operator Data

Click the Show Users button to populate the grid.

The system displays each user assigned to the permission list or lists that you selected and indicates if the permission list is assigned to the user as a row security permission list or role-based (role-class) and, if the permission list is role-based, which role it is assigned to on the user's profile.

Searching Transaction Security Data in SJT_DEPT

Access the Find in SJT_DEPT page.

Select the setID and department ID of the department whose transaction security data you want to review.

Click the Show Security Definitions button to populate the Security Data - SJT_DEPT grid with the transaction security data securing this department's record or records.

Searching Transaction Security Data in HRS_SJT_JO

Access the Find in HRS_SJT_JO page.

Select the ID of the job opening whose transaction security data you want to review.

Click the Show Security Definitions button to populate the Security Data - HRS_SJT_JO grid with the transaction security data securing this job opening's record or records.

Creating Data Permission Security for Managers

To create data permission security for managers, use the Create Manager Users and Sec. component (RUN_PER510).

This section provides an overview of data permission for managers and discusses how to create data permission for managers.

Understanding Data Permission for Managers

Use the Create Row Level Security for Dept Managers process to grant the appropriate data permission security access for department managers. The process will:

• Create a user profile if the manager is new and has no user profile.

• Create or update an existing row security permission list for each department manager, giving them access to the data in the departments that they manage.

• Delete the row security permission list for a user if it is obsolete (for example, the employee is no longer a manager).

The system uses the MgrID value from the Department Profile page (DEPARTMENT_TBL_GBL) to determine a department's manager. Managers will be given access to every department for which their ID is listed in the MgrID field.

Since you can list only one department manager per department, you will have to manually update the profiles of additional department managers. You can do this by assigning the row security permission list the system creates for the official manager to the unofficial manager's profile. Remember that the system will remove this list every time you run the Create Row Security for Mgr process.

Note. The Create Row Security for Mgr process uses the managers' EmplID as their user ID and uses the following naming convention for row security permission lists: HCDP_DEPT_MGR_[manager's EmplID]

Before You Begin

The Create Row Security for Mgr process uses tree-based security to create row security permission lists for managers. Before you run this process, you must have set up a department security tree.

The hierarchy rules of the department security tree apply to these permission lists. If a manager's department has departments reporting up to it on the security tree, the manager will have access to the people in those departments as well as his or her own.

Refresh User Security Join Tables

The Create Row Security for Mgr process creates and modifies row security permission lists and assigns row security permission lists to, or deletes them from, user profiles. Both of these actions require that you:

• Run the Refresh SJT_CLASS_ALL process to refresh SJT_CLASS_ALL with the row security permissions list data.

• Run the Refresh SJT_OPR_CLS process to refresh SJT_OPR_CLS with the new user profile and row security permission list pairings from the User Profile - General page.

The system will not enforce the new data permission set up by the process until you run these refresh processes.

See Running the Refreshing SJT_CLASS_ALL Process.

See Running the Refresh SJT_OPR_CLS Process.

Pages Used to Process Row Security for Managers

Processing Data Permission for Managers

Access the Create Row Security for Mgr page.

As Of Date	Select the date as of which the row security list permission list should become effective.
User ID	Select a default User ID. The system will base the new user IDs on this default.
Create User as Locked?	Select to lock all the new user IDs.

The Create Row Security for Mgr process consists of two PeopleSoft Application Engine processes and one SQR report:

1. HR_PER510.

   Determines the changes required in order to maintain data-permission for department managers.

2. HR_PER510_CI

   Applies to the database the changes determined by HR_PER510.

3. SQR report PER510

   Lists the changes determined by HR_PER510 and applied by HR_PER510_CI and their status.

Note. You must select each process individually and wait for it to complete successfully before selecting and running the next process.

Creating and Locking User IDs

To create and lock user IDs, use the Create Users component (CREATE_USERS) and Lock Users component (LOCK_USERS).

This section provides an overview of security for user IDs and discusses how to:

• Create users.

• Lock users.

Understanding Security for User IDs

Create user IDs for your workforce using Group Build and the Create Users page. Create and populate a group using Group Build and then use the Create Users page to create User IDs for each group member.

Use the Lock Users page to lock user IDs until you are ready to use them.

See Also

Setting Up Group Definitions and Security

Setting Up and Working with Groups

Common Elements Used in This Section

Pages Used to Create and Lock User IDs

Creating Users

Access the Create Users page.

User ID	Select a default User ID. The system will base the new user IDs on this default. Once created, you can modify individual profiles on the User ID pages. If the user ID upon which you are basing the new users has data permission, you will need to run the Refresh SJT_OPR_CLS process. Otherwise the system will not recognize the data permission on the new user profiles. See Running the Refresh SJT_OPR_CLS Process.
Create User as Locked?	Select to lock all the new user IDs.
Create User IDs	Select to run the process.

Locking Users

Access the Lock Users page.

Lock Group	Click to run the process and lock the user IDs of the entire group.
Unlock Group	Click to run the process and unlock the user IDs of the entire group.

Activating Additional Security for Recruiting Solutions

To activate additional security for PeopleSoft Enterprise Recruiting Solutions, use the Recruiting Row Level Security component (HRS_SEC_TBL).

This section provides an overview of data permission security for job openings and discusses how to activate additional security for recruiting solutions.

Understanding Data Permission Security for Recruiting Solutions

You can secure access to job openings at three points. The following people have access to job openings:

• The creator of a job opening, as indicated on the Create New Job Opening component (HRS_JO_LAUNCH).

• Users with standard data permission access to the transaction data in the job opening.

• The recruiting team.

Recruiting Team Access

In some circumstances, the members of your recruiting team may not have standard data permission access to the transaction data in the job opening. To set up data permission to job openings for recruiting team members:

1. On the Security by Permission List page:

   1. Select the security set RSOPN.

   2. In the Security Type group box, select the type 031 (Recruiting Team).

      The system displays EmplID for the Key 1 field. Leave this field empty. This security access type has hardcoded key values so you do not need to specify any EmplID values.

2. Assign the permission list to one or more roles and assign the roles to those users who need recruiting team access.

3. Assign users to a job opening in the Assignments group box on the Job Opening component (HRS_JOB_OPENING).

When a recruiting team member accesses the job opening, the system will determine if the user has a permission list with recruiting team access and if he or she is listed in the assignments group box when granting access to the opening.

See Granting Data Access to Permission Lists by Field Value.

See Creating Job Openings.

Applicant Data Access

The data of applicants associated with job openings is available to those with access to the job openings. Applicants not assigned to a job opening are available to anyone with access to the applicant components. To restrict access to applicant data use application security to restrict which users have access to the applicant components.

Recruiting Administrator Privileges

You can also grant recruiting administrator privileges to row security permission lists on the Recruiting Row Level Security page by selecting the Recruiting Administrator check box. Privileges include being able to change the status of draft applicants or overriding the status of a job opening.

See Also

Entering Applicants

Managing Job Openings

Page Used to Set Up Security for Recruiting Solutions

Setting Up Security for Recruiting Solutions

Access the Recruiting Row Level Security page.

Note. You do not need to run the Refresh SJT_CLASS_ALL process when you modify a row security permission list on this page.

Setting Up Security for Local Functionality

This section provides an overview of security for local functionality and discusses how to:

• Grant access to local country functionality.

• Restrict access to local country functionality.

Understanding Security for Local Functionality

Local functionality refers to functionality that is specific to a country. Country-specific functionality is in collapsible sections marked by the country’s flag, in the global components. To grant access to local components, you use component permission. To grant access to the local functionality on global components, you use the Global Panels page in addition to component permission.

To grant users access to local country functionality on the global menus:

1. Use the Country Specific - Installed HR Countries page (INSTALLATION_SEC) to select the local country functionality that is installed as part of your PeopleSoft HRMS system.

   If you do not specify a country here, its local functionality can’t be accessed.

2. Grant the primary permission lists access to country-specific functionality using the Global Panels page.

3. Assign a user access to a primary permission list containing access to the countries that are required by the user on the User Profile - General page.

See Also

Enterprise PeopleTools PeopleBook: Security Administration

Pages Used to Grant Access to Local Country Functionality

Granting Access to Local Country Functionality

Access the Global Panels page.

Primary Permission List

Users assigned to this permission list can access the country-specific sections on global components of the countries that you indicate on this page. Primary permission lists are defined in the Permission List component. Users are assigned a primary permission list on the User Profile - General page.

See Setting Up Primary Permission List Preferences.

Restricting Access to Local Country Functionality

Access the Global Panels - Excluded Panelgroups page.

Component Name

Select the name of the component for which global functionality for this country is being restricted. For example, to restrict access to Italian-specific functionality in the Personal Data component, select the Personal Data component.

Modifying Data Permission Security

This section discusses how to:

• Modify security for hiring and transferring people.

• Allow people to update their own data.

Modifying Security for Hiring and Transferring Workers

PeopleSoft HRMS enables users to assign workers into departments that they can’t access for updates. To prevent a user without access from transferring a worker into a department, PeopleSoft HRMS contains a view, DEPT_SEC_VW, that shows only the department IDs that the user is authorized to access.

If you use this view, you need to create a class of users who can access all departments so that they can perform transfers. Also, update the Job record definition in PeopleSoft Application Designer so that the prompt table for the DEPT_ID field is DEPT_SEC_VW. You may also want to change the security view on the DEPARTMENT_TBL component to this view if you want users to only be able to access departments they have access to. This is defined using the Department Security Sets.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Application Designer

Allowing Workers to Update Their Own Data

PeopleSoft HRMS doesn’t allow users to update their own data except in the self-service internet applications. However, sometimes you might want them to update some of their own data in other components. To allow users to update their own data, you implement the PeopleCode function Allow EmplIDChg (allow emplID change). The function looks for a single Boolean parameter. When the parameter is set to true, workers can update their own data; when it is set to false, they cannot.

For example, to allow workers to change their own personal data, you enable the PeopleCode function for PERSONAL_DATA, the underlying record definition for the Personal Data component. Then workers can change their personal data, but not their job information.

To enable the Allow EmplIDChg function:

1. Open the record PERSON in PeopleSoft Application Designer.

2. Open the RowInit PeopleCode on the EMPLID field.

3. Insert new code after this line:

   /************ START OF ROW INIT PEOPLECODE *************/

4. Insert a row and enter the following code after the first line (a comment) of existing code:

   if %Component = Component.PERSONAL_DATA then
       AllowEmplidChg(true);
   end-if;

5. Save your changes and exit the PeopleCode page.

Workers can now update their own data using the Personal Data page.

To allow workers to update their own data in other places in PeopleSoft HRMS, enter this PeopleCode function in the underlying record definition for each page where you want to allow updates.