I am just starting out on the road of creating Service Requests to handle many different business processes in self service on service desk 7.7.1.
LANDesk created a generic service request process intended to handle all standard requests - currently there are over 100 business requirements in the pipeline with more to come.
The suggested approach from LANDesk is to have a single window linked to the generic lifecycle and use a window calculation to create a dynamic window with the relevant attributes displayed and unused ones hidden. Each business process could require 30 attributes which means that I am looking at over 3000 attributes on the window being controlled by a single window calculation.
I am only working on a single business process at the moment till I figure out how to get this done. This process is for Change to Terms and Conditions of Employment which is sub divided into 7 categories
- Change Grade or Job Title
- Change Location
- Change to Job Share
- Change Working Hours or Weeks
- Extend fixed term appointment
- Make Fixed Term Appointment Permanent
- Soulbury Only: SPA points
The window has a number of common fields required to match and drive the lifecycle e.g. user details, managers for approval, request status. Each activity has its own group box with the relevant attributes within it. To help put into context I have included these screen dumps.
- TCEDesignView.png the design console view displaying all attributes
- CGTSelected.png a web view with the Change Required trigger field set to Change Grade or Job Title and so the entry fields for those attributes are displayed in the matching group box.
There are a couple of minor issues readily apparent
- window layout - the web grid has expanded the left hand column
- descriptive label - each group box has a descriptive label which cannot be addressed and hidden dynamically so the group boxes are being kept visible
Any suggestions on how to best overcome these would be welcome.
The attached selectorcalc.txt shows the window calculation code being used. Basically I construct a string with all of the attributes and properties listed using placeholders for turning them on and off. For the category selected the placeholders for the relevant attributes are set so hidden=false and mandatory=true while the remaining fields are hidden=true and mandatory=false.
I would welcome any comments/suggestions/alternatives on achieving the same result.
My main issues with this, however, are scalability and performance because as mentioned there could well be over 3000 attributes on a single form. This would require an excessively large string to be constructed which I am sure will have significant performance impact or even break due to a size or memory constraint.
My intial reaction is to have a separate window for each business process but this will mean cloning the lifecycle which will introduce extra management complexity if the lifecycle is ever amended - which is highly likely in the early days.