Hi!
I do see some Slack-triggered runs over the past day (between the manually triggered runs I was doing). And some of them fail (by design).
At least by the design Gummie helped me come up with 
.
Since the message I want to listen to, I can’t ignore bot messages.
In order to avoid a recursion effect where the Gumloop message I post triggers the flow again, I go from the Message Reader node into a Filter node which checks whether the message is from the Slack automation bot that sends the new sign up notification to the Slack channel in quesiton.
If that is not the case, the flow fails there (because the filter condition isn’t met).
I was under the impression that this is the best/intended way to solve my recursion issue (again, due to Gummie’s guidance). I guess these failed runs then trigger some sort of action in your backend that disables my trigger?
I have already, multiple times now, followed the debugging steps here (turn off trigger, save, delete node, save, add node, save, enable trigger, save) and have re-authenticated.
I also built the flow only about 5 days ago, so I assume that was after the trigger functionality improvements you mentioned?
Just an hour ago or so another message came in and failed to trigger the workflow.
Is there anything in the filtering/recursion protection design I could adjust?