Hi there,
Does anybody else have delays in getting email notifications when creating email triggers? It seems to be taking 10+ minutes for me to get the Helpdesk emails which makes it extremely frustrating and difficult to test the automation logic I'm creating to see if they work and to see the formatting of the email since it's based off html.
Thanks!
Hello Tim! I am sorry for the trouble: we encountered with throttling HelpDesk webhooks by SharePoint and that caused delays in running the triggers. Now developers are working on fixing the issue. Usually, it occurs in American business hours of peak service load.
We have been seeing delays intermittently and a total stoppage currently running a about three hours. We also had a couple of hours last week where tickets were not being created by emails. Not sure if that was related.
Thanks for sharing! My team is currently in a demo phase and testing to see if Helpdesk is able to meet our needs and is consistent enough. Curious if the on-premises version is more stable than the 365 online.
Hi,
We noticed the delays in running triggers 2 days ago.
Thanks for confirming the issue and having developers working on the issue.
Do you have an ETA when this issue will be resolved?
Dell
Hi. Any updates please regarding this issue?
At 2:30pm EST our system complete stopped processing now.
Hello,
All services are working stable now. Please accept my apology for the issue.
Best regards,
Petr
Plumsail team
Its dead again after only work for 10 mins.
We have been experiencing the same issue. Our Help Desk's email settings are currently configured for the "Email forwarding" option.
Does the webhook throttling also apply to the "Outlook mailbox" option? If the Outlook mailbox option is unaffected, we can switch our Help Desk to use that instead.
Thanks!
On Friday we released a fix for the trigger delays that should help to avoid its cause - SharePoint throttling. That regards only running the triggers, not e-mail processing (converting incoming messages into new comments). If you encounter an issue with the latter and use connected Outlook mailboxes, try to re-connect them. If it does not help, try to use e-mail forwarding instead (in the opposite case, try switching from forwarding to Outlook mailboxes if possible) and raise a support ticket sending a message to support@plumsail.com - refer to this topic, provide screenshots of the errors you have, share samples of unprocessed .eml files.
Has there been any instability regarding SLA triggers? At first I thought it had to do with my conditions/logic, but I only seem to be receiving the email notifications 4+ hours later when I in fact have set my time to 6 minutes or less (business hours) with my business hours set from 8-5
Hello Tim! What minutes do you mean? In the SLA policies, you can set only target hours, not minutes. Please clarify your issue and describe some example of it.
Hi, yes so basically I'm trying to test out the SLA Policies and if I take one, for example, to send an email to an agent after 1 hour of a ticket not having a response, instead if putting in 1 hour and having to wait to see if it works I have tried to put, for example, 0.1 hours which is equivalent to 6 minutes. I have found that either I don't get that email at all or I may get it sometimes in a few hours. Another thing that I have noticed is that if I put the exact same parameters in 2 different SLA policies, but with different target times, sometimes I will only get 1 email and not the other which doesn't make much sense.
Tim, thank you for clarifying the issue! Let's start from the end. HelpDesk applies only one SLA policy to one ticket that matches its condition. Thus, the order of SLA policies in the list is important. Please find more information about that in this article.
As regards the issue with the delay. HelpDesk checks the SLA violations periodically thus, you won't get the notification instantly after the violation though a few hours may be too much. I will ask developers to specify the period and check whether there are any issues.
1 Like
Tim, HelpDesk supports only integer values for the target hours. The possibility to enter a fractional number is a bug and it will be fixed. Then, HelpDesk checks SLA policies hourly in business hours in the specified timezone - ensure that you set up it correctly. Thus, you should receive a notification about violation of SLA policy not later than an hour after (or a bit later). To troubleshoot conditions you implement in your SLA policies, I would advise to create a trigger that sends e-mail message on the ticket modification. Create a test ticket, edit it, and check whether the trigger sends you the message. Once you find the proper condition configuration, reproduce it in the SLA policy.
For now, we do not register any general issues with SLA policies or running triggers. If you still have, please provide us with the following data:
- HelpDesk URL,
- screenshot of regional and working hours settings,
- sample ticket ID on which you reproduced the issue,
- name of the SLA policy (the issue should be reproduced with the integer target values in the configuration),
- .eml file of the late notification from your mailbox.
Share the requested information through private message here, in the community, or raise a support ticket sending message to support@plumsail.com. In the last case, refer to this topic.
1 Like
Just had a 12 hour delay. Of course, then we test it's fine now.
I have to be honest, this inconsistency in notifications is troublesome. Notifications can range anywhere from 1 minute, to 5 minutes, to 10 minutes, to an hour or two hours, or apparently now 12 hours.
Hello Clint! I am sorry for the troubles you experienced with the trigger delays. They happened on March 9 and 11. For now, the service works normally and developers are researching the cause. I will post the results in this topic.
Thanks for the update. I know you guys are always on top things, so I'm not worried there, just wanted to emphasize there have been a few of these now.
Most likely, it was a network issue which was resolved on March 11. We extended logging and alerting to detect, fix, and research alike issues for sure.