Peoplesoft 9.1 - Time and Labor: Dynamic Groups are dead, long live Dynamic Groups!

The pronouncement of the title does not hint that Oracle has taken away the definition of Dynamic and Static groups from Time and Labor, but it's significance is greatly reduced with the introduction of approval workflow engine in 9.1 and by the improved row level security framework in 8.9. In pre-8.9 days, the entire row level security in T&L used to be driven by Dynamic Groups and it used to be a design nightmare to arrive at the best security strategy as various modules drove security differently (at that point of time, frankly dynamic groups offered a pretty flexible way of driving security as it's design is distantly similar to the current robust row level security structure). But with the introduction of the very flexible and configurable row level security structure in 8.9, the need to use Dynamic Groups for row security in T&L, almost died down and now with the introduction of the AWE framework in 9.1 - I really do not see any more need to use Dynamic Groups for security purposes. This is more a message for current 8.9 and 9.0 Time and Labor implementations - you should discourage the use of T&L security driven by Dynamic Groups as much as possible and adopt the HRMS Row Level security in Time and Labor. The focus of Oracle has been towards adopting common frameworks across various modules for driving aspects like Security, Approval, Delegation etc. and it will be great to keep that point in mind while designing solutions in these areas if you are on versions lower than 9.1/9.0. So do we need Dynamic Groups anymore in Time and Labor? There are two areas where the use of Dynamic Groups are significant: 1. As a parameter for running the Time Administration process. Dynamic Groups will still remain to be a very useful run control parameter for running the time administration process. 2. Grouping approvers together for use in some of the T&L specific AWE definition Ids. This is a change introduced in version 9.1 in the definition of a dynamic group. A new field called 'TL Approval Group' has been introduced in 9.1 as shown below:

When a Dynamic/Static group is selected as a 'TL Approval Group' - it will be used only as a group of potential approvers and not for row security. Row Level security cannot be attached to these groups and they can be used in the AWE Definition Ids for Time and Labor to specify the user list that approves time. Posted by HRoi Consulting at 7:48 PM 2 comments: Links to this post Email ThisBlogThis!Share to TwitterShare to Facebook Labels: AWE in Time and Labor, Dynamic Groups in Time and Labor, Peoplesoft 9.1, Time and Labor security

Saturday, July 4, 2009

Search Page security in Peoplesoft Time and Labor
I had detailed how Time and Labor security works in a previous post and today I want to touch upon how customers can configure the security on the Manager Self Service and Administrators for Time and Labor. Currently, there are three distinct ways of configuring search page security in Peoplesoft (including Time and Labor): 1. Use the highly robust and modified Core Row Level security, where any level of flexible security definition can be created with the introduction of Security Access Types in Peoplesoft HRMS 8.9. 2. Use the Direct Reports functionality which most of the MSS pages of Absence Management and e-Performance make use of. This feature will provide a standard page containing the direct reports of a user. 3. Use Time and Labor security to show to users employees in the Static and Dynamic groups that they have access to. (You can also enforce search security through Search Init peoplecode, but this approach is highly discouraged.) Most organisations will be designing their search security by making use of the new Row Level security design and in this context, a debatable question is whether we need to use Time and Labor security itself? Also, a number of people ask whether we can use Row Level security for the Time and Labor search pages, or whether it can make use of only Time and Labor security. The answer is provided by the below decision chart (click on the picture to see a larger view):

All the Search pages in Time and Labor is flexible enough to utilize both Time and Labor security and core Row Level security. This decision depends on how the rowsecclass attached to a user is configured. If the rowsecclass is attached to any Time and Labor group (this can be found from the table

PS_TL_GRP_SECURITY), then the user will be able to see only employees belonging to the groups the user's rowsecclass has access to. On the other hand, if there are no Time and Labor groups attached to the rowsecclass of the user, then core row level security available for the user will be used to fetch the employees. What should be the optimum Time and Labor search security strategy? If your organisation is using other Peoplesoft HRMS modules then it is best to utilise a common security design for all the modules. So I will always suggest using row level security for Time and Labor pages and not to configure any extra Time and Labor groups for the purpose of row level security. Time and Labor groups can be created for the purpose of batch processing of employees. It is very useful to create Time and Labor groups and use the group as an input parameter for the Time Administration or Batch Approval or Batch Schedule Assignment processes. Note that a Time and Labor group can be defined without linking it to any row security class and used solely for the purpose of grouping employees together. Posted by HRoi Consulting at 11:17 AM 3 comments: Links to this post Email ThisBlogThis!Share to TwitterShare to Facebook Labels: Peoplesoft core Row Level Security, Peoplesoft HRMS, Peoplesoft Time and Labor, Time and Labor search pages, Time and Labor security

