- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-22-2015 11:34 AM
Hello community,
Was wondering if someone could help with this...
So i have a requirement to create a simple Mailbox request that in the end will create an incident for an AG to carry out the permission granting once the request is approved.
I started with a RP, however the group in charge didn't like the way the incident was inserted in the "Waiting for approval" state on the incident table prior to approval....
so i switched to a Catalog item where i can therefore utilize the workflow for approval and then create incident after approved.
I created a SR, with a workflow that is approved by one HR member, and then when approved it will create the incident in a "New" state...
someone stop me if i am doing something wrong for this process....
So in creating the SR, there are few variables (Requested by,Name of persons mailbox to request access to, type of access needed "Temp" or "Perm", Access start date, Access end date)
When "Ordering" the request, it goes to the HR user for approval, and on the approval screen shows the summary of the variable answers. When HR user approves, the incident is created however there are a few issues i cant seem to understand.
a.) The caller_id on the newly created incident is the HR approver
b.) Is there a way i can copy the variables from the SR to the description of the newly created incident ?
Ive looked on the forum to find out if there were any similar questions, seems that others want to do the reverse with a UI action.
Post thats most closely relate to what im looking for (Want to raise an incident from Service request on Request state"Approved".Can any one explain me how...) , however i do not know scripting enough to put the final touches on this. Is there anyone who can help lend a hand ?
Ive tested using the create task event in the workflow engine, however it creates the incident as the approver, and no information in the SR copies over to the incident.
Essentially i dont want to have to introduce an AG to a new module with new actions (Service Catalog > Open Records > Requests) as they are used to only closing incidents and the introduction to a new way of handling a request would make their head explode.
Let me know if you can assist in my knowledge quest Thank you!
Solved! Go to Solution.
- Labels:
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-22-2015 09:03 PM
Hello Brian,
1) Why to create an incident for 'Request Fulfillment' ?
Incidents are supposed to be created if there is an interruption to the service and not for request fulfillment. In most of the implementations we have done, we include a closure code 'Does not classify as an incident' for incidents getting created for request fulfillment.
You can simply create a 'catalog task' on 'sc_task' table via workflow once request is approved rather than creating an incident. This will solve the problem of variables as well as caller field. Your variables will simply be available to team which is currently working on 'Incident'.
2) If this still is the requirement, then you will have to hardcode the variables from catalog request to incident comment section.
eg.
lets say you have created an incident with incident object variable as inc, your code for copying variables would be
inc.comments = current.variables.'firstVariableNameShouldGoHere' + '\n' + current.variables.'secondVariableNameShouldGoHere' and so on.
This will be a hard coded stuff and should be avoided as a best practice.
If this is a single request for which you are doing this, I can suggest to go ahead with hard coded stuff and also prepare the document for survival in case in future those variables are added / removed / changed.
If this is the general practice you are following for Service Request handle, this can be done via other ways to get the variables dynamically for each service request.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-22-2015 09:03 PM
Hello Brian,
1) Why to create an incident for 'Request Fulfillment' ?
Incidents are supposed to be created if there is an interruption to the service and not for request fulfillment. In most of the implementations we have done, we include a closure code 'Does not classify as an incident' for incidents getting created for request fulfillment.
You can simply create a 'catalog task' on 'sc_task' table via workflow once request is approved rather than creating an incident. This will solve the problem of variables as well as caller field. Your variables will simply be available to team which is currently working on 'Incident'.
2) If this still is the requirement, then you will have to hardcode the variables from catalog request to incident comment section.
eg.
lets say you have created an incident with incident object variable as inc, your code for copying variables would be
inc.comments = current.variables.'firstVariableNameShouldGoHere' + '\n' + current.variables.'secondVariableNameShouldGoHere' and so on.
This will be a hard coded stuff and should be avoided as a best practice.
If this is a single request for which you are doing this, I can suggest to go ahead with hard coded stuff and also prepare the document for survival in case in future those variables are added / removed / changed.
If this is the general practice you are following for Service Request handle, this can be done via other ways to get the variables dynamically for each service request.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-23-2015 08:38 AM
I understand.
Ive switched to a Catalog Item. Created the variables, attached a workflow. I dont have a fulfillment group, so ill have to set the fulfillment process up according to Managing Request Fulfillment - ServiceNow Wiki .
Our company doesnt use SN as it should be used. I guess i just have a hard time figuring out how to switch an Entire global company "Incident" only state of mind into a Service Catalog offering with just me being the administrator.
Thank you for the assistance, ill hit the drawing board again.