Understanding Row-Level Security
To establish security within the PeopleSoft application, decide what level of security to establish throughout the system, which key fields to secure, and whether security will be handled through user IDs or roles. Security can restrict individual users or roles from specific rows of data that are controlled by such key fields as setID and business unit. You can also limit user access to a specific subset of rows. For example, user ID security can allow the law school to access only the item types assigned for the law school. Or, if you have a group of staff in the registrar's office, you can add them all to a role and use role security to enforce the appropriate limits on their system access. A user may be assigned to one or more roles, providing considerable flexibility to access necessary resources. As a result, a user who is linked to more than one role can use the menu items assigned to any of those roles. Some security attributes—such as row-level security—cannot be defined by combining roles. Only one role can be used for this purpose. In you designate row-level security for a user by selecting a role. The row-level security attributes for the role that you select then become the security attributes for that user.
Because various combinations of security are possible, it is important to understand the effects of row-level security when you use this mix of system security options and roles:
| System Security | Role of User ID | Row-Level Security |
|---|---|---|
|
No security |
User ID is not linked to a role. |
Not applicable; each user can access any object because there is no security implemented. |
|
User-level security |
User ID is not linked to a role. |
Defined in the application by key field security. |
|
Role-level security |
A user ID is normally assigned to a row-level security role. It is possible, however, to link a user ID to multiple roles, but not when you specify row-level security. |
Defined by a row-level security role. If a user ID is not assigned to a row-level security role, then that user has access to menu items, but does not have access to any application pages with key fields enabled for row-level security. |
You must set up which users or roles have access to specific business units, setIDs, and any other key fields that the application requires. For example, you might permit access to only one business unit for a certain role of users.
When a user in this role enters data, the system requires a business unit because this is the primary key for data related to the business unit. The available selections on the prompt list for this user include only the business units for which the user has been granted authority. What appears in the prompt list is data that has been filtered through one or more levels of security.