Reasons a post was flagged as abusive?

We provide an option when reporting abuse to specify an AbuseReasonId (default = 0), which is then included with the report when referenced elsewhere. Both the specifying and interpreting of this reasonId would be a customization.

All API types support this, here is the REST endpoint:  Create Abuse Report REST Endpoint  

Steven Heffner said:

All API types support this, here is the REST endpoint

At which point is something a "you should do this via your own customisation / our customisation services" vs "we will include it in a future release" ? Clarity on this would be helpful and ease frustration.

Steven Heffner said:

We provide an option when reporting abuse to specify an AbuseReasonId

But that isn't in the platform user interface by default for some reason?

While this could be added via a customization, I agree that this should be reviewed/discussed as a platform change. This is currently in the product ideation here:  Enable users to include a short message when reporting abusive content or members  

Ben Tiedt said:

This is currently in the product ideation here:  Enable users to include a short message when reporting abusive content or members 

I'm aware, I commented on it 4+ months ago.

Didn't quite answer my question though.

I apologize. Let me attempt again.

Christopher G. Stanton said:

But that isn't in the platform user interface by default for some reason?

The functionality was originally in the platform to inquire about a reason for abuse at the time the report is filed and, based on feedback, it was simplified to a single action while leaving the API for backwards compatibility or customization. At the time, the feedback we received was that the two step process was cumbersome and unneccessary.

Christopher G. Stanton said:

At which point is something a "you should do this via your own customisation / our customisation services" vs "we will include it in a future release" ? Clarity on this would be helpful and ease frustration.

Over the history of the Community platform, there have been a few features that have flipped back and forth (often related to SEO as recommendations changed, but also user-related features that have gone in and out of favor over time). This feature was one that is being requested to be restored by feedback after being asked to be removed by feedback. That's not a bad thing and expectations and use-cases change over time. The goal of the platform is to provide a successful initial experience for the majority of users. When a feature request/change has significant support, it is considered to be included in the product by default.

Specifically to address when should a feature be custom vs. included in the product:

• It should likely be custom if it is not a generally beneficial feature. We gauge this by market review and the ideation.
• It should likely be custom if it is needed sooner than it will be included in the platform if it is scheduled to be included in the platform by default.
• It should likely be included in the platform if it is requested by a significant number of existing customers and/or is a market/strategic direction.

Hi Ben, 
Thanks for the explanation, didn't know the functionality was there in the past, interesting .

I think a lot of people working with the platform are requesting to be able to add a reason when flagging a post/reply/user etc as abusive. Speaking to some of them they would really like to see this functionality (back again). Might be a nice feature to bring back in on a future release!

Ben Tiedt said:

It should likely be custom if it is needed sooner than it will be included in the platform if it is scheduled to be included in the platform by default.

This is the crux point here that I believe needs more transparency so the decision can be made.

If I look through the ideation, I can see ideas that have been there for 3+ years, some have votes of over 50, some have votes of over 10. Some have been pointed out that the votes are mainly from the same company, but others have not got this breakdown.

A decision to go for making something custom can't be made if it isn't clear what the timeline is for the decision on it to be made, and it isn't clear how ideation is prioritised when the evidence is that they're sat there for so long, and presumably over time customers will come and go which would muddy that further.

There needs to be better action and clarity of whether the person posting the ideation should consider going the custom route without the alternate silence of waiting for ideation resolution.

Ben Tiedt said:

It should likely be custom if it is needed sooner than it will be included in the platform if it is scheduled to be included in the platform by default.

This is the crux point here that I believe needs more transparency so the decision can be made.

If I look through the ideation, I can see ideas that have been there for 3+ years, some have votes of over 50, some have votes of over 10. Some have been pointed out that the votes are mainly from the same company, but others have not got this breakdown.

A decision to go for making something custom can't be made if it isn't clear what the timeline is for the decision on it to be made, and it isn't clear how ideation is prioritised when the evidence is that they're sat there for so long, and presumably over time customers will come and go which would muddy that further.

There needs to be better action and clarity of whether the person posting the ideation should consider going the custom route without the alternate silence of waiting for ideation resolution.