7.4 gives you what you are after I think. You can use reinitialise as an automatic action in the process and use that to select the process you want.
Hi Dave, is there a way to reinitialse to a different module. Just thinking that an incident can be raised, but it should be a request. The workaround at the moment is that I have an action "create request" which copies the information to a child request. However the incident will be logged.
I don't think you can - doesn't appear to be an option on our version (7.3.2) and suspect the fact its a whole separate 'domain' to move from Incident to Change would mean its unlikely.
Could be wrong, though...
David is spot on. You can arrange for your incident to be automatically closed once the request/change/... has been copied and created. Another alternative design would be to log everything initially in the call domain and then have a triage process which allocates it to an incident/request/change/whatever. This might sound attractive but I've found you always need to allow for humans making mistakes or changing their minds :-) so having an action to switch a process from one domain to another is nearly always needed.
By linking them you have a history of how you got here. This allows you to try and work out why incidents of such and such a type come in which turn out to be service requests and might drive you back to the terminology used on a portal or the language/terms used when talking about IS to the rest of the business.
Sadly from what I have experienced you cannot link the call domain to any other process domain as there are no linking business objects to do this.
However I have similar to what you describe in our system, where everything starts its life in a incident process instead and then making decisions on where to go based on the category that has been set. Then in order to ensure that anything in this switchboard process is not accounted for in analyst workslists, I simply add a criteria to the queries to show all incidents apart from those in the switchboard process.
This works very well and has helped getting the rate of tickets being placed into the correct process up!
The OOTB design doesn't have those linkages, but you can add them. The key here is that you are not creating linking objects in the sense the product sometimes calls them. These are the full many to many relationships between domains and indeed you cannot create those. But the good news is that to create an incident/request/change/... from a call you don't need a many to many. Just add your incident object to the call object will be enough.
I've seen many ways of designing this triage method and using the incident domain is also perfectly respectable. I tend to find many service desks have a greater number of requests than incidents, so there is a case to be made to start from request.
Call is a handy domain when you don't know where to start :-)
Good suggestion with regards to Request. You could almost say that each query to the Service Desk begins as a request for service - one of which is Incident Management!
The objective of course is to ensure we do not have duplicate records for the same thing. However starting off as a request for service we can easily filter them out. The other idea was a tick box, but am liking the request route.
Point taken, I think when investigating this I should not have tried to overcomplicate things and then I would have seen the simple answer!
And quite right you are about more requests than incidents, the triage process has proved this to my organisation and it is quite an eye opener for managers! It actually means in a way, that the IT infrastructure is not that bad, its just that customers want lots of changes and extras hehe!
There are many ways, many ways :-)
But I'd still like to be able to reinitialise acorss domains as well :-)
Lot's of customers are asking me for initialise across domains too.
Is there an ER out there for this yet>?