How would you implement row level security in Peoplesoft CRM?

Data or Row Level Security : This is a critical component focusing on what data would be visible for the users.
The Data visible to the users would be dependent upon Row Level permission lists.
This may be defined at various levels based on Department, Position, Region etc.
With the new releases there is flexibility to implement more than one level of security.
Earlier versions only supported Department Tree based security.
You can design special types of SQL views -security views- to control access to individual rows of data stored within your application database tables.
Your PeopleSoft applications are delivered with built-in, row-level security functions, tailored to that specific application.
For example, in PeopleSoft HRMS, we provide security tables that enable you to restrict operator access to employee rows according to organizational roles, or to permit an operator to view and update rows for employees in their department only.
Then to get the security down to the operator ID level instead of the operator class level, there are steps defined in Designing Your PeopleSoft Human Resources System manual under Using Operator IDs for Employee Data Security.
Changing operator class to operator ID Steps to implement Organizational Security by OPRID:1) Delete all entries for each OPERClass/OPERID in Security Tables.2) Run SECVWTRE.WT to load the SQL text for the security views(only needs to be performed if organizational security has been turned off).3) Run SECBYOPR.WT to change the view text of Oprdefn to select based on Oprtype of0 (instead of1 for operator class security.4) Add the field OPRID in place of the OPRCLASS field in the search views and make it a key item.5) Recreate the search views and the Oprdefn view.6) After the departments have been loaded, create a tree with effective date the same as the effective date for the departments equating the node with the department ID.7) Run PER505 to update the effective date of PS_R_PER505.8) Update the security tables to show which departments each operator or operator class has authorization to read/write.9) Run PER505 if any changes are made to the tree structure.
This will update the security tables established in6 to reflect the changes to the hierarchy.
To switch from Operator Class to Operator ID security:1) If you have department security in place for an OprID or OprClass delete these entries now, they will not be available after updating the Oprdefn view and may give inaccurate results if left in place.2) Run SECBYOPR.WT to change the view text of Oprdefn to select based on an Oprtype of0.
(To switch back to Operator Class security run SECBYCLS.WT to switch the view text of Oprdefn to select based on an Oprtype of1.)3) Recreate the Oprdefn view.4) Change each search view and replace the OPRCLASS field with OPRID field and make OPRID a key field.5) Set up the tree and department security as in the steps5 through8 under Operator ID security setup.
Change Standard Search Record into OPRDEFN_DEPT.
The view text in OPRDEFN_DEPT should look like this: SELECT A.OPRID ,A.EMPLID FROM PSOPRDEFN A WHERE A.OPRTYPE=0 You must rebuild this view.
-Thanku

Thank you Khadijah for provide me an opportunity to answer this question and many apologies for the delay reply…..
I have worked on PeopleSoft HRM and we define create row level security and connect it with Dynamic Group (by using security by group) option.
This helps us in giving access to multiple users who are in same group and required same level of access/security.
I am not a ERP programmer but I have been working as a functional lead in my previous and current roles.
If you need more details, then please refer this question to computer programmer (ERP Technical lead).
Thank you