Others will have better advice to give on some of your questions, but I’ll share my POV.

Our community is closed like yours (requiring login via SSO with our systems) and also fully on Insided’s Private setting. But we are transitioning towards what I’m calling a “hybrid” setting: Insided’s Public setting, but with most of the content in various category forums set to be only visible and accessible by registered users (who have access via our SSO). This will open up the community navigation, layout, and structure to be visible to everyone, including a forum or two that will be visible to everyone. After that, we’ll look at alternative ways for people to sign-up and login to achieve a more open conversation for some forums … like you’re discussing. 

But ultimately, my plan, and what I hear in your questions/concerns, is that restricting things to registered users is key. While it appears from Insided category permissions that you can allow Unregistered/logged-out users to post and reply, that’s where I’d expect the most problems with abuse and spam. If you can find a way to offer people to still register/login, but not have to have a login with your platform, that might be good for both lead generation (non-customers creating community profiles) and eliminating spam. Then if there’s abuse, you can ban that user account. 

Tagging @Blastoise186 who has commented before about having experience with spam control and moderation of more open communities. 

@DannyPancratz Thanks a lot for your reply! It makes a lot of sense. 

I’d love to see if it possible to requier people to register using Name + Company’s email + Job title. 
Do you know if is it possible? 

Thanks a lot!! 

Yes, you can set what’s required for them to login with.

However, I’m not sure if you can restrict email address to require the company email. 

Hey, thanks for the tag!

I can definitely give my thoughts on this, but probably not at 1am as I need my sleep! I’ll be back tomorrow with a more proper reply.

@Juliana Spinardi very good question! I’m planning to do exactly what you (and @DannyPancratz)  described and the concern of the quality of users is critical to us, so we’ve discussed a few things and are still in the process of deciding the final approach, so I’m happy to share here:

First of all for the login and identification of users as customers vs non-customers, we’ll be opting for dedicated login methods, meaning that SSO from our App will identify customers, and the standard InSided authentication will identify standard (non-customer) members for the time being. (Google login for staff).
We are hoping this will simplify a few issues, and “force” customers to use their professional address. Then if you require company ass with anything you might or might not get a good answer, and over time this could change too. There are also data enrichment companies/ databases you can use to complete profiles. However the possibly better option we will aim for should tech allow is forcing LinkedIn login for non-customers, which we have not looked into yet, but I’m hoping will fill a lot of the gaps, and while not being a professional address, actually comes with more value and one that lasts.

Then, as you said the scale is also of concern so setting the technical implementation aside (because that should always come second to strategy) we’ve plotted the possible approaches to allow non-customers on a graph of Quantity and Quality of members. We included:

1. Invite only access   

2. Paid membership  

3. Entrance examination

4. Granted request    

5. Free entry to all   

What we concluded (nothing revolutionary but still interesting) was that invite only was probably the most extreme limitation but conferred the highest quality, as opposed to free entry for all, and everything else landed in the middle roughly same area of the graph. (Taking into account our paid membership approach is not trying to monetise the community but simply deter spammers and trolls). Do note that there are many assumptions here and you might want to create your own graph with your community and audience in mind.
Traditionally, one would find the optimised approach somewhere in the middle (2,3,4) but not all approaches are incompatible, so while we haven’t finalised the decision, the option we choose will likely be a combination of 2,3,4 and 5. And sadly this is where we might have to rely on the technical implementation complexity might actually influence the choice between 2,3 and/ or 4.

Finally, the technical implementation, of what is possible out of the box with InSided on this side is low as I see it. You can actually require all users to be validated here:

But I’m not actually sure if there is a way to bypass this approval for certain login methods, so that customers using SSO (and staff members using Google login in our case) are unaffected by this validation for example. ← @Julian can you shed light here?
I’ve actually created a couple of ideas with focus on the invite approach, as I’m hoping uploaded contacts do not need to be approved when this is enabled, allowing for this method to be done out of the box:

They have not been very popular until now.

I hope this helps! I’d love to hear other perspectives and what you are planning yourself to validate or tweak my own approach!

PS: Using Javascript you can likely reject email addresses that have the standard free-mail providers, I found a way to reject email addresses with “+” recently, or any special character for that matter, then it is simply a matter of naming that field “Company email address” and tailoring the error message to reflect what is happening.

Ok, I’m back now and ready to reply with more than just a one-liner. I do have a few strategies that I reserve for extreme emergencies only which I won’t reveal, but here’s what I’ve got for you. Let me also see if @timcavey is around. As the Community Manager on the OVO Forum, he tends to zap all the spam that I catch. :)

First things first… There’s one VERY powerful tool that inSided has had for literally years now!

Don’t worry, I cancelled out of it this time. :)

But the Report/Flag tool is always my first line of defence as a user. I can rapidly report just about any spam or other junk and it gets stacked up in a neat pile for Tim to deal with in Control, or directly from his email inbox. You should definitely make sure it’s configured correctly even for a private community, just to be safe. You never know when it might be needed - and if I can’t reach out to you via this tool… I have to find other ways and that’s not ideal for either of us.

