Title Not Changing

Hello, there.  I have a weird situation with a Web Method in a Workflow.  If you review the images provided, you will see from the Feed and Workflow History that the Web Method was executed as expected; however, the title of the ticket was not changed.  Is there something that is happening after the web methods are executed that changes the title back?  If there is there is no entry in the feed.

Any ideas?

Thanks, Tevis

Asked by Tevis Boulware on Tue 7/9/19 12:06 PM
Sign In to leave feedback or contribute an answer

Answers (4)

This answer has been marked as the accepted answer
Mark Sayers Tue 7/9/19 2:12 PM

It looks like your Branch step is activating both of those web service steps to run at the same time. When you have two web service steps that both run at the same time and *both* are updating something on the ticket, the system treats that like if two *users* were updating a ticket at the same time. Last update wins and could nullify anything the other updater was attempting.

You'd be better off trying to perform these updates in the same PATCH call so this is not an issue. It is built to accept many changes in a single operation.

No feedback
Thanks Mark and I tested this and this exactly what is happening. We need these two methods to run at different times (one is a conditional call). The issue should only occur in testing since the workflow approvals are done right after the tickets are created, thus triggering both web methods. That is this is a "test funny".

In practice there will always be a significant time lag from the initial ticket creation, which fires the first method, and the approval condition that fires the second method. This time lag will allow the first (unconditional) web method to fire and execute well before the second method will be fired. Testing shows that if I let the first method execute before doing the approval that fires the second method, the sequence of web methods works as expected.

Thanks for the information.

Tevis
- Tevis Boulware Fri 7/19/19 12:13 PM
Excellent, I'm glad that we were able to identify that for you! - Mark Sayers Fri 7/19/19 12:26 PM

Mark Sayers Tue 7/9/19 12:12 PM

Hello Tevis,

I don't know of anything off hand that *should* cause this, but can you share screenshots of your configuration of this web service method so I can review how you have it set up currently?

Sincerely,
Mark Sayers
TD Support

1 of 1 users found this helpful.
The "weird" thing is in early testing, when I first created the Web Method, it worked fine. Once I got the web method working, and tested, I moved on to other things and then it seemed to have stopped working. BTW, I am doing this in the Sandbox if that matters. - Tevis Boulware Tue 7/9/19 12:22 PM
I don't think that would matter (the environment you're testing in), but I would like to see the configuration of the method to see *how* it is that you've configured the step to make this change. Are you sure you are pointing it at the right environment's ticket? things like that. - Mark Sayers Tue 7/9/19 12:30 PM

Tevis Boulware Tue 7/9/19 1:59 PM Last edited Tue 7/9/19 2:00 PM

Hi Mark, it worked for me as well, then just stopped.  If you see the workflow step, I had originally thought the "dangling" step in the WebMethod success condition was causing a problem.  So, I fed this into a Collector and the problem did not go away.  Also, the "Change Requestor" success dangling condition works just fine.

I expect that is these dangling conditions that may be causing the problem, but why would one work and not the other?  Also, why would these show as successful in the feed and the workflow history, but not change the ticket.

Thanks, Tevis

No feedback
I don't see how it could have just stopped working. Does it work when you have Admin up and perform a test request from that web method? - Mark Sayers Tue 7/9/19 2:06 PM

Tevis Boulware Tue 7/9/19 12:31 PM

Hi Mark, it looks like I needed to start another thread to give you attachments. 

No feedback
Ok, I'll test this, but a couple notes: 1) you should always make web service calls to yourdomain.teamdynamix.com etc etc rather than app.teamdynamix.com. So if that is how your Web Service provider is configured, I would recommend changing it. That wouldn't break anything, but it's best to always use your own TD domain when calling API endpoints.

2) This also likely isn't a breaker, but you aren't using the "title" parameter in your call anywhere (that I could see)
- Mark Sayers Tue 7/9/19 1:29 PM
This worked fine for me in my testing. Perhaps if I know how you were using this step in your workflow that might be helpful. - Mark Sayers Tue 7/9/19 1:51 PM
Hi Mark, I am testing changing the domains. Can you explain what the differences are in the domain names; and why one is "better" than the other? I am just trying to understand the differences.

Thanks, Tevis
- Tevis Boulware Fri 7/19/19 11:01 AM
It is just less likely to cause some sort of error due to a mis-match in the domain being called to/from and your organization's actual TD domain. Plus, in the future, there may be considerations to restrict API calling to *only* be allowed if you are calling to your actual TD domain or custom TD domain, so it is best practice to just ensure all calls are going to your domains now and avoid having to change any potential integrations you have later on. - Mark Sayers Fri 7/19/19 11:46 AM
Also it helps us faster identify and troubleshoot issues for you if we can more easily identify their web traffic by the fact that you're pointing calls to your specific domain and not the generic api.teamdynamix.com... URLs. - Mark Sayers Fri 7/19/19 11:56 AM
Thanks Mark, this if info I will need to bring to the CCB. - Tevis Boulware Fri 7/19/19 12:03 PM