Hi @shannon.mejia, 

How do you generally route Service Requests or set attributes for them? This needs to be done in a separate workflow that checks for specific conditions (such as a tag you added or the service catalog item you requested) and sets some attributes. You can also use a custom object for a list of service catalog items and the values you want for each item (using a reader node) and point towards the attributes within the custom objects.

Other idea: The result of the API call has the information of the newly created ticket ID. You can afterwards use the UPDATE API for that ticket if you parse the information from the newly created ticket.

@DanielRuff thanks for the reply!  Yes, we have a custom object table and a WF that will update those tickets. That WF won’t kick off because the SR is created by the API and not a human action (limitation for WF’s).  I am trying to figure out how to update the ticket even without the human interaction though.  I will see if I can use the Update API and parse out the ticket details.  I assume I need to do this in a different WF?  Or can I do it in the same WF that created the ticket?

@DanielRuff  I was able to use the Parse and then the Update API to update the ticket after created.  Thanks for the assist!

I have an API node setup to create a service request, but I cannot specify the properties (i.e. priority, impact, urgency, group, etc) of the SR with the API.  How can I update these details in the WFA?  If I just add an action node, it updates the details on the original condition and not on the newly created ticket.  I need the newly created ticket to be updated.  

 

When you create a Service Request through the API node, the initial SR will only have the basic fields that the API allows. To update additional properties (priority, impact, urgency, assignment group, etc.) on the newly created ticket, you’ll need to capture the ticket number/ID from the API node’s response and then use an Update Request (or Update Record) action node that points specifically to that ticket ID.

The reason your action node is updating the original condition instead of the new SR is because it isn’t referencing the output of the API node. Make sure you map the response field (like requestId or sys_id, depending on the system) from the API node into your update node. That way, the workflow knows which exact record to update.