Thursday, July 10, 2008

Time and Labor Security demystified
Security in Time and Labor is an area that needs more clarity to most new implementors. Almost every team I have consulted for has had the question 'how do I ensure that the employees reporting to a manager shows up in the manager self service pages of Time and Labor?' This post aims at being a guide towards designing the T&L security setup. T&L Security is primarily concerned with ensuring the correct access of reportees to managers as well as controlling the dates which are open to any employee to report time. We are more concerned with the first case here. Security in Time and Labor is a two step process - 1. Grouping the employees reporting to a manager/HR administrator together and 2. Granting access to the correct groups to the respective managers. To group employees together T&L has a powerful feature called Dynamic groups (there is another category called static groups which are not practically used and thus does not deserve mention here) which is similar to the Group Build feature in core HRMS. A Dynamic Group constructs a group of employees based on an SQL selection criteria (for example - select emplid from ps_job where reports_to = ) and is thus truly dynamic. The Dynamic Group once created has to be refreshed on a daily basis to ensure that the group includes all eligible employees. The illustration below shows how a dynamic group can be created by defining the appropriate SQL eligibility

criteria. After the group has been created, the next step is to assign this group to those managers/administrators who need access to the same. Access in Time and Labor is controlled by an Operator's ROWSECCLASS. So the groups will have to be linked to the eligible ROWSECCLASSES to enable access for managers to their reportee's data. The illustration below shows how a group can be linked to a ROWSECCLASS. Keep in mind that one group can be linked to multiple ROWSECCLASSES and one ROWSECCLASS can be linked to multiple groups.

Now coming to the important question - how does a manager get access to employees under him? Let's just look at the below process flow for that: 1. Manager logs in with his/her Operatorid. 2. The ROWSECCLASS of this Operator is fetched from PSOPRDEFN. 3. The TL_GRP_SECURITY table is queried to get all the groups that this ROWSECCLASS has access to. 4. The TL_GROUP_DTL table is queried to get all the EMPLIDs part of each group fetched in step 3. 5. The employees fetched are displayed on the MSS pages. This is an extremely simplified definition of what actually goes behind the scenes when the system tries to retrieve the employees in a T&L MSS page. So to ensure that a manager has access to his reportees ensure the following: a. All the reportees are part of atleast one Dynamic Group. Query TL_GROUP_DTL to get the groups of an employee.

b. The manager/administrator has access to those groups. Query TL_GRP_SECURITY to get all the groups that a particular ROWSECCLASS has access to. c. Schedule the Dynamic Group Refresh process on a nightly basis to ensure that the dynamic groups are up to date. Caveat: The above process requires the creation of a large number of ROWSECCLASSES and Dynamic Groups to maintain exclusivity of employee access to managers. Organisations that follow the above approach will need to custom create a program thatwill create new ROWSECCLASSES when a new manager is hired and programatically create dynamic group and assign security to that dynamic group for the new ROWSECCLASS created. This complex process can be circumvented by customising the code behind the 'Get Employees' button present in all T&L MSS Employee Search pages. The approach would be to create a single Dynamic Group and enroll all employee in the same and give access to all managers/administrators for that single group. Customize the Peoplecode behind the Get Employees button to fetch only those reporting to the manager from the entire set fetched by the vanilla logic explained above. The customisation has to be done in FUNCLIB_TL_CP.MGR_SS_FUNC.FieldFormula event.

T&L security design is an area where we see lot of questions being raised, especially considering the integration of AWE in v9.1. If you have specific questions on this, reach out to me @ jiju@hroiconsulting.com