Welcome with your not so newbie question at all!!
You can not turn a item in your change module into and item in your indicent module into a item into your request module. You can however create a new change from an incident and copy the information over. This means that you then end up with a new reference, and the Change and the Incident are linked.
How I dealt with this was to use 2 domains - the Change Managemetn and Incident Management modules in Landesk. Change to raise change requests - and sometimes these are raised from within an Incident by using the Create Change Request action. This works for me because in my head an incident is something that is broken, and the change needs to be done / created to fix whatever is broken, so that works for me.
I use Incident Management module in landesk to raise all tickets coming in through the Service Desk - in my case that would be incidents as well as service requests. I differentiate between them based on categorisation. Each category is either a Service Request or an Incident ticket (this also drives the Service Level Matrix).
If you use Incident Management module / domain / whatever in landesk to process both Incidents and Service Requests you can make the one into the other by changing the categories.
I like using only 1 process to do both service and incident requests and build the flexibility in the process to deal with the different paths you want things to take.
If you use different processes, you would have to switch process (Reinitialise action) if you want to change an incident into a service request, and this would mean you need to design it such that you have a status which is used in both processes where you can get this action to switch over.
The big downside of this, is that you won't be able to use the pre-built content from the Request Module, and you will need to rebuild the content in the Incident domain - but hey that gives you the oppurtunity to really get to grips with the design elements of Landesk (the full administrators training course / boot camp is advisable)
Thank you for your reply.
We will be adding the change and problem management modules on soon.
One question is what are you referring to with the pre-built content Request Module? Is that a OOTB module in the latest versions? I have done the Admin bootcamp which was for v7.5, however we do not recall a request module, nor was it mentioned how best to deal with requests separate from incidents.
Thank you for your help.
Yes there is a request module, and they nice people at Landesk ahve built the start of a service catalogue and request processes.
I don't think there is a "best" way to deal with incidents vs service requests. Its up to you to decide how you want to use the tool - and which bits of functionality you can live with and which you don't want to compromise on. Your working practises are always going to need to adjust to work alongside what you can and can't do in the tool.
I think one of the challenges here is that a single Incident might result in one or more Requests if you are to map onto the Request and Service Catalogue functionality provided in the OOTB. For example the user asks for a mouse, mouse mat and Adobe reader software in a single email; well that needs to translate to 3 Requests because each may have different authorisation and fullfilment (for example software may be automatically installed via MAP integration with LDMS) paths and possibly even be serviced by different processes.
I'd thus say, though it's not ideal, that the "Create Request" action in Incident is probably the safest method as you can run multiple times if more than one item is being requested.
What I want to see in future is better support for the creation of many-to-many business objects in Business Object Designer; at the moment you can only create against cat/ord/ref lists. If we could create against other objects (ie collections to Incident) we could use a multiselect listbox pointing to this object so that you could review the Incident, select one more Service CI items (used for Requests/ServiceCat) and then use an automatic action (with all collections checkbox checked) to automatically spawn the necessary child Requests from the originating Incident.