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.
Showing posts with label Dynamic Groups in Time and Labor. Show all posts
Showing posts with label Dynamic Groups in Time and Labor. Show all posts
Monday, February 21, 2011
Sunday, November 1, 2009
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.
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.
Subscribe to:
Posts (Atom)