Private messages to a group, or other means to handle private support requests

We will be deploying discourse primarily as an open forum for users of our products to discuss features, bugs, usage, etc. Our customers still often need a private channel to discuss certain issues, however. To date, they are all used to emailing ‘support’, where a group of us can respond and stay copied on the conversation.

But I’m hoping to steer folks toward the forum where possible to encourage people to use the open resources on the forum. Worst case, we will just end up replying to the emails with links to the relevant topics, but this also tends to make some of us less likely to go find the conversation on the forum.

Also then we can take advantage of features like:

  • mentioning particular folks who are best able to help with a given issue
  • limiting the noise on email
  • linking to related topics in the gutter

This kind of request has come up before, but I haven’t found any answer as to how people are handling this type of use case yet.

@lightyear - what have you guys been doing for the requirement below? Have you been handling that aspect of things with discourse?

Some previous similar discussions:

Private forums or discussion threads:

1 Like

Can you explain the exact, ideal, workflow you would like to see?

I will try my best. But let me explore what currently exists here a bit more first

TL;DR: I think we can get by pretty well with existing features. Will let you know more when its been put into action.

After completely reading the topic I linked to above, I think that there are a lot of similarities in what I am looking for to those described by the likes of @mkirk and @haiku.

Another way of looking at it is that its a further extension of adding features such that Discourse can completely replace email / mailing lists.

We have use a variety of communication tools at our small company to provide our customers tech support including, a web ticketing system (zendesk), email, phone, and remote access vnc and teamviewer. There is a mixture of issues that can be discussed openly and those that cannot (especially / obviously when they require exchanging credentials for remote access).

Now we are looking at adding Discourse to the mix because having an open forum where users can discuss their issues, ideas, etc like you see happening here on meta would certainly be a valuable resource to them.

Each of these tools has their merits, but there are too many already, and so reducing the number of channels an end user has to consider when seeking support is one of my goals.

We have decided to cut out zendesk as the ticketing/knowledge-base system, as discourse will better fill the role of knowledge-base, and the ticketing system is under-utilized (in part because people are so used to using email for asynchronous communication).

Email is hard to replace though. Everyone already uses it every day and they can freely copy anyone in their address book on any message if its relevant to them.

They can email us at The message is visible by anyone in the support group, as well as anyone else they have copied or that we copy in the future. The archives are visible by anyone that is later added to the support group, so it becomes a knowledge-base in of itself.

Its probably not replace-able unless we cut the cord and say: “you must use Discourse for support” - perhaps in combination with the email-in feature.

If it does the job and its so hard to replace, why would we want to do it at all?

  • It would reduce the number of channels for support
    Go here, search for your issue. If you can’t find it create a new topic or send a PM to support
  • It would be easier to encourage people to search for their problem first if they are already in the place where they might find the answer
  • It would be easier to encourage people to ask a question on the forum first if they are already in the place where they can do that
  • It would encourage those of us handling support to link to relevant posts if we are already in the place where they exist
  • It would reduce the amount of noise in our email inboxes

##OK - so on to my ideal workflow:

  1. Customer runs into a problem
  • They log onto discourse
    • They may search for their solution first
    • They may post a question publicly first
  • If they do not do the above, or they do not find their answer, then they send a PM to the support group
    • Ideally, there would be a tab for ‘Support’ or ‘Tickets’ on the topic page
    • When they click there, they would see any previous issues that they created or have been copied on
    • The Create Topic button would say something like ‘Privately Message Support’
  • Clicking the support button would open a new private message window:
    • support as a non-expanded* group would be the recipient
    • their ‘account’ group** would also be a recipient
    • they would be able to add/remove additional recipients and write/send their message
  • Those of use in the support group would receive a notification of a new private message
    • One of us responds, as ourselves, linking to any appropriate public topics or previous private messages involving them
    • If the request is one that seems like it could be discussed openly, we suggest they create a topic in the appropriate category, or later we may create one to document the problem and solution
    • While responding, it shows us who else is responding***
    • If the request requires internal discussion that is private within our group, then we discuss that in a new or existing topic in a private support category and link to this PM

*Non-expanded group

  • Support is copied on these messages as a non-expanded group
  • These messages are visible to the new members of this group
  • Members of this group can control how they are notified of messages in this group, with defaults
    • notify me of new messages to support
    • only notify me of responses to messages that I am copied on personally
      if unchecked, you will be notified of all responses to messages in this group

**Account group

  • A group can be created for end users in one customer account
  • This group will automatically be added to the recipient list on messages to support (thought it can be removed)
    This would eliminate cases where different users at the same site contact us independently about the same issue - happens more often than you would think.

***Show who else is responding

  • This has come up before on meta. It would help reduce duplication of efforts on our part - a rare occurence, but in the ‘would be nice’ category.

I realize a lot of this is way out of scope for what would go into discourse core any time soon if ever. But you asked for ideal, so I gave it to you.

I think that there are still enough incentives to try to keep people in this environment that something less than ideal would can certainly work.

##Here’s how I’ll try to do this with existing features:

  • Create a pinned topic to tell people how to PM support
    • Encourage them to look for their answer first
    • Encourage them to post a public topic if possible
    • Encourage them to copy their co-workers if they are going to send a PM
    • Link to this topic whenever people request support via some other channel
  • Be OK with the fact that it automatically expands to individual users
    • Invite new members of support to relevant historical topics when necessary
  • Be extremely happy with the fact that you can change the Tracking/Watching status on PMs
    • Create an internal topic on handling support that reminds people in our group of that fact

@sam, one thing that is still a little awkward with the plan I’ve outlined above is that its not so straightforward to create a private message to a group. If I understand correctly, right now, I have to:

  1. Go to a user profile or user card and click “Private Message”
  2. Delete user from recipient list, then add group name

Is there a way to open the PM window pre-populated with a group as the recipient now?


I followed @mcwumbly instructions, but no joy to PM a group.

i.e. I go to the profile page of a member of the group, click the PM tab, delete their name in the box and (try) add the name of the group they are in. tp_painter_peeps It doesn’t accept that name and suggests alternatives not in the group.

I get an Archetype error message

Is PM groups still supported or any idea what I am missing here? Just need to stick with another method?

@mcwumbly Did you ever discover the answer to this question?

I think the answer is that there’s no easy built-in way to do this…

In practice so far we’ve still been using an email alias for private support requests, as we were taking things one step at a time, and haven’t really thought too deeply about this problem much recently.

This is pretty much exactly what we want too for the same reasons. Rather than replacing Zendesk we would be replacing Tender with Discourse.

Discourse would be ideal except.

  • TL0 users can’t send PM’s (even to blessed groups).
  • It’s not super obvious how users can send PM’s to groups of users (ie, staff).

Another suggestion I posted elsewhere was a the idea of a category where TL0 users can post (and see their own topics) but only members of a blessed group could see and respond to all topics in that category.

Update: So after doing more digging, I noticed that new users can have a trust level higher than TL0 by default. This solves the problem of not being able to send private messages after sign-up. Though it does remove some of the newbie abuse barriers.

The group PM feature is still not very obvious. One thing that would make it easier would be if there was a way of embedding an link in a topic that opens the PM composer addressed to a group.


You may want to check out this topic:

1 Like

We did eventually change that. TL0 users are now allowed to respond to any PMs (now called just Messages) they happen to get.

First class group private messages are implemented per:


Sounds awesome.

All the stuff you highlight in this post sounds great too.

Kind of makes me want to start doing more customer support again!


In case anyone on this topic missed it. Messaging to groups via URL works now. High fives :raised_hand: Discourse team

Works great for letting users initiate support requests by sending a message for a group to handle. (That sound you just heard was ZenDesk losing some customers.)

The messages for group members will show up in each group member’s individual group inbox which are accessible via the group member’s user profile. Each user can set their Watching/Tracking status for that inbox. I think I have this right, correct me if I am wrong. Took me a while to sort it out. Time for :beer:


I can’t get this to work anymore. It works just fine with the username-feature, but i can’t get it to work with the groupname-feature.

I can confirm that this is no longer working in Discourse 1.9.0.beta10. I’ve posted in bug to make sure this does not get lost:


Is this still the go-to way to handle private support requests?

I’d say so! This is what the Discourse team uses internally, too, so it should be well-maintained and polished :wink:


It’d be nice if the New Message button showed up when you were viewing your own group inboxes, with the recipient list prefilled with the group you were reading.

The check for showNewPM: and("user.viewingSelf", needs to replace viewingSelf with viewingSelf && !isGroup, plus some wiring fixes in routes/application actions.composePrivateMessage to grab the group name properly.


Sounds good to me, what do you think @eviltrout?

1 Like