Over 70% of the support calls we get are related to licensing / out-of-trial. When our integration apps are out of trial / out of licenses the user is alerting using these 3 methods:
- a notification is send to the user / board
- the integration gets disabled with a friendly message (because we respond with non-200 on the subscribe event)
- the monday platform shows a red bar indicating to contact the developer
The third one (with the generic message to contact the developer) is obviously the most visible to the user. The user don’t read notifications and they don’t go to the integration page showing the disable integration. Even monday.com employees experiencing out-of-trial in their demo account show the same behavior: contact the developer.
The request is to change the red bar message to the same friendly message which is displayed under a disabled integration. This would drastically minimize the number of request we get from our customers.
Thanks for the suggestion! I’ve passed this on to the MP team to see what we can do
I assume #3 happens when they create a recipe that has a custom trigger? Just making sure I have context.
Hi Cody, that is correct.
just to make sure that I understand correctly - you want the option for error communication in the subscribe flow, the same as we released for the runtime flow?
I am referring to the below message header. In the subscribe flow we would like to respond with a severityCode and notificationErrorDescription (same as in the runtime flow) and the notificationErroDescription should pop up here (see below).
For the runtime flow it would be nice to show the same message (notificationErroDescription) which is also displayed in the disabled integration.
It would save us over 30% of the support calls we get.
Right now users have zero real time insights into automation activity. They can see it in a log, or get a notification with a failure. I think sometimes monday.com underestimates the need of users to see workflow states for an item. Many times their workflow requires them to wait until automations are done before doing something else - if they get ahead of themselves then they break their workflows. Not all automations have an obvious result.
Turns out this feature request actually belongs in another monday domain. I’m changing the post’s category so it gets to the right place