Dynamic Groups in T&L: Going beyond direct reports security

In a post sometime ago, I had made a blatant statement that the utility of Dynamic Groups in Time and Labor was reduced by the introduction of a flexible core HR row level security definition as well as the adoption of AWE in version 9.1. As I have been making some analysis on my current assignment, it has become clear to me that my initial analysis was premature! I had always wondered why Time and Labor adopted a security structure that was way different from all other modules in PeopleSoft HCM. While most modules have gone towards adopting the direct reports functionality for Manager Self Service pages, Time and Labor stuck to it's ground using core row level security and T&L dynamic groups. What could have been the rationale behind this design of the product and why does T&L still use Dynamic Group security when no other module in HCM uses the same? The answer could lie in the fact that time management as a business process is not done by the direct supervisor/people manager alone and thus cannot use the same security logic used by other Manager Self Service components. Let's take an example. In a manufacturing environment, shift management is mostly done by shift supervisors/shift leaders who may not necessarily be in the managerial job family. On the other hand transactions like performance appraisals, initiation of promotion, transfer and even absence approvals are traditionally done by a people manager or an employee falling in the managerial job family. The supervisor id assigned at the job data level or the reports to position used in job data is mostly that of a people manager. So, if T&L also adopted the security definitions of other modules, it would have greatly constrained the flexibility of the module. So, I have to agree that Dynamic Groups give an extra layer of flexibility to the T&L product in terms of defining the security and goes a long way in satisfying the requirement of businesses to have non managerial employees manage shifts and approve worked time.

Learning of the day: Group Build and Future effective dates

Group Build functionality in PeopleSoft HCM can be used to group employees together based on flexible parameters. But, one limitation of Group Build is that it does not consider future effective dates, even if the parameters used to build the Group is designed to return future effective date. As mentioned in support.oracle.com (or customer connection or metalink, whatever you might want to call!), Group Build is designed to only consider current and historical effective dated rows. This is an important point to keep in mind while designing any process that involves Group Build - "Group Build does not consider future effective dates".