Waiting for information

Trigger E-mails not being sent still in 20.10.957.7556

Steven Woodhouse 1 year ago updated 3 months ago 31

Trigger e-mails work for a few hours before stopping again.  SMTP Test button works ok.  Using the latest SMTP Advanced Settings plugin.

Reverted to 20.7 for the time being which works correctly.

ConnectWise Control Version:
Other (please specify)
Server Affected:
Host Client Affected:
Guest Client Affected:
Waiting for information

Hi Steven, 

We were unable to replicate your issue internally. Please reach out to Support for further assistance. 

Support were no help...please re-investigate this issue ASAP and it's a critical bug in your software!!!

Hi, we've just upgraded our fully working 20.7 install back to 20.10 and again the e-mail triggers work for about 2 hours before stopping.  We also setup a trigger to send a message to Microsoft Teams which does still work however, so the problem doesn't appear to be with all triggers, just e-mail triggers and only after it's been running for about 2 hours.

Would you still like us to raise this with support?

Hey Steven,

just to clarify, say you have a single trigger with two actions, one HTTP and one email.  After 2 hours the HTTP action will still work but the email will not?

Might be difficult to tell but is it always exactly 2 hours after process restart until the SMTP actions stop working?

Also are you self-hosted or within our cloud?

Hey Steven, would you mind sharing how you setup a trigger between ConnectWise Control & Teams. The failing smtp triggers are really hurting us, and would love to have Control talk to Teams


Hi Joel,

No problem, you can follow this guide to setup the Teams webhook URL:


In Connectwise, add a new Trigger with "Web Request Action"

URL = URL generated by Teams


Content Type: LEAVE BLANK

Body: {{"text": "Your guest to session '{Session.Name}' from '{Session.CustomProperty1}' sent you a message: '{Event.Data}'", "api_action": "screenconnect", "screenconnect_data": {*:j}}}

Amazing thank you. I was not leaving Contact Type blank. Grateful for your time.

Hi Scott,

They are separate triggers.  We are self-hosted.  One time I noticed that it lasted overnight and worked once the following morning before failing again, so it's not always 2 hours exactly.

Ah, I see, thanks for clarifying that.

One last thing, do you mind posting the Event Filter syntax for a Trigger that fails to send an email?


Event.EventType = 'SentMessage' AND Connection.ProcessType = 'Guest' AND Session.HostConnectedCount = 0

E-mail Subject: [SC] Your guest to session '{Session.Name}' from '{Session.CustomProperty1}' sent you a message

HTML Body: False

Body: {Event.Data}

We're also still having problems with the triggers.  

We have been having issues for a while, followed the thread here:  https://control.product.connectwise.com/communities/6/topics/3188-trigger-emails-not-being-sent-after-v208295747520-update
But then in the last post it was announced that version 20.9 has fixed it, and thread was closed.  Issues did not go away completely (maybe takes a few hours before triggers stop working, whereas before it was minutes).

Email test works, then it works for a while, and stops.

Self-hosted, latest official release, all extensions updated, plain email triggers for host up/down or for someone sending a chat message, e.g.

Event.EventType = 'Disconnected' AND Session.SessionType = 'Access' AND Connection.ProcessType = 'Guest' AND Session.Name = 'mainserver' AND Session.CustomProperty1 = 'client1'


Event.EventType = 'SentMessage' AND Connection.ProcessType = 'Guest' AND Session.HostConnectedCount = 0

Can confirm that problem still exists in latest release 20.11.1385.7587.  E-mail triggers work for a few hours but then stop working.  Teams triggers still continue to function.

Note at top says "waiting for information".  Maybe Steven is not available.  Can I provide information?  What are you looking for?

Same here, test emails send fine but we are not actually getting anything from the triggers or from a plugin that was supposed to be a workaround for the triggers. We are on 20.8.29574.7520 and we are cloud hosted - any help or workarounds would be greatly appreciated. We've been missing client messages for months now because of this. 

Agreed, this issue has been going on for too long now and needs to be fixed especially if it affect cloud and on-site instances.  This is a critical feature which is broken!!!

I've got an active case with support right now.  Got escalated to L2 earlier today.  Will update with solution when there is one.

