HOW TO CHANGE INCIDENTS TO REQUEST ON SDM

[Amosu Babatunde]

Hello everyone in here,There is a directive from our management that incident should be separated from request. It was noticed that end users (employees) misinterprets incidents for request a lot of times and we are asked to fine-tune this.

(1). Is there a way we can change "already logged incident" to request either from the front end or the backend.

 

(2). I need know a way we can make "employee" access type users choose either to log an "incident" or "request" when logged in.

 

Your individual prompt responses would be appreciated.

Warm Regards,

Amosu

 

 

[Cristi Mitrana]

For (1), there is no such support and it's not possible in SDM.

For (2), enable the set the IncidentandRequest value for the employee_intf_incident_support option in the Options Manager -> Request Mgr and the End users will be able to log both Incidents and Requests.

The rest is a matter of end-user education and training.

[Legacy User]

Hi Amosu,

 

For item_1, there is a type field on the Call_Req table which stores P or I or R depending on what was created. Changing I to R will convert an Incident to Request and vice-versa. It can be done with a customization, but NOT supported. 

 

See this external forum: Changing Requests to Incidents - SDU 

 

===

Kind Regards,

Brian

[Maheshwar Kusuma]

Hi Amosu,

 

You have to also take into consideration about the fields differences for each object type i.e. Request(R) / Incident(I) / Problem(P) might have different fields that's configured for each ticket type. If you plan to change the type from P or I or R then you need to take into considerations so that you wont get confused at a later stage.

Again as Brian said its NOT supported.

[David Ng]

Hello Amosu,

 

1. As pointed out by previous updates, changing the existing incidents to requests is possible by manipulating the "type" field on the Call_Req table, however, you need to consider how your site is handling Incidents and Requests, if there is any major difference between them technically (any fields or functions unique to either side). also, how many such records are being considered for the change?

 

2. Usually, employees log either incidents OR requests per their preferred document setting; usually incidents from an OOB perspective. Can you provide an explanation of why employees need to be able to log both kinds of tickets, what the difference is between incidents and requests from a company perspective? And also, are you looking to include a function where a user could switch the ticket type to handle a future case of user error, where a user accidentally logged a request but meant to log an incident and vice versa?

[J W]

Amosu,

 

I agree with all the cautions already presented here.  I have completed this customization for many customers - but the deciding factors to proceed were that they did not have any differences in their categories, workflows, or service levels between the types. 

 

Simply changing the type after it has been saved does not automatically invoke any process that would be associated with that type.  You must capture that change and then create all the necessary triggers, events, logs, etc.  This can become unmanageable quickly.

 

The supported process here is for users of Self-service to create Requests only and then an analyst to create a new Incident from a Request using the original as the basis when required.  This will copy selected fields into the new ticket and create a relationship between them.

 

You would then complete the Incident and then close the initial Request.  The allows for separate processes for Requests and Incidents at the cost of possible confusing the customer with two tickets.

 

There is not, however, a 'Create Request' from the Incident form.  (There was an Idea for this as some point in the past).

 

If you enable both Requests and Incidents from Self-Service, then I recommend you take efforts to make the distinction clear to the users.  Here is a sample I helped one customer to develop:

 

 

Good luck!

 

J.W.