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.
1 comment:
An excellent point, however the other side of that argument is where a customer doesn't want the overhead of managing two sets of security - especially where the approvers are the same as the reporting managers (so they could use reports to) - it would be nice to have that option as well as the option to construct a separate framework.
Post a Comment