Question

Help Using APIs to Allow a Service Request to Update a Service Request

  • 26 March 2024
  • 6 replies
  • 86 views

Badge +1

Bear with me as I explain the setup I am trying to get working.

 

I have a service request that I would like to allow managers to put in, but then would need follow up information from HR. All the fields in the service request would then be used for automation, so I need HRs contribution to be added to the primary service request.

 

I have an initial service request that gets the primary information I need, with fields not visible to the requester that HR will be responsible for.

 

Once the manager submits the request, a workflow generates an email for HR with the ticket number of the service request the manager submitted along with a link to a separate service request that has the same fields that were invisible to the initial requester along with a field to put the ticket they are trying to update. HR fills in the ticket number and the extra fields needed and submits.

 

Still with me? If so, good 👍

 

I am trying to use the “update requested items of a service request” api (put /api/v2/tickets/[id]/requested_items/[id]) in a workflow to get the information form HRs service request to merge into the managers service request.

 

The first ID in the API is the numeric ticket number of the service request. Since I had HR fill that in, I can pull it from there. The second id is what is giving me issues. Initially I thought that id was the service request id number, but that is not the case. When the service request is submitted and I look at the information with the get api, the second id is different every time making any kind of workflow using a request to update a request seemingly impossible.

 

Is the service request update the only way to update custom fields in a ticket? What is the point of this second id that changes every time when you already have a unique ticket id? Have you tracked with me to this point?

 

I’d love any helpful insight if anyone has any, including if there is a better way to use a ticket to update another ticket.


6 replies

Badge +1

Yeah, so getting the id number I need doesn’t seem to be as difficult as I thought. I can use the ticket number to pull the ticket information using a web request and run the payload through a JSON parser to get the value I need.

Where I am running into issues now is when the workflow runs, it fails and states “Workflow is waiting for another event Web Request Response

There are no errors in the execution logs, and if I run each step one at a time while testing with the workflow open, it works without issue… so I’ve hit another wall unfortunately.

Hello!

The IDs are unique for each Service Request item that is submitted. You can do an api call (/api/v2/tickets/[id]/requested_items) to pull the list of attached SR items on the ticket. Assuming that it is only one, you can pull the first in the list’s array and grab its ID.

With that info, you can make a second API call to update that particular SR item.

Badge +1

Thanks for the reply.

I had gotten that part, but the last issue was coming from the parsed service request ID still not working in the workflow causing the update api to fail. The solution there was simple enough thankfully. I had to run it through a function to remove the brackets. Since it was 14 characters with the brackets included, the following function worked: substring({{Parsed_Request_ID}}, 1, 12). This removed the front and back brackets, and I was able to then use that result in the service request api.

So with that, I can get a service request to HR to have them fill in extra information for a ticket and have the ticket automatically update without anyone on our team needing to copy anything over.

Userlevel 7
Badge +16

Hello @BortFrenzy, so were you able to get a full workflow functioning correctly for your use case? If so, congrats! That one was tricky. A piece of advice that has helped me with subsequent web requests and API calls is to add a short time node between them. This will make sure that the data your second API call relies on has had time to get set correctly.

In your workflow how many calls are you currently making.  From what I have read you would need to have to use some sort of ID in the email that goes out for the secondary ticket so that you can link the two together.  You would start by having the HR ticket include the ID of the originating ticket and then you can use the automator to parse the information on the requested item and gather that ID.  So on the secondary ticket the workflow would use the Get requested items endpoint (/api/v2/tickets/[id]/requested_items) from there you could parse the body and make the secondary call to that originating ticket to update the requested item information. ( /api/v2/tickets/[id]/requested_items/[id]).

The trick here is that the second ID is going to be the requested item ID of the original ticket so a 3rd api call has to be made to get the requested item id of the original ticket using the Get Requested Items api call again with the originating ticket id.

 
Userlevel 7
Badge +13

Thanks for the reply.

I had gotten that part, but the last issue was coming from the parsed service request ID still not working in the workflow causing the update api to fail. The solution there was simple enough thankfully. I had to run it through a function to remove the brackets. Since it was 14 characters with the brackets included, the following function worked: substring({{Parsed_Request_ID}}, 1, 12). This removed the front and back brackets, and I was able to then use that result in the service request api.

So with that, I can get a service request to HR to have them fill in extra information for a ticket and have the ticket automatically update without anyone on our team needing to copy anything over.

If you like to remove characters inside a placeholder you can use remove – Liquid template language (shopify.github.io) I use {{ placeholder | remove: “[“ | remove: “]” }}

In the parser you can change the type of the variable to string as well 
This isn’t a onboard setup? The onboard module have this built in.

Not planing to include HR into Freshservice? because then you can use one service item. 
Having fields shown for agents only. 

Reply