You should be able to create a link on the end user in the new incident/request window. Then they can enter the end user and if the information needs to be updated they can click the attribute link and edit. Of course you will need to modify the privileges to give them access to do that.
1 of 1 people found this helpful
What you could do is to create a workflow (or modify your current one) to launch a window with details you'll need (User Information). Add a hyperlink to the label name next to the End User field. When clicked this will take you directly to the users window to retreive information OR just add the information fields you need from the End User to the form itself. Save that. Then include an action for "Is Incident" or "Is Request". If it is "Is Incident" just let it go along in your Incident workflow. However, if it's a Request, have the "Is Request" action create a new Request using the default Request workflow within the system.
Maybe I am misunderstanding what needs to be accomplished. If so, please let me know.
Our way of handling this in our version of the OOTB database is to use the Call Domain to log the top level details. Then the process gets the analyst to decide what type of call it is and then a request/change/incident/problem is generated using an automatic action to create those specific domain processes with copies of the relevant data copied across.
It's not the only way, but it is pretty clean.
Another way is to have all your processes in one domain and then use the Reinitialise action to switch from one process to another.
Another way is to have 'convert to incident', 'convert to change' as actions in the request process.
Ideally reinitialize would allow you to also jump across different domains, but it doesn't. If an ER were to be raised for this (if one hasn't already been) then I'd vote for that!
I'm sure I posted this before :-)
I don't use the Request domain at all - for exactly the reason you state.
I only use the incident domain to log all my tickets, be they service requests or incidents. I use the category to then determine if its a service request or an incident. The Incident domain is just a label - the enduser / analyst does not need to know about the backend stuff and how it all sticks together.
I'm happy to show you how my stuff works - let me know if you want to get in contact
if you want to stick with just using Incident originally you could modify your workflow to check for the category and if it equals request, have the auto action to create a request with the details from the Incident then close the ticket automatically with a "Request Raised" end state. This would just be to note that this Incident really got created as a Request.
Dave, there is an ER I did for the reinitialize some time ago.
Thanks for all the input everyone. They were all considered but the winner is (drumroll please..................) dmshimself.
I went with his option because it is quick to implement and is exactly what the client wanted.
So lucky! Hahahaha. Glad you were able to get what you needed.
Result!. If you ever need someone to come over on a fully funded, fact finding research mission, I'm your man :-)
Cheers Jamie - I hear seaching for ideas in the community might be getting a bit of a tweak up at some point. Consider my vote already added