Looking for a feature like reset bump date but for notifications on a topic

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.

1 Like

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.

So that won’t work :frowning:

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.


We do allow users who reach TL4 to edit wiki posts, which is why this one wouldn’t work for us.

TL4 isn’t automatically attainable, are you handing it out?

To be clear though, TL4 can edit all posts, rather than just wiki. If you’re giving your customers TL4 then they can already edit these topics.


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 :slight_smile:

I do still need to find a solution for this though! I may need to engage the services team for this one.


Sounds like this is still achievable through wiki notifications, you could:

  • Knock ambassadors down to TL3
  • Make them category moderators to your wiki categories
  • Set default permission to edit wiki at TL4
  • Make your staff TL4

Then staff can edit wiki posts in the incident topics, but not ambassadors as their edit topics rights only applies to the wiki categories.

1 Like

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?


They would appear in a section below admins and moderators with the category name denoting them as moderators for that category.

You could use CSS to hide this.

Maybe wait to see if anyone else presents a more palatable solution if this is sounding like too much change.

Learning about trust levels is always good though, I would start here and then maybe take a look at the permissions table.


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!