About Aurora Community site structure
One of the most important aspects of setting up your community is choosing which content types to include and how to organize them. Communities are structured hierarchically—they’re broken down into Places, which are divided into Containers and Boards. Containers consist of Categories and Groups, while Boards consist of Forums, Knowledge Bases, Blogs, Ideas, and Events. Typically, Categories and Groups are made up of Boards—these boards are the areas where community members can post and reply or comment on what they read. Categories can also be broken down into other Categories as necessary. Containers Boards Containers Containers are higher-level Places like Categories and Groups. Categories are areas that can house several types of Boards that are broken out into different types of content. Groups are similar to Categories, but they are designed for specific groups of Community members who want to collaborate on a particular subject or project. Create a Category Create a Group Create a Category Go to the Community Structurepage. Click Add(plus icon) at the level of the community where you want to add the category. On the window, enter a Name and ID. The ID displays in the URL for the category. Note: The ID must be a single word made of only letters, numbers, dashes, and underscores with no spaces. It cannot be changed later. Optionally, enter a Description and add an Avatar for the category. Click Create. For more information, see About Categories. Boards Create a Forum Create a Knowledge Base Create a Blog Create an Ideas board Create an Event board Boards are Places that are subsets of Containers. The types of boards available in your community are Forums, Knowledge Bases, Blogs, Ideas, and Events. Boards enable members to post content, write comments, and reply to other members’ comments. The process for creating a board is similar for all content types. To create a board: Go to the Community Structurepage. Click Add(plus icon) at the level of the community where you want to add the board. On the window, enter a Name and ID. The ID displays in the URL for the board. Note: The ID must be a single word made of only letters, numbers, dashes, and underscores with no spaces. It cannot be changed later. Optionally, enter a Description and add an Avatar for the board. In theTagsarea, specify the types of tags to use, add preset tags, and/or indicate whether you want to require tags for the board. Click Create. Related topics Community Structure Best Practices Community site structure hierarchy and terminology Manage Containers or Boards Container and Board permissionsAurora: Permission descriptions
Each Khoros community permission enables users to perform specific actions. These permissions are assigned (either by default or manually) to different community roles. Permissions are grouped by feature area on the node where you’re assigning them: Accepted Solutions Analytics Badges Blogs Boards Case Portal Categories Community Content Escalations Events Following Groups Ideas Inbox Knowledge Bases Likes Media Member Management Member Profiles Mentions Moderation SEO Tags Widgets A description and a recommendation as to the type of member who should be granted this permission are displayed by each of the permissions so you know exactly what you’re granting and to whom. You can set permissions globally or at the node level (category or board) in the community structure. For each permission, you can keep the out-of-the-box default setting or explicitly Grant or Deny permissions as needed. About permission levels Manage community permission defaults About permission levels Permissions can be set to Inherit, Deny, Grant, or Assign. Inherit – Person has the permission defined in the node or node-level role above the current level. Therefore, this level does not display when you’re managing community permissions defaults but does display for the category, group, and board levels. You can hover your cursor over the Inherit button to see whether the inherited value is Deny or Grant (the button is also displayed as red for Deny and green for Grant). Deny – Person does not have the ability to take action described by the permission. Grant – Person has the ability to take action described by the permission. Assign – Person has the ability to take action described by the permission and has the ability to grant the permission to other members. Typically, this should be given only to Administrator roles. If you look at the Administrator role, you'll notice that all permissions are set to Assign since Admins can grant permissions to other users. As a general rule, only Admins should be able to Assign permissions to others. There are a few use cases where this could change, but typically speaking, Administrators should be the only ones that have the ability to manage permissions in the community. The different permission levels cascade down to any nodes below them, but certain permissions at higher nodes will override lower-node permissions: Assign Overrides any other permissions given at lower-level nodes Explicit Grant Overrides Default Deny, Explicit Deny, and Default Grant at lower-level nodes Explicit Deny Overrides Default Grant and Default Deny but not Explicit Grant at lower-level notes Default Grant Overrides Default Deny but not Explicit Deny at lower-level nodes Default Deny Does not override anything at lower-level nodes Note: If there are conflicts within roles, the explicit exists to override the default. So for example, if you set a permission to Assign at a particular level, all levels below that for that permission will be overridden even if they are set to Deny (including if you manually/explicitly set it to Deny). Note: It is a community management best practice to modify permissions at a role level rather than at a user level to ensure consistency across the community. Manage community permission defaults Setting community permission defaults enables you to grant the base permissions for all members of the community. To manage community permission defaults: Go to Settings > Roles and Permissions. In the Community Permission Defaults section, click Edit. (Optional) To jump to a specific permission to manage, enter it in the Find a permission field. Set Deny or Grant access for the settings in each area. Each permission entry displays a description and recommended deny/grant status, as shown in this example:Aurora: Enable tags and set tag options
Many communities use tags to organize content that exists in different boards. Settings vary depending on where you are in the community. The tag options set for the community apply to all parts of the community, and you can later modify the settings at category or board levels based on your requirements.About Aurora roles and permissions
Your community uses permissions to determine the actions that your community members can take and which community areas and features they can access. Instead of setting each of these permissions manually, permission settings are grouped into roles and then you can assign these roles to members. Khoros provides a set of default roles. You can modify these roles (although we don’t recommend it) and create your own roles. You can also create a relationship between your community ranks and roles so that members get new roles and receive additional permissions as they advance through the ranks. Each role has a setting for each permission. When you define a role, you can set some permissions directly and leave the default settings for the rest. After you define your roles, you can set up the ranks in your community to assign (and remove) roles when members change ranks. The higher the rank, the more access it’s likely to grant the member. In addition to controlling member access within a community, you can also use roles to gather metrics on community usage or to establish criteria for gaining a rank. Although it’s more common to use a rank to grant a role, you can also use a role to assign users a rank. Some communities use this technique, for example, to assign a special rank to community moderators by using a role as the criteria for granting a rank. Similarly, you may want to create a role specifically for your employees. They might have the same permission settings as other community members, but you can use a special employee role as the requirement for a corresponding rank to identify them as employees to the rest of the community. Note: Groups use the default community roles as well as a set of roles specific to groups. Learn more in Group roles and permissions. Related topics: Create a role Default Community roles Permission descriptions Add members to roles Best practices: roles and permissions You can also receive self-paced training on roles and permissions in our Build Khoros Communities course.About Aurora Groups
Groups deliver an enhanced experience for Community members to engage around a common theme or purpose. Each group has its own configurable set of content types (forum, blog, knowledge base, ideas, and events) to organize content and communication. This guide provides overview information about: Group membership types Search within groups Group management Group flood controls You can imagine groups for everything from special interests within the community to focus groups to product launches and more. Groups can be visible and open to anyone in the Community, closed (requiring a request to join), or hidden (invisible to the public and accessible by invitation only). Community Administrators can share group management with Community members by giving a member the Owner role, which enables the member to edit group details, manage membership requests and invitations, and assign and change group roles for members. Members can discover and browse groups on the Group landing page: The Group page provides quick access to the hub's info, contents, recent activity, and members. Administrators and group Owners can perform most group management tasks directly in the Community UI without needing access to Community Settings. On the Create Grouppage, here is a quick look at group configuration options. Note: The Boards section of the page appears to Community Administrators only. The ability to add group child places is dependent on the Add any community-supported boards permission, which is denied by default to the Owner, Curator, Inviter, and Member group roles. Member management is performed in the Manage Members page. An Owner or Administrator can see a list of current members, edit a member's role, remove members from the group, view pending invitations, and accept and deny requests to join. Other important group capabilities include fully-functional search and group subscriptions. Group membership types Every group has a membership type that controls access. A group can be: Open Closed Hidden Important: Membership type and access are managed through Community permissions. There are no other Community Settings to control access. For example, a hidden group is hidden because non-members of that group have the See groups permission set to Deny. Open groups All community members can browse and like all content, reply to posts, and comment on posts of the group. Group members can create new content and browse, reply, and comment on the post. The ability to see and join a group is governed by the access allowed to the container node. For example, an open group placed in a category with the See categories permission set to Deny cannot be joined by a member unless the member is assigned a role with See categories set to Grant. Ways to join: Join Groupbutton on the Group page By invitation from a group Owner, Inviter, or an Administrator Closed groups As with open groups, a closed group is visible only to community members with access to the category in the group lives. Group visibility is governed by the access set on the container node. Non-members do not have read or reply permissions for closed groups. Content in closed groups appears in search results to group members only. Non-members who try to access a closed group are directed to a page explaining that the group is closed and that the user must request access. The request to join is sent to group Owners via email. Members can create new content as well as browse and reply to existing content Ways to join: Join Groupbutton on the Group page. By invitation from a group Owner, Curator, Inviter, or an Administrator. Hidden groups Community members access Hidden groups either by invitation (by group Owner, Inviter, or an Administrator, or by being added to the group directly in Community Admin. Hidden groups are hidden from non-members in the Community UI and cannot be searched. Non-members attempting to access the URL to a hidden group’s page or child places are directed to an error page. Search within groups Content search within a group is fully-functional. All visitors can see content in open groups in community and place-level searches. Open group content is accessible to all. Content in closed groups is accessible only to group members. Hidden group content is searchable and accessible only by group members. Any relevant results in the community-wide search bar also surfaces content inside of groups to users who have permission to access it. Open and closed group nodes and child nodes appear in places search results to group members and non-members. Hidden group nodes appear in places search results to group members only. Group management in the Community UI The Community UI provides basic group management features: Create a group Delete a group Edit group details including group type, child board titles, and avatar Invite new members to the group Remove members from a group Manage group invitations and requests to join Manage group role assignments Group management in Community Admin Community Administrators can define Community Settings at the group container level, just as they can with other containers. In the Manage Members page, Community Administrators can remove a member from a group, edit a member’s role within the group, and manage any pending invitations. Group management by community members with Admin Permissions A community member with the Edit groups and Edit groups in Community Settings permissions can access Community Settings from the Group page in the Community UI and perform group administration actions. The permission adds the Edit Group Settings option to the Group page Options menu. These permissions are denied by default. Important! Be very careful when granting these permissions. It is intended to enable trusted employees to perform group actions that cannot be performed in the Community UI. For example, you may grant this permission to a product manager who is running an Early Access program through a group so that the product manager can quickly add customers to the group. We strongly recommend against granting this permission to your customers. Group flood controls Group members can send up to 50 invitations in an hour and up to 100 invitations per day.Aurora: Best practices: roles and permissions
When you first launch a community, permissions and roles are fairly easy to manage because there are a limited number of roles, ranks, and members. As your community grows, you will need to add new ranks and roles to further segment your membership and reward the most active participants. Although you can set individual member permissions one at a time (not recommended), Khoros Communities are designed to help you manage permissions through a hierarchy of roles at the community, category, and board levels. The advantage to this approach, aside from the obvious reduction in the sheer number of moving parts, is a more predictable and manageable permissions structure. The cornerstone of this structure is a link the system creates between roles that have the same name, but that exist at different levels in the community. When you assign roles to members at the community level, they automatically inherit membership in roles that have the same name at the category and board levels. The settings for the new board-level role are stored with those of the higher-level role. Best practices for working with permissions and roles Keep it simple, especially when first launching your community. In the early days of the community, before your active members emerge, you can get by with just a few default roles (Administrator, Moderator, and Khoros or community defaults). At this stage, you want to encourage participation by making it easy for new members to sign in and start posting. You can add roles later as you need them. Set your community-level defaults to the lowest common denominator in terms of access. These defaults apply to all new community members at all levels of the community and are typically the most restrictive settings. As members gain experience in the community and advance up through the ranks, you can give them additional permissions through roles that explicitly grant access. You can always override these defaults with role-based settings at the category or board level. Create roles at the community level, and then create category- or board-level versions of the same roles if you need them. The purpose of a category- or board-level role is to override the community-level settings for a specific category or board. Members who have the community-level role also get the permission settings from the lower-level roles. The names of the roles at all three levels must be exactly the same—including capitalization and spacing—for the connection between roles to work. For example, “Vip” and “VIP” are not the same. The lower-level settings apply only when members are at that level. For example, a category-level permission applies only to members in that category. Elsewhere in the community, community-level permissions are in effect. Always assign roles at the community level rather than at lower levels. This enables you to manage roles and permissions from a single location rather than having to go to each category, for example, and listing the members who have a role assigned to them. Members get the access allowed by the community-wide settings as well as the category-level or board-level override settings for specific categories or boards. The category- or board-level roles typically give members access to areas or features that are off-limits to the rest of the community. Always use roles to assign permissions. The system is designed to track membership in a role, not individual permission settings. As a result, you can easily determine which roles a member has or which members are assigned to the same role. While you cannot assign permissions to individual members, you can look up which roles & permissions are assigned to a particular member (see Look up a member's roles and permissions.) Observe these general tips: Configure permissions and roles to the Principle of Least Privilege. (Apply only the minimum required permissions for a role.) Change permissions within roles only where the default, inherited permission doesn't suffice. For each role, fully document the function of each role, its included permissions, and its purpose and location (for example, if it exists at child levels of community). Provide these details in the role description. Use an informative and consistent naming convention when creating roles. Clear and concise role names make roles much easier to scan and manage and enable new admins to intuit the meaning/purpose of a role.Aurora Community Structure Best Practices
When you first launch a community, you may think you need to create a structure sophisticated enough that it will accommodate all of your needs as the community grows. However, in this case, building in anticipation of growth might not be the best strategy. For instance, it might be tempting to create every possible category and board you might need, but this is counterproductive. The initial structure for the community should be appropriate for the expected volume of traffic. Essentially, this means you should start small and add containers and boards as needed over time. Ensure your structure includes topics and interests relevant to your members. As you begin building your community, focus on creating content that indexed by organic search (Google, Bing, etc.). Your goal is for the community to scale up and to build critical mass. You want between 5 and 10 new posts per day on each board to effectively attract members to keep coming back. When launching the community, most companies issue invitations via email to alert members to the community. About 10% of the people who see an invitation will visit the community. Within 6 months, you can expect between 30 and 40% of your target audience to visit the community at least once. Of those who visit, 10% will post at least once per month. Although the percentage remains steady at 10% per month, it’s not the same 10% each month. This means that you need 5,000 and 10,000 invitees within the first 6 months to support a single board. As a result, the fewer topics you have at launch, the easier it will be to achieve that essential feeling of activity. The way you organize your community depends to a large extent on its goals. A general purpose discussion community can be organized by whatever topics make sense. A support community is likely to be organized by products or product lines, depending on the products being supported. For example, if you’re supporting computer peripherals, you might have a category for each type of device, with forums or other boards for hardware, software, platforms, and connection. This community has a large number of categories but relatively few topics in each category. If you’re supporting cell phone users, you might have a category for features you offer, one for customer care issues, and a third for phones. This community has fewer categories but more boards per category. Related topics: About Community site structure Community site structure hierarchy and terminologyAurora: Add members to roles
You can add community members to any of the default community roles or the roles you've manually created. A member's assigned role determines what they can and cannot do in the community. You can also assign roles to members from the Member Permissions page as described inLook up a member's roles and permissions. To add members to roles: Note: To add members to a role at a lower level, go to the [Place] Permissions page at the desired level of the community and then add members to the role. Sign in to Aurora as an Admin user and go to Settings > Users > Roles and Permissions. On the Community Roles and Permissions page, click Options menu of the role to which you want to add members and click Edit. On the Edit Role page, click Add Members. On the Add Members window, in the Members field, enter the name or the username of the member to whom you want to assign the role. In the drop-down menu, select the member. Repeat steps 4 and 5 to continue adding members. Note: To remove a member, click the X icon next to their username. Click Save. Note: You can managethe roles assigned to individual members from their member profile page. Learn more about managing member roles. Related topics: Import members from a CSV fileAurora: About images and video
Most communities enable members to add images and videos to their content. Rich media makes content more visually striking and drives member interest and engagement. Note: Image and video moderation is done in conjunction with content moderation so that inappropriate content is not published to your live site. Learn more about content moderation. While writing content, members can add images and videos by: Clicking the Insert Media button in the Content Editor toolbar Dragging and dropping images or videos directly into the Content Editor Copying and pasting images and videos via the clipboard Inline image editing When writing or editing content with embedded images, you perform several quick editing actions. While editing your content, you can click an image to access the sizing controls. Click the small, medium, or large options to choose the image size that best fits your space. Note: You can use the Content Editor toolbar to indent or align the image within the column. Tip: Center-align images in the column to prevent text from wrapping around the image. You can also add a caption for your image, which displays below the image. Finally, you can click the person icon to add Alternative text that describes the image for the visually impaired. Image Viewer When viewing content in a piece of content, you can click any image to view it in the image preview pane. Use the left and right arrows to scroll through any other images in the post. Click the Download option in the top-right corner of the viewer to download a local copy of the image. Banner images for blogs Aurora communities enable you to add banner images to blog posts. You can create and upload your own image or find an image in an online library, powered by Unsplash. Learn more about creating a blog post. Related topics: Manage image and video settings and permissions
