Possible to pre-fill text fields in a new IR or SR via web API or querystrings?
Tom_Hendricks
Customer Super IT Monkey ✭✭✭✭✭
I may be missing something obvious. It sure feels that way! Here is an example scenario for some context:
If there is an API call or simple URL/query string combo that effectively accomplishes the above example similar to the following pseudo code, that is what my question is about:
Example:
url: https://nameofserver/api/v3/Projection/CreateProjectionByTemplate?id={SRTEMPLATEGUID}&createdById{USERGUID}
body: { "formJson": { "Description":"Please install Microsoft Pinball on user XYZ123's machine. Because reasons.", "AlternateContactInfo":"pager", "RequestedWorkItem":{ "Id": "{ONBEHALFOFUSERGUID}", "baseId":"{GUID}"}}}
Method #2:
url: ;RequestedWorkItem={ONBEHALFOFUSERGUID}
The phone system brings up caller information at the analyst's workstation who is receiving the call, and it wants to pop a new ticket open in their web browser via a URL. First, the caller info from the phone switch is presented and the analyst may choose to change it (e.g., someone is calling from a co-worker's phone).
At this point, the analyst will also select whether this should be an Incident or Request--they need to talk to the caller before they know, after all--and then pick from a list (populated by the Cireson API--that web call works great once we know the work item type, btw!) of applicable templates.
Opening a new Incident or Request with a template (or blank) is easy. However, we also want to populate that new Incident or Request with the caller's name (which is actually a relationship...), their alternate contact info, and the Description field. None of this can be stored within the template because it is unique to each phone call.
The /api/v3/Projection/Commit call seems the closest to what I am looking for, but it saves the work item without consideration for required fields. I can see why it does that, but it is not helpful in our process. I would want to populate this information in the new ticket on the screen as though it was re-typed by the analyst, but not in the database until after the other required information is entered. I would not want to have to duplicate all required fields in this other interface before finally opening a work item in the Cireson portal, either.
At this point, the analyst will also select whether this should be an Incident or Request--they need to talk to the caller before they know, after all--and then pick from a list (populated by the Cireson API--that web call works great once we know the work item type, btw!) of applicable templates.
Opening a new Incident or Request with a template (or blank) is easy. However, we also want to populate that new Incident or Request with the caller's name (which is actually a relationship...), their alternate contact info, and the Description field. None of this can be stored within the template because it is unique to each phone call.
The /api/v3/Projection/Commit call seems the closest to what I am looking for, but it saves the work item without consideration for required fields. I can see why it does that, but it is not helpful in our process. I would want to populate this information in the new ticket on the screen as though it was re-typed by the analyst, but not in the database until after the other required information is entered. I would not want to have to duplicate all required fields in this other interface before finally opening a work item in the Cireson portal, either.
If there is an API call or simple URL/query string combo that effectively accomplishes the above example similar to the following pseudo code, that is what my question is about:
Example:
url: https://nameofserver/api/v3/Projection/CreateProjectionByTemplate?id={SRTEMPLATEGUID}&createdById{USERGUID}
body: { "formJson": { "Description":"Please install Microsoft Pinball on user XYZ123's machine. Because reasons.", "AlternateContactInfo":"pager", "RequestedWorkItem":{ "Id": "{ONBEHALFOFUSERGUID}", "baseId":"{GUID}"}}}
Method #2:
url: ;RequestedWorkItem={ONBEHALFOFUSERGUID}
0
Comments
I had done something like this before to copy Change Requests, but I was hoping for something a little simpler and more elegant. What we did works, but it seems like it was the hard way. Perhaps not.