Hi , I recently started working on an application which dint have the most optimized design. In current design , the class names do not reflect the organizational hierarchy , so we have to change the class name of the worktypes.
Also all worktypes seem to be defined as class groups. Hence we want to club them at work level class group and define all work type classes as belongs to the class group,
This application is currently in Production and hence these changes might impact the work objects and the linked tables like assignments , history , attachments etc.
Has anyone experienced this scenario and are there any best practices to handle this ? Can we update the pzinskeys in assignment objects to reflect the new class group etc.
I agree with Phani. I would caution against changing the underlying class structure of your production items. There are just too many opportunities for something to go wrong with your production data. Certainly, if you refactor your class structure, you can close off all avenues from the portals for making new items in the old class structure and let the existing ones run their course. Having this parallel data structure will make reporting challenging, but otherwise, I can't think of any obvious problems you'll run into.
If you change the class of in flight items, you don't just need to update the pzInsKey, you'll need to update all the class references on the work objects, on the assignments, on queue items, on SLA items, on link-attach items, on history items. I'm sure I'm forgetting several others and of course if you get any wrong, that will result in problems of varying degrees of difficulty to debug.
Currently we have 2 implementation layers , one for US and one for other regions. We want to remove those layers and put all of them as subclasses under one implementation layer inheriting from one framework layer,
With this a single user can access different regions based on his skillsets and access roles. Also the WOs are currently being saved in different tables and we want them to go into the same table based on class group for efficient search.
If we dont touch inflght cases , how will users be able to search for them especially when they are in a different implementation layer? Let me know your thoughts.