Considering that we have anothing on the Remedy - Service Desk integration, I would say that this is only possible (if possible at all) with usage of Event Manager.
In essence....though haven't done a specific integration to Remedy myself...
You would need to involve Event Manager to process the return "Resolution" from Remedy but you can make use of the "Integration Process Source" here (which is included in all license types).
Second you perhaps can send outbound web service calls to remedy to create the ticket via setting the behaviour or a business object to generate outbound web service calls. You create a window for that object and add as collection to Incident so you can call it from an action. Then add this after OPEN on the incident as an automatic action and value type fields onto it from the Incident object. Idea is that on save a Web service call is generated and sent to Remedy; assuming of course Remedy could accept an inbound web service call to create an Incident. Important though that you include the GUID of the Incident process (tip: you may need to have a calculated field to extract that as a string so you can add it to the automatic action field you set up for the GUID).
I'd suggest you'd need 2 actions handled via event manager:
1) Initial response back from Remedy with the Remedy Incident Reference Number (or whatever, GUID maybe, they need to uniquely reference the Created Incident). I'd suggest a windowless action that puts this returned reference somewhere on the main Incident Window for example.
2) Resolution Action from remedy which you map to the resolution action in the Incident process.
Any incoming event (1 and 2 above for example) from remedy needs to include the GUID we sent out so Event Manager knows which process to update and that goes in the process_guid fields in the event message format we expect back (see event manager guide for the structure of the web service message we need as field few fields are mandatory).
That's the general approach and as per all integrations, they tend to have unique challenges so would have to be developed in the lab first to see if it is possible.
It occurred to me perhaps to use the part of the tasks (integrate the task with Remedy) and use conditions to move the main process.
The only part that is not so clear for the identification of the processes are the GUIDs.
VaLr by using the process GUID in integrations means we can leverage the “Integration Data Source” method in Event Manager for incoming responses; it just means we need to pass and for the 3rd party application to store an use this in any subsequent communications back to Service Desk. Hopefully that should be a big deal for the application and you would still pass the transaction reference number outbound as well for the 3rd party to have a more friendly reference.
I’ve even used this method inside Service Desk as well. Say you want to do a bulk replacement of data. Create a “utility“ process that just launches an action and then closes. Make that action link to a web service and point it at Event Manager. Setup Event Manager to trap these events and perform actions on the desired process using the event parameters etc. Now point a spreadsheet import at the utility process with columns that say include process guid, old val, new val and hey you can do “magical stuff”! A good use case is for bulk CI replacement for users (user - CI linking) say for a laptop refresh.