We upgraded to 20.11.1479.7606 at 9am this morning and so far...7 hours later, the e-mail alerts are still working!  Will do another test in the morning to see if they continue working overnight but this is the longest they have worked for so far!

The release notes mentioned about fixing a bug in the triggers, so hopefully this is the fix we've been waiting for!

We're on almost the same version.  20.11.1385.7587

I wouldn't hold my breath.  Ours would also work for several hours, but then stop.

Same issue, latest stable release.  Advanaced SMTP plugin v1.2.5, CC instance, hosted on Win Server 2019, mailing through office 365 dedicated account.  Running CC version 

Trigger alert to send email on chat when no host is connected, works on reboot or service restart from 2-24 hours, but will stop working.  Test emails working as normal from email settings page.

Ok, running 20.11.1479.7606 but after approximately 26 hours it broke again.  This time we think we have identified the root cause and can reproduce the problem!!

The e-mail trigger breaks as soon as a one-off support session joins!  We tested this theory multiple times by restarting the screenconnect services, then sending test messages before and after joining a test machine.

In our case, we had the following trigger setup which seems to be the culprit:

"Notify when guest connects to unconnected support or meeting session"

Event.EventType = 'Connected' AND Connection.ProcessType = 'Guest' AND (Session.SessionType = 'Support' OR Session.SessionType = 'Meeting') AND Session.HostConnectedCount = 0

As soon as we disable this particular trigger, the regular e-mail alerts from unattended machines still come through...even after a test machine joins...we will test again tomorrow to make sure this still works and will report back.

It's broken again...but this time I think it happened when a new unattended machine was added!

Since making the above changes and the blip 3 days ago, our e-mail trigger messages have been working for nearly 4 full days now.  To confirm, the only trigger we have in place now is:

Event.EventType = 'SentMessage' AND Connection.ProcessType = 'Guest' AND Session.HostConnectedCount = 0

This is not the case for us.  We do not have such a trigger.  

Miko, the only thing I can see in common with the trigger that broke it for us and your triggers is the:


Try disabling your trigger:

Event.EventType = 'Disconnected' AND Session.SessionType = 'Access' AND Connection.ProcessType = 'Guest' AND Session.Name = 'mainserver' AND Session.CustomProperty1 = 'client1'

...but leave this on enabled:

Event.EventType = 'SentMessage' AND Connection.ProcessType = 'Guest' AND Session.HostConnectedCount = 0

...then reboot your server (or services).

We have a lot of the first type of trigger, which tells us when a machine goes offline (and its counterpart that tells us when the machine is back online).  Helps monitor connectivity without resorting to more 3rd party software to monitor it.

Connectwise support got back to me as well, saying that they are aware that this is still an active bug, and are working on it.  See below.


Ok, our e-mail alert trigger has been working for 6 full days now...so to help support track down the bug, it was either the fact that we had multiple e-mail triggers setup or there is an issue with something in the following trigger causing the e-mails to stop working:

Event.EventType = 'Disconnected' AND Session.SessionType = 'Access' AND Connection.ProcessType = 'Guest' AND Session.Name = 'mainserver' AND Session.CustomProperty1 = 'client1'

We could also reproduce the problem instantly when the above trigger was enabled and when a guest session joined.

Got a call with support next week.  Will update with results, and mention the above to them.

UPDATE - After nearly 7 full days of e-mail alerts working, they have suddenly stopped!  We had a few guest sessions connect today so I still think it may be related to that...

Reply from support regarding this issue:
"...we do still have a bug report (it's a new one) registered for the trigger emails not sending out in 20.11.xxxx+; the bug report that you linked to is also linked internally to our bug report with development, so once the development ticket is resolved, that public report will also close. You may also follow along with our Output Stream here for updates when the new versions are released (it will mention the trigger emails specifically).

As of 20.11.914, trigger bug still seems to be present, but not showing up in the others, so hard to track on here (or am I reading it wrong, and they fixed it in subsequent builds, and that's why it's not listed?).

I feel like we are having the same issue in a much later version (21.7.3543.7823)

Test emails work just fine with our custom SMTP but email triggers do not. If I reload the related services for it, it will work for a while (a few hours or maybe a few days) before it just stops. Multiple clients of ours rely on these emails for auditing purposes. Support has been zero help.

Can anyone confirm?

Yes, I'm afraid they never fixed this issue...