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!

To update the properties (priority, impact, urgency, group, etc.) of a newly created service request (SR) via API in WFA, you can add a dedicated action node after the creation step. Ensure that the action node is configured to target the newly created SR, not the original condition. This can be done by referencing the ticket ID generated in the creation response. Explore advanced API parameters or documentation to fine-tune the process.