We have been having intermittent problems where Autotask logs the changes made by Email2AT, but they are not actually made. After a lot of back and forth with AT support, their Development Team said that Email2AT is moving faster than they are. We are making changes to the ticket before AT finished creating it. Can we slow down the steps?
We could possibly split the workflow in half, send a triggering email from Email2AT to Email2AT to create an artificial delay after the ticket creation step, but is there anything cleaner than that?
At face value, this seems like an absurd request from Autotask. When MSPintegrations performs API calls, it already waits for Autotask to respond with a “success” message before moving on to the next step.
This is rhetorical, but how long, exactly, should MSPintegrations wait before moving on? Is a Half second sufficient? One second? What if Autotask has a lot of traffic? Does MSPintegrations need to wait 10 seconds in that case?
I’d like to talk to my contacts at Autotask to discuss this with them directly. Can you provide any information to reference this issue so we can see what’s already been discussed? Case number, name, etc? Feel free to chat that to me on our website if you prefer.
AT support wrote, “Autotask supplies a response when creating entities when it has confirmed that it includes all fields and details necessary to successfully complete the action in question. It can take some slight additional time to complete the process of actually creating the entity, though. This is resolved generally in a matter of seconds, but given the speed integrations can make follow up calls, that few seconds can potentially result in situations like this if an update is made too quickly after the creation. Autotask is usually able to handle this, as seen with this issue being not replicable and only happening once or twice a day, but it can occasionally result in processing issues like this.”
I’ve reached out to my contacts at Autotask/Datto/Kaseya, and will update when I hear back.
If they can articulate exactly how we should work around this, we can likely implement a solid solution to prevent this issue. Like I said earlier, I don’t want to pick an arbitrary delay that may or may not work.
Feel free to check in again in a few days - I’ll let you know if and when they reply.
A thought: could the answer include checking that all of the fields that were assigned plus some other “key” or required fields return appropriate results before concluding that the ticket creation was completed? It could be a checkbox option in Email2AT whether we are requiring this extra confirmation. Something like: Check fields. If not complete, pause 10 milliseconds and try again. Repeat until successful or 30 failed attempts.
Short of a change in functionality, I’m wondering if I should do a simple loop check. It’s the contact field that has this issue approximately 2% of the time. After updating that field, we could query it to make sure we get the appropriate results and repeat until we do, with a maximum number of tries.
That said, this isn’t so urgent that we can’t wait for you to hear more from your contacts.
The challenge will be that a Autotask workflow rule could fire and immediately change the value, then MSPintegrations would wait forever because it “missed” the update to the value MSPintegrations expected.
Can you re-send me a link to your history that exhibits this behavior and has SOAP debugging enabled? I’d like to look at the actual API queries again.
No problem. After those two steps, the contact ID should be 594, but in reality, without any further updates, the contact ID is actually 776. We verify this by looking at the ticket history. It shows a seemingly impossible combination of the contact being changed from 776 to 594, and later, when we do it manually, we change the contact from 776 to 594 again.
This makes it really tough. Besides an arbitrary delay, I can’t think of anything we can do to verify that this problem doesn’t happen. Since the values are correct when using the API, we can’t implement a query to test to see if the value “stuck” since it looks right to begin with.
I can usually think of creative ways to overcome issues like this, but I am at a loss. I’m unwilling to implement a global delay, as we performed over 1,000,000 create calls last month alone.
What other ideas have you been considering? How can I help?
A checkbox on the ticket creation process that says to pause for 1 second, or even half a second, afterwards. If that isn’t enough, this is a bad idea. The current time between the start of each task is 17 milliseconds in the failed examples, so a half-second would be multiplying that by ~30.
I wonder if the fields of a new ticket are always written in the same order. Could Email2AT always put a certain value in a certain field that comes at the end of the process and check that it has the correct value as an approximate sign that the ticket is done being created?
A thought for doing this with Email2AT without enhancements; going back to my earlier suggestion. In the step that changed the contact to 594, if we check for the contact being set as 776 in a loop that tries up to x (5 - 15) times, we would know that the prior step got past that field. We do not have any other workflows that change the contact, so in this particular case, we might be ok.
