Idea Details

Easily Convert Incident to Request, and vice versa.

Last activity 05-29-2019 07:39 PM
Anon Anon's profile image
04-07-2011 11:28 AM

In the environment I work in, requests are often open under incident records, and vice versa.  Part of this has to do with common behavior of starting a phone call as an incident ticket, while at other times a 2nd level support analyst would find that a reported incident really should be a request.  Can there be an easier way to to simply convert an incident to a request, or a request to an incident.  I know this can be programmed using a self-hosted implementation of Service Desk, however we are transitioning to Service Desk On Demand and it is not possible.


Comments

01-03-2017 06:11 AM

have a look in my response to your question:

convert request to incident and viceversa 

01-03-2017 05:41 AM

Does any one have step by step code for this customization

09-02-2016 01:44 PM

I solved this way 

 

i added this code in my htmpl  file 

<PDM_MACRO name=dtlDropdown hdr="Tipo de Solicitação" attr="type" lookup=no make_required=yes whereclause="(sym='Requisição') or (sym='Incidente')">

 

 

and to add type 'Request' on field 'Type' I  used this  javascript code.

 

var cbxTipo = document.getElementById("df_0_2");
if(typeof cbxTipo != "object" || cbxTipo == null ){}
else{
try{

var optTipo = document.createElement('option');
optTipo.value = "R";
optTipo.text = "Solicitaçao";
cbxTipo.options.add(optTipo);
}catch(e){}
}

 

sorry about my english

 

thanks

02-23-2016 04:10 PM

Yes when a Service Desk staff member receives a phone call, they should be able to immediately launch a new ticket window. Instead of having to listen to the user to determine the ticket type to create. This means you can get more accurate statistics on the length of time spent on calls.

09-30-2015 04:43 PM

We have workarround that even works with different categories. When type changed in interface we have custom javascript that is populating custom field with information that type was changed and submiting the form. We also have an trigger on type change, that runs spel code that checks if custom attribute contains any value, if value is found spel script clears that value and returns error message: ticket type was changed please provide new value. Since form was allready submited, but save failed SDM fully reloads the form and instead of request form you have incident form with incident categories and etc.

We allready implemented this customization for number of clients, and even have migrated to new versions, and this works stable, without any problems. The only drawback is that form reload does not creates KEEP values for priority calculation, so there is a need to extend priority calculation functionality in order to get this values for incident. Anyway this is something that can be easily implemented by CA and i don't see any reason why they discarded this idea with so many votes. And i hate them each time we do this customization

09-03-2015 09:20 AM

Have something setup do use a button click that was created, it works.

But as stated the categories have to be the same...

04-21-2015 04:00 PM

Changing ticket type is not so trivial when you have different categories, prioritization scheme and forms with different fields for incidents, problems and request. so it is realy sad that CA decided not to implement this idea.

08-16-2013 04:14 PM

In our environment I have added a dropdown for the type attribute for R/I/P ticket detail forms. It works like a charm, and is quite simple. One thing I would point out in handling this as a mod rather than as OOTB configuration. I provided the field only to the role used by our Service Desk analysts. I would recommend considering this as a business practice rather than exposing to users of all roles. This is easy to do with a seperate form customization group and you can expose other fields only your Service Desk would care about as well. <br><br>I have still promoted this post as it might be helpful to provide to all OOTB and then restrict as needed so admins/organizations new to the product are readily aware of this possibility.

07-02-2013 04:38 PM

This in our environment has as much to do with the fact that end users don&#39;t (and shouldn&#39;t) care about ITIL. 

12-28-2012 02:25 PM

Technical solutions are shared all seem like valide solutions.  I wonder if part of the difficulty for your user community may be in the descriptions of Services being offered. Core problem, aka RCA, I beleive is in Services Offered.  If Users have &quot;Incident&quot; Categories clearly saying such: Fix this, Get that to work; and Request Services saying:  Need this, Want that; maybe impact and continued mis-classification can be reduced to a manageable level.

11-14-2012 08:32 AM

We offer the ability to convert requests into incidents and vice versa to our SaaS customers too (as an enhancement). Users can then convert tickets using an action in the action menu.<br><br>The principle is rather easy: you basically want to have the type changed from R to I.<br><br>You do need to be careful though when you have different incident and request categories as that could cause issues. We typically have the user recategorize in those cases.

09-12-2012 07:11 PM

Just echoing <a class="ibtUserLinkNormal ibtUserLink" href="https://caideation.secure.force.com/ideation/ideaProfileActivity?c=09a30000000I8ZYAA0&amp;u=00530000007MiNS" style="color: rgb(0, 100, 175); font-size: 11px; background-color: rgb(242, 246, 235); font-family: Arial, Helvetica, sans-serif; text-decoration: none; " target="_blank">saisravanksv </a> comment-<br><br>We expose the &#39;Type&#39; field as &quot;Ticket Type&quot; in our environment (we actually include Problem as that can be a part of our WF as well), but it makes it quite simple to flip between different IRP types.  Now if you want to create a full new ticket, that is a different, and more complicated endeavor alltogether.  

07-03-2012 02:03 AM

In my environment, it occasionally happens that an incident/request is logged incorrectly.  So the field has been setup so that it is conditionally editable.  Basically the field is only editable if the logged in user is the administrator.  So I wondered if it could then be true for only one tenant&#39;s administrator.   That was my thoughts anyway.

06-22-2012 09:33 AM

I think this can be done straight away, On the detail forms of incident and request keep a dropdown field pointing to type attribute restricting problem in it. This field should be guarded by the confitions, 1. the ticket category is enabled for incidents and requests both 2. should not have children.  if the conditions are true, then only show up the field else keep a note...Keep the relevent forms in the required form groups.

05-08-2012 02:10 PM

This would not be difficult to program.  To my knowledge, it is a field in the database that indicates a request or an incident, so out of box, incident and request forms would have an action button to convert it to incident or request based on the direction you need to go.  Yes, in an ideal world where we all have tons of time, educated users, etc., we could implement the tool in a manner that would not allow an associate to submit an incident as a request and vice versa, but lets face it, the majority of the implementations are in environments where this is not the case.  This feature seems like a simple one.  Of course the forms may be different and have different required fields and if that is the case, then the action button could convert it for you.  My guess is that BMC Remedy and maybe even Service-Now does this out of box and features like this that save time for your service desk folks are well worth the time.

04-18-2012 02:52 PM

In a situation like this I feel as though you need to wrap stringent rules around your business process.  Since you no longer have the ability to customize the tool, you should find a way to refactor the business process to accomodate the tool&#39;s structure.<br><br>From a process perspective, I would be wary of implementing such a feature, although it is certainly possible and fairly easy to build.<br><br>Cheers.<br><br>