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.Pull different Aurora community content into an RSS feed using URLs
You can pull different community content from different levels in the community in an RSS feed using URLs. To pull the most recent RSS results for the entire community, use: https://yourdomain.com/t5/s/[CommunityID]/rss/Community For example, for Atlas, you'd use: https://community.khoros.com/t5/s/lithosphere/rss/Community To pull content over the RSS for a category, use: https://yourdomain.com/t5/s/[CommunityID]/rss/Category?category.id=[CategoryID] For example, if Atlas had a category with the ID of "Social," you'd use: https://community.khoros.com/t5/s/lithosphere/rss/Category?category.id=Social Note: Category IDs are case sensitive. To pull content over the RSS for a KB, use: https://yourdomain.com/t5/s/[CommunityID]/rss/Community?interaction.style=tkb For example, for Atlas you'd use: https://community.khoros.com/t5/s/lithosphere/rss/Community?interaction.style=tkbBest Practices: Community Experience Surveys in Aurora
Community Experience Surveys provide community managers with a way to identify issues and optimize the community. Does this replace my existing survey tool? No. The Community Experience Survey complements any existing survey tool you may have. However, the Community Experience Survey provides more granular member details, such as node- and rank-specific data, that other tools can’t provide out of the box. Where should I deploy the survey? Where you deploy the survey depends on what questions you want to answer. For example, if there are certain boards you want to focus on, then deploy the survey there. However, you can also deploy surveys in the entire community first to get a sense of the baseline response and response in each place since you can always filter at the board level in the CSV Export for survey responses. When should the survey fire? We recommend not firing the survey immediately when a visitor lands on the page as it is disruptive to the user experience. (Remember, your visitors are there for a specific reason, and you don’t want to get in the way of that goal.) However, at the same time, you don’t want to wait too long to fire the survey as the browser session may expire. We recommend something in between. One approach is to see what your average Member Time on site is from Community Analytics and reduce that value by 20% to get close to the time when a user is nearly complete with their task/session. How long should I run the survey for? How do I know I’ve collected enough data? We recommend running the survey continuously so that you have a larger set of data to analyze. Visitors will receive the survey once within a 90-day period (by default, but this setting is configurable). However, if you plan to turn the survey off at some point, we recommend keeping the survey running for as long as it takes for the mean/average of the results to stabilize and not change much with additional samples. What’s a good response rate? For web-based surveys, 5-15% is a good response rate. For mobile-based surveys, 10-20% is a good response rate. Since the majority of community traffic is still web based, you should hope to see about a 10% response rate.Aurora: View community experience survey results
Admins can enable community experience surveys, which prompt members to provide feedback about their experience in the community (see Create community experience surveys). Survey responses and scores can be collected via an export. These results are in CSV format. To export community experience survey results: Open the Account menu. Select Settings. Select Content Features. In the left column, select Community Experience Survey. In the Questions and Answers section, beside Survey results, select Export. The CSV file contains the following information for each visitor who responded to the survey: The date on which the survey was taken The place in the community where the survey was triggered The username of the member who took the survey The member’s rank The member’s role(s) The answers given to each questionAurora: Create community experience surveys
Admins can enable community experience surveys surveys, which prompt members to provide feedback about their experience in the community. Survey responses and scores can be collected via an export (see View community experience survey results). Create a survey Creating a survey requires several configuration steps, including designing the branding, designing its behavior, selecting its questions, and finally, turning it on for visitors. To access survey configuration options: Open the Account menu. Select Settings. Select Content Features. In the left column, select Community Experience Survey. Set up your survey: Design survey branding Design survey behaviors Select your questions Turn on the survey for visitors Design survey branding In the Branding area, select Edit. In the window, update the following as needed: Community name: The community name used in survey questions Brand name: The brand name used in survey questions Survey logo: Use a PNG or SVG logo; horizontal preferred. Text color Header background color: Used in the background of the survey header Select Submit. Design survey behaviors In the Survey Behaviors section, select Edit. Select whether you want to Present To: Signed-in members Anonymous users Both members and anonymous users (Optional) Select the role(s) you want to survey. (Optional) Select the role(s) you don’t want to survey. (Optional) Select the place(s) where you want the survey to be triggered. In the Frequency area, enter the number of Maximum responses to collect per month. This field sets the maximum number of surveys to collect for a given calendar month. After collecting this number of responses, no users will be prompted to take the survey until the first day of the following month. Enter a number of visits in the Present survey after this many visits field. This field sets the number of visits (0-500) to wait before prompting a viewer to take the survey. For example, if set to 3, the viewer isn’t prompted to take the survey until their fourth visit. Default = 0, which is the first visit. Enter a number of minutes in the Present the survey after this many minutes field. This field sets the number of minutes (1-60) to wait before prompting a viewer to take the survey after the defined number of visits have occurred. Default = 2. In the Conditions area, enter a number of days in the If declined/abandoned, repeat after this many days field. This field sets the number of days (1-365) to wait before prompting a viewer to take the survey after they’ve declined to take the survey. Default = 30. Enter a number of days in the If completed, repeat after this many days field. This field sets the number of days (1-365) to wait before prompting a viewer to take the survey again after they have already completed it. Default = 90. Select Save. Select your questions In the Questions and Answers section, select Edit. Use the toggles to turn on or off the questions you want to include or exclude on your survey, respectively. Some questions have follow-up questions based on the selected responses. Note: Because this survey is intended to gather important metrics and feedback, including CSAT (Customer Satisfaction Score), updating question titles and the order of questions is not permitted. Use the checkboxes by responses under your selected questions to designate which responses will be available for those taking the survey. Select Save. Turn on the survey for visitors After you have designed your survey the way you want it, you can enable it for your visitors by turning on the Community Experience Survey toggle at the top of the Community Experience Survey section.Aurora: Community email options
Khoros Communities offers several email configuration options to ensure the deliverability and security of emails sent from your community. This article goes over the common email configurations that Khoros provides in a standard community launch. Note: Additional email configuration options might be feasible but aren't included in your community launch. Consult with your Khoros representative for more information. Modify sender name and address You can modify the sender name and address of community emails in the admin settings. For example, emails are sent from “Community Mailer” and "mailer@us.khoros-mail.com" by default in US-based communities. You can change this to something better tailored to your brand, such as “Acme Community” and "notifications@mailer.acme.com." Refer to Edit the Aurora community email sender name and address for steps. SendGrid SendGrid is Khoros’ current default relay used by most of our customers. SendGrid features higher mail delivery rates and is capable of handling much more traffic. However, due to our infrastructure, SendGrid does not support strict DMARC policies (“none” is supported). SendGrid is required for the Community Analytics (CA) metrics reporting feature. We do not support Community Analytics email reporting for any other relay type. Sender Policy Framework (SPF) Khoros strongly recommends that all customers update their SPF records to include the region-appropriate Khoros domain. This helps provide a good balance of deliverability of mail from Communities, reduce setup time, and increase security. Sender Policy Framework (SPF) records enable domain owners to publish a list of IP addresses or subnets that are authorized to send emails on their behalf. The goal is to reduce the amount of spam and fraud by making it more difficult for malicious senders to disguise their identity. SPF records can be set only on the A DNS record, not a CNAME DNS record such as (community.customer.com). We strongly recommend that the sender address is a subdomain of your primary domain and that the SPF record is set on that subdomain. For example, if your primary domain is [customer.com], we recommend the sender address to be a subdomain such as [anything@mail.customer.com] and to set the SPF record there. Refer to Configure SPF records for community emails for more information. DKIM (DomainKeys Identified Mail) DKIM (Domain Keys Identified Mail) is an email authorization technique that leverages unique keys to digitally sign mail. This is done by adding an encrypted DKIM signature to the message header. DKIM helps combat certain techniques often used in phishing and email spam, such as emails with forged sender addresses that appear to come from legitimate organizations. This configuration requires coordination with Khoros in order to exchange key information and configure the Khoros mail relay properly. Note: Strict DMARC policies are not supported and require a Custom Relay instead. Refer to Configure DKIM for community emails for more information. Custom Relay In the rare case that none of the above options are acceptable, you can use your own mail servers for delivery. Essentially, all email outbound from Community are sent to your mail server first and then out to complete the delivery. This solution involves additional engagement with the Khoros Professional Services team.Aurora: Configure DKIM for community emails
DKIM (Domain Keys Identified Mail) is an email authorization technique that leverages unique keys to digitally sign mail. This is done by adding an encrypted DKIM signature to the message header. It helps combat certain techniques often used in phishing and email spam, such as emails with forged sender addresses that appear to come from legitimate organizations. Our customers commonly implement DKIM records together with SPF to meet DMARC policies. This can provide better protection for your domain against malicious emails sent on behalf of your domains. Learn more about SPF setup. Note: Khoros cannot support a custom DKIM implementation in conjunction with SendGrid custom relays. Custom DKIM implementations also prevent the use of Communities Email Analytics. To perform this implementation with Khoros: Provide Khoros the mailer address to be used. Refer to Edit the Aurora community email sender name and address for best practices regarding the address choice. Khoros will provide the DKIM selector and key, which your teams will then install on the target mailer subdomain. Validate the DKIM configuration using tools such as mxtoolbox. The domain to check is the part following the @ symbol in your mailer address. For example, if your address is notifications@mailer.customer.com, then the domain to check is mailer.customer.com. Ensure all checks pass with the domain and selector. Once the DKIM configuration on your DNS entry is validated, Khoros completes the final Community configuration. Best Practices Refer to Edit the Aurora community email sender name and address for best practices regarding the choice of mailer address. You must use DKIM if you have restrictive DMARC records in place, even if you do not want to DKIM sign emails. The strictness is indicated below: Strict - Reject Strict - Quarantine (with a 25%+ apply percentage) policy Relaxed - Quarantine (with a < 25% apply percentage) policy Relaxed - None policy DKIM deliverability is not as high as with SPF only due to the IP addresses of the Khoros DKIM mail relays being newer (~2020) and part of AWS’s IP space. These relay servers may never be considered trusted by some email vendors for this reason, thus being more susceptible to emails being blocked. You must ensure there is no SP (Subdomain Policy) attribute present on the same subdomain. This can result in your top level DMARC policy being applied to your subdomain, and as a result, email not being delivered. To do this: Go to https://mxtoolbox.com/DMARC.aspx. Add your domain in the field (for example, khoros.com or everything after the @). Select DMARC Lookup and see if an SP message is displayed, which should look like this: “Organization Domain of this sub-domain is: example.com Inbox Receivers will apply example.com DMARC record to mail sent from mail.example.com”Aurora: Configure SPF records for community emails
Khoros strongly recommends that all customers update their SPF records to include the region-appropriate Khoros domain. This provides a good balance of deliverability of mail from Communities, reduces setup time, increases security, and allows the use of email metrics. Find the region-appropriate line below, replacing “customer.com” with your own subdomain to add to your SPF record on the subdomain used to send emails: For APAC Communities: customer.com 86400 IN TXT "v=spf1 include:ap.khoros-mail.com --all" For NA Communities: customer.com. 86400 IN TXT "v=spf1 include:us.khoros-mail.com -all" For EMEA Communities: customer.com. 86400 IN TXT "v=spf1 include:eu.khoros-mail.com -all" This step enables Communities to securely send emails on your behalf from that subdomain. Verify that the SPF record is publicly accessible and correctly configured. You can use a SPF Check and Lookup tool to accomplish this task. Configure the email address as described in Edit the Aurora community email sender name and address. Validate your configuration by taking any action in your community that will trigger an email. Verify that the emails do not go into your spam/junk folder and have the intended sender address. Note: This process applies only for email configurations involving relaxed or no DMARC policies. If you require a stricter DMARC policy or any alternative configuration, contact Khoros or refer to Community email options for additional details.
Aurora Product Coaching Session: Spam Management Best Practices
Khoros Communities platform offers several settings and features that allow you to mitigate Spam in your community. Join our Spam Management Best Practices coaching session to identify, filter and deal with spam effectively. Our coaching session will guide you through the practical tips and techniques to help combat spam and help maintain the hygiene of your community. Topics covered in the coaching session Overview of Aurora spam settings and functionality Manage Content dashboard related to spam management and its features Using roles and ranks to configure permissions to check spammers Content Filters Best practice tips Notes - Admin permissions are required to conduct the call. 👉Click here to Sign Up Related Resources Enable Spam Management Community Spam Management Review Posts Captured as Spam Khoros Academy: Communities Moderation Essentials Khoros Academy Instructor Led Training: Spam Management for Communities AuroraAurora: Assign roles to members in bulk via CSV file import
To assign or remove a large number of roles for members at one time, you can use bulk import via a CSV file. Your CSV file needs to include the following for each member: “ADD” or “REMOVE” indicator Username or email address The roles you want added or removed To bulk assign or remove roles: Go to the Settings > Roles and Permissions page. In the Community Roles area, click Assign Roles in Bulk. On the Assign Roles in Bulk window, browse for the CSV file on your local machine. In the Charset drop-down menu, select the character encoding of the CSV file you’re importing. The default for Microsoft Windows operating systems is windows-1252 for most locales saved through Microsoft Excel. Click Start Assignment. Larger sets of member assignments may take longer to be imported. When the import is complete, you receive an email indicating whether it was a success or if there were any errors that need to be corrected. Related topics: Create a role Add members to roles
