Public accessible content vs private

[owlietenil2]

We want to be able to dictate whether an article requires a sign in or not, so we don't have multiple boards with different permissions. As in, some content we might deem public and some behind the sign in wall. Is there a way of doing this at article level at all? Using Labels or Tags?

[StanGromer]

Without some extreme customization, you can't do it at the topic/article level - Permissions are controlled on the node itself so generally speaking you would want to create two different knowledge bases, one public, one private.

[Toby]

Hi @owlietenil2 

My community is private for customers only and I am looking into creating some open content spaces. I have not created the open spaces yes, but I am working with my Khoros rep to create them.
Once I have created these open spaces, I will share within this community.
Best,

Toby

[Fellsteruk]

Not sure if it would work for you but i have achieved this in my own community with the use of just two boards

board1 - this is public, all tbk live in this board that i want anyone to see

board2 - this is private, only accessible with role, anything i want to mandate a signing lives here

All content is categorised using labels which are consistent across both boards, if a normal user or unauthenticated user signs in they see all the public content, if a "special user" one with access to board 2 they get to see all of the public and private content. 

To mandate a signin, you're only really, easy/safe route is use of roles to grant access to an area with content 

[adriana4u]

Hello,

Hope to find all doing well.

I'm really happy to have found this thread in here. We also have a closed community but wanted to have open areas for prospects, without opening communities. Do you think this would be possible? What would be the first steps here? 

Counting on you here @StanGromer 😂

[ScottR]

If your community is private (not done solely by permissions), then it is likely configured to disable anonymous access, which redirects a non authenticated user to the SSO flow.  That is a setting that has to be updated by Support, not in the Admin.

You would want to disable this after building out your desired "To Be" structure using the standard techniques other have described.