I recently built an incredible integration for my community, but it’s missing one critical feature: I want to notify users subscribed to a topic when the original post is updated. Here’s my scenario:
We have a SaaS platform and, like many, we have a status page: status.sailpoint.com where our users can monitor and subscribe to incidents when they occur on our platform. The problem with these incidents is they’re very one-way, so our customers can’t communicate with us or each other about how that incident is affecting them. What happens is they end up blowing up their CSMs and our Support lines wanting to know what’s going on (understandably).
To alleviate this, I had the idea to build Discourse into the experience. When a new incident happens, the incident page on status.sailpoint.com will have a nice link/message like “Click here to discuss this incident.” On the backend, we make API calls to create and update a topic in Discourse as the incident progresses, like so:
This is great because now our customers can have an outlet to converse in one place, and CSMs/support have a single, public point of convergence to respond to and alleviate concerns.
The Issue
Every time we add a new incident to this original post, I want to notify those who are subscribed to the topic. I don’t want to create new posts in the topic to do this, I want everything neatly housed in the original topic. I also don’t want new posts in the topic that are then linked with a onebox back in the original topic.
It would be nice to be able to “bump” the notifier.
I get notified when the team here edit documentation topics that I watch. Maybe it’s because the original posts are wiki posts. If that’s the case, maybe it’s your solution. You’d have to set the trust level allowed to edit wiki posts (min trust to edit wiki post) to whatever you need.
That would be so close! But I can’t let non-employees edit these posts because of the sensitivity of them, but I would still want trust level group of choice to still be able to edit wiki’s on other posts.
I don’t know the answer to this, but what about changing the category settings so that normal users can Reply but not Create - does that have the effect of preventing normal users from editing the original wiki post?
Unless you have customers editing wiki posts elsewhere on your Discourse installation, you can just raise min trust to edit wiki post to TL3 (if you’ve rendered it inaccessible) or TL4 and make sure your staff are at the same or greater.
Oh no, I wasn’t aware TL4 can edit all posts. Simple fix though, we’re just giving TL4 to our Ambassadors in our ambassador program, a program we have for our top contributors. That’s handled by the trust level in the user group, so I’m just going to knock that down to TL3.
This conversation has me incentivized to revisit trust levels
I do still need to find a solution for this though! I may need to engage the services team for this one.
I see that topics in plugin are wikis, so that must be how they do it here at Discourse. Okay, I’m going to better educate myself on trust levels first to make sure I have that right first.
I will say though, I don’t like the idea of making them category moderators. Doesn’t that mean they’ll show up as community moderators on /about?
I will do just that. I feel that, in our enterprise use case, we wouldn’t want our community to list regular users (customers/partners) as moderators, as it’s too close to sounding like they’re more formally associated with the operations of our business on some capacity.
Thank you so much for all of your detailed responses!