One of the other tools inSided has, is an integration with Akismet Anti-Spam - you need to turn it on if you want to use this! It’s pretty much all set up already, so you just have to flip the switch. Any potential spam it catches goes into the moderation queue for you to double check. If false positives are caught, please approve those posts as soon as possible. Otherwise, if it’s correctly flagged spam, verify the alert and this will result in the spammer being auto-banned as a result. Akismet will not auto-ban anyone by itself as a precaution.

Super Users like myself are another valuable asset. I run a policy of instantly flagging blatantly obvious spam on sight - no matter how long it’s been on the forum for - along with scrutinising more sneaky spam before making a judgement call. I’m more tolerant of experienced and trusted users than I am of someone who’s literally just created their account an hour ago for example. But there’s a lot of factors that I consider and it’s hard to describe them all.

Most of the spam I see is so blatant, that I doubt many users would fall for it - but some of it is outright malicious and you can be sure that Tim will definitely accept my flags as soon as he spot the alert. He also won’t hesitate to throw down the banhammer on sight if he happens to get there before me.

All of the anti-spam efforts that I do on the OVO Forum contribute back to Akismet automatically and helps it to learn. This means that my protection over there is beneficial to all of you in a small way. Everyone wins!

For the less obvious stuff, Tim sometimes asks me for help in figuring it out. It’s not very often that happens, but it’s not impossible either. Trust your judgement and if you're not sure, consider just deleting the post/comment without using the spammer button. That way, it’s easier to restore later if needed. But do NOT click on dodgy links to investigate them!!!

For anything malicious, I also drop a warning to other members to give people a heads up. Tim obviously has to delete these as well to fully clean things up, but he just uses the regular delete button on my comments so that the anti-spam doesn’t ban me by mistake.

Never be afraid to run a public community though. It can be rewarding especially once it gets going.

@Blastoise186 @SmartlyGreg  THANKS  a lot for your thoughts! 

I really appreciated it. 

No worries! :)

In actual fact, if Tim stops by he can probably give you a ton of advice as well. While I unfortunately can’t be helping to zap spam in every community directly, rest assured that my efforts on the OVO Forum and here on inSpired do help to make the filters improve.

In fact, I know Tim well enough to know he’ll probably happily share ideas and tips with just about anyone. :)

 First of all thanks @Juliana Spinardi for asking your question here, since you’ve published it I basically wanted to respond, however time is not on my side these days - but is is getting better!

I think there might actually be a solution that has not been discussed so far, so I might be able to help. To grow as a community, I think it is important to open the community to as many people as possible. So “opening up” by allowing to register directly with username and password is surely one way to achieve that (next to not setting the platform visibility to "private”, which I would try to avoid if there is any way to do that).

You've mentioned worries about spammers (trolls are less of an issue most of the times), and I can only agree. In a perfect world, you could add a "community-account” option to your SSO registration flow, to offer a solution to those users that do not have a “regular” SSO login to your company platform. There are successful examples for that, which also keep spammers at bay. I understand however that this might be a bigger challenge to your colleagues from an infrastructure / database perspective.

A completely different, and potentially optimal solution could be to adjust your permission management so that only trusted users are allowed to create content. I would approach it something like this:

1. Create a custom user role Trusted User. We will use this role to identify users that we want to allow to post (tbd. e.g. identified as customer / employee of a company). You could also split this into multiple custom roles btw.)
2. Set the categories up so that users with such a custom user role is allowed to create topics / replies. This will restrict the permissions to these users once we restrict activity for regular users with the role Registered User.
3. Adjust your SSO payload to include a new parameter for this custom role. Without having IT knowledge myself, it should be possible to send over such a static value, e.g. "1”. We will need that to have inSIded automatically assign the role
4. Our support team will assist you to map the value to the corresponding custom role. This will finalize the first step to allow users that register / log in via SSO to participate.
5. Define a process to identify trusted users. Ideally this is not manual (though I did that for a long time on this community), but there are ways to look up if it is a person that you already engaged with (e.g. Hubspot, Salesforce, etc.) or has an email address that can be associated with an actual Business. This is usually done via e.g. Zapier.
6. Remove rights to create topics / comments for the primary role Registered User. This way, any regular user will not be able to be active any more on the community.

This is just an idea that came to my mind while reading your comments. It might not be the golden solution for everyone, but in the case of inSpired we are successfully doing this (besides not allowing all regular registered users to post, we do allow this here and rarely have issues with spam).

I hope this helps you with your challenge, would love to hear which solution you have decided for in the end!

And to answer your question, @SmartlyGreg:

Finally, the technical implementation, of what is possible out of the box with InSided on this side is low as I see it. You can actually require all users to be validated here:

But I’m not actually sure if there is a way to bypass this approval for certain login methods, so that customers using SSO (and staff members using Google login in our case) are unaffected by this validation for example. ← @Julian can you shed light here?

No, I am not aware of anything that can bypass this feature. I would only recommend to only use this in extreme situations, e.g. dealing with large amounts of spam or unwanted behaviour. To me this is more of an emergency brake, I do not know any community that is using this on a permanent basis.