So there starting to be Q's on bugs, and there will be more in the future.

What do you think we should do with them?

There is already a canonical question How to Report a Salesforce Issue

I will add that: If the answer to the question is in the field of:

  • Yes, it's a bug, you can/should contact SF...
  • Yes, it's a known issue, you may want to contact SF...
  • This looks like a bug in SF, contact SF ...
  • other similar answers in this format

Such questions should be closed as duplicates. I want to point that a closed question is NOT hidden, so even if another user, will submit the same bug, he should see it in the quick drop down.

AskUbuntu has done a similar thing (which is where I got the idea) - when ever a bug is submitted, they are closed, and referred to ubuntu's site.

(AU and SFSE - are in a similar format, as both are a Q&A for an active/known product)

one that is not complete similar, but a close sibling is: Creating a Class in Dev Console Gives a 500 Error

  • AskUbuntu's handling is pretty sound. The Salesforce Stack Exchange isn't really for straight-up customer-service issues such as bug reporting and feature requests. They should be closed as 'off topic' and referred to the proper site for reporting such issues. Commented Oct 29, 2012 at 21:08
  • Are you saying that you don't want people to report bugs they find even if there are no questions about it already or do you want to simply close duplicate questions about the same bug? Commented Oct 30, 2012 at 21:14
  • 1
    salesforce.stackexchange.com/questions/4954/… - In my opinion this would be more of the type of question which is more of a SF support issue which could be closed. Agree? Commented Dec 1, 2012 at 12:17
  • 1
    One thing that could also be useful is that if you file a case for an issue, to post the case number (either in the question or as a comment) so others can reference it.
    – Ryan Guest
    Commented Dec 6, 2012 at 0:37

2 Answers 2


Maybe I misunderstood you, but I think they should only be closed as duplicates if they deal about the exact same bug. Sometimes it is not clear for the person asking that their question is about a bug, and they may believe they are doing something wrong themselves for instance.

While a specific answer on how to solve it may be impossible when it comes to most bugs, I don't think that while we may often be forced to answer "contact SF suport", that should mean those questions should be closed. There also seems to be an increasing attention of SF staff to this website and questions, which could result in meaningful replies to bug related questions.

  • 2
    I agree with you @Sdry about people thinking that it is something that they are doing wrong first and not an SF bug and 99% of the time that someone's program isn't working it is probably not an SF bug. People first want to see if anyone in the community has encountered and dealt with the issue, before they proceed to classify it as an SF bug and open a support case. After a few days with the only response being it looks like an SF bug - please open an issue, I think it is OK to close it. Obviously, if it is a dup it should be marked as so. Commented Oct 29, 2012 at 10:40
  • 1
    If you don't have access to Premier support and you aren't sure if it is a bug or something you are doing wrong then bouncing it off other developers as a question can be a real time saver. If it is something you are doing wrong then hopefully it will help the next developer with the issue, otherwise it can be closed as a bug for Salesforce support. Commented Oct 30, 2012 at 21:35

One thing I'd like to point out is that the answer to the question may be a workaround to the bug, since it solves the problem. I'd lean towards keeping these questions open so people could post workarounds.

I just came across this situation here: Site.com CSS not recognizing media queries

The question is about why doesn't CSS3 work in Site.com. The most correct answer is that it's a bug that should be reported to salesforce.

However, the most useful answer would be a workaround that can be used to get around the issue (and solve the use case).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .