Recent Content
About Aurora badge rules and supported criteria
For each community badge you want to create, you must define the rule that determines how a member achieves or receives the badge. For simpler rules, you can use the built-in tool that enables you to select a criterion and additional qualifiers. However, if you want a more complex rule for a badge, you can use the Advanced Editor to enter badge formulas. Badge formulas include a combination of a formula clause type, a keyword, an operator, and a value. When the calculation of a value in a formula returns a true result, the member achieves the badge. The badge achievement is then reflected in their profile and badges page. To create more complex badge rule expressions that require multiple rules be met before awarding a badge, you can use the “AND” operator. Common use cases for badges with multiple rule criteria include profile completion tasks and more complex engagement options. For example, you may want to award a “VIP Contributor” badge to members who: Have received at least 100 likes Have had at least 25 answers marked as Accepted Solutions Have posted at least 10 blog articles Tip: You can also use community roles as an additional requirement for any badges based on activity. By taking advantage of the “unlocking” game dynamic, you can set certain badges to be earnable only after a community member has reached a rank that grants them the required role. Create a complex badge rule Go to Settings > Users > Badges. To add a rule to a badge in an existing badge set, click the name of the badge set that contains the desired badge and then click Add Badge. Otherwise, create a new badge set where you want the badge with complex rules to live (see Create badge sets and badges). After entering the badge Name, Description, and Icon, in the Criteria drop-down menu, select Advanced Editor. In the Advanced Editor field, enter your custom badge rules. Enter each rule you want met (making sure that each rule has an identifier, operator, and value). Enter AND between each rule. Select the Hide from member profile until earned checkbox to ensure that the badge is displayed on member profiles only when the rules are met. Click Add Badge. Let’s say you want to create a badge for new members to encourage them to begin participating in the community. You might create a rule like this: metric.net_overall_threads >= 5 AND metric.net_kudos_weight_received >= 20 AND metric.net_accepted_solutions >= 3 This complex rule may be great for a badge that rewards users for creating new content with great quality. Feel free to use this example for your own community! Note: You cannot create complex rules with OR or NOT. Supported badge clauses and badge criteria A badge formula can include one of five types of clauses depending on the type of behavior you want to reward. You can chain rules together to create complex criteria using these clause types: Metric: Assigns a badge based on the value of a specific community activity recorded for each member. Member in role: Assigns a badge to a set of members based on community-level roles. User ID in set: Assigns a badge to a manually specified set of members based on their numeric user ID. This should be reserved for awarding rare badges to a small group of members. Non-Default profile setting value: Assigns badges based on members changing the default state of a specific setting or profile field on their member profiles. Specific profile setting value: Assigns badges based on the member changing a setting in their profile to a specific value. (For example, you could award a badge when a member sets their profile language to French.) Clause Type Clause Format (variables in bold) Metric metric.name_of_metric >= number Example: metric.net_accepted_solutions >= 1 Roles user.role.name in ['role'] Example: user.role.name in ['Administrator', 'Khoros'] User ID user.id in [id] Example: user.id in [10, 2, 5] Non-default profile setting setting.setting_key != 'default' Example: setting.profile.location != 'default' Profile setting value setting.setting_key = '[value]' Example: setting.profile.location = 'Argentina' Rewarding user activity using metrics For definitions of exactly what these metrics are, refer to these Aurora Analytics Metrics Definitions. The following member activity metrics are supported for use in a badge formula using the format: metric.name_of_metric >= [number] Accepted Solutions metric.net_accepted_solutions All Content Types metric.net_overall_posts metric.net_overall_replies metric.net_overall_threads Blogs metric.net_blog_articles metric.net_blog_comments metric.net_blog_posts Forums metric.net_posts metric.net_threads metric.net_replies Ideas metric.net_idea_threads metric.net_idea_comments metric.net_idea_posts Images and video metric.image_upload_count metric.video_upload_complete_count Likes metric.net_kudos_weight_given metric.net_kudos_weight_received Message views metric.message_views Sign-ins metric.logins KBs metric.net_published_tkb_articles metric.net_tkb_comments Rewarding specific members You can award badges to a specific group of members based on their role or user ID. Since you can’t edit a rule after you create the badge, we recommend using roles as the basis of your rule criteria. That way, if you need to add or remove members later, you can modify the member list for the role independent of the badge rule criteria. Important: If you want members to be notified (via email or real-time notifications) of a role-based badge, you must roll out the badge first and then add the role for that member. If the member already has the role before the badge is published, the member will not be notified. Keep in mind: Newly created badges are automatically applied to all members who already match the criteria, resulting in email notifications being sent out to community members depending on your badge notification settings. You need to coordinate such badge releases with Khoros to avoid a surge of emails being sent out to the community members, which can impact your community performance. Use single quotes around the role name. Use commas if you enter more than one. For example, to award a badge to all members with the “Admin” or “Moderator” role, enter this rule criterion: user.role.name in [‘Admin’, ‘Moderator’] You should use "user ID in set" in badge criteria only if you have a static, unchanging list of specific members. This clause type should be used only in special cases to award badges for one-time achievements. Otherwise, you’ll need to delete and recreate the badge each time you want to add another member’s user ID to the rule. Use commas if you enter more than one. For this case, use this format: user.id in [10,2,5] Rewarding profile completion You can use the profile setting below to create badges that reward members for filling out more information about themselves in their profile. These settings can all be used with the "Non-default profile settings" clause. Profile setting identifier Setting name Setting location setting.profile.name_first First Name My Settings > Personal setting.profile.name_last Last Name My Settings > Personal setting.profile.location Location My Settings > Personal setting.profile.biography Bio My Settings > Personal > Bio setting.profile.url_homepage Personal Site My Settings > Personal avatar_changed Note: To award a badge when a member changes their default avatar image, use this syntax: avatar_changed = true Avatar My Settings > Personal > Edit Rewarding date-based activity You can award badges based on date-based activities. Setting identifier Setting options Examples consecutive sign-ins number setting.user.max_consecutive_logins >= 2 registration_date date registration_date > "2015-01-01" (see supported syntax options below) time_since_registration time value in days, months, or years time_since_registration >= "1 years" signin_date date signin_date > "2015-01-01" (see supported syntax options below) About sign-in related activity We store a counter of the number of days in a row and the last sign-in time. When someone signs in, we get the date of the last increment and the date of today, and we count the days between. If < 1, we ignore it (so no gaming the system). If == 1, we increment the day counter. If > 1, we set the day counter to 0. About entering dates You can enter dates (which must be in quotes) in all formats supported by ISO 8061: Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) where: YYYY = four-digit year MM = two-digit month (01=January, etc.) DD = two-digit day of month (01 through 31) hh = two digits of hour (00 through 23) (am/pm NOT allowed) mm = two digits of minute (00 through 59) ss = two digits of second (00 through 59) s = one or more digits representing a decimal fraction of a second TZD = time zone designator (Z or +hh:mm or -hh:mm) Note: When an ISO 8601 date doesn't specify a time zone, it is considered to represent local time. We do not override the local time zone for this purpose, so the date is parsed from the badge clause based on the server's local time zone. So that will differ depending on the AWS region: US-West-2 (PST) EU-West-1 (CET) To prevent confusion on the Internet, date strings (for example, in badge clauses) may specify a time zone. Related topics: About Badges and Badge sets Create badge sets and badges Feature badge sets on the member profile Delete badge sets and badges Example badge sets and badges View badges from the member profileBroadcast private message with API not being sent to all users
Hi Everyone, Seeing something a little strange that I can't figure out. Working on a custom component that sends a broadcast message to all the voters on an idea. Testing on stage I see only around half of the messages are sent no matter how many I send (sometimes over sometimes under). So, for example, a message that was supposed to have 200 recipients might only send to 120. You can see below there were 201 voters in this case. The large console log that says bodyString is the body of my API call and I copied it and double checked. All 201 users were present in the body. But the response from the call shows only 122 recipients. And it is not a consistent limit. If I send to 800 users, it goes to 339. However, if I send to 800 users from the out of the box private message page all 800 go through. I am only able to test this on stage with large numbers so I'm not sure if it could just be an issue on stage. I don't want to spam hundreds of real users to test on production 😀 Has anyone else got any experience with this? Thanks
Aurora: Escalate discussions to Salesforce
Forum discussions can be escalated either manually or automatically You can also escalate replies to forum discussions. Members with the View escalations permission can see the details about the escalation. Manually escalate forum discussions to Salesforce Members with either the Escalate a discussion to the CRM systemand the Escalate one's own discussion to a CRM system permission can escalate discussions to Salesforce. Those with theManage escalation settings and providers permission can also set the Escalate discussions settings for the forum board. To manually escalate a discussion: Open the Options menu for the discussion. Click Escalate to Salesforce. A window opens where you can enter the details for the escalation. Enter the Reason and Comments for the escalation. Click Escalate. You receive confirmation that the discussion has escalated successfully. On the discussion page, you can see that the discussion was escalated along with details on who escalated it and when. Escalate discussion replies Members with either the Escalate a discussion to the CRM system or the Escalate one's own discussion to a CRM system permission can escalate discussions to Salesforce. Automatically escalate discussions to Salesforce You may want to automatically escalate discussions or replies within your community. This urgency could be due to issues raised by members with elevated roles or the need to promptly address and resolve cases within the community. To address this, you can designate a board specifically for discussions and/or their replies to be escalated automatically. You can also set a waiting period for a response (either a reply or a solution), after which the discussion is escalated automatically. Let’s understand these settings: Scenario 1: If you want to automatically escalate a discussion based on the author’s role, set the Automatic escalation by role settings as shown below. In certain cases, you may not want to regulate escalations from specific members within the community. For instance, admins and moderators might post discussions solely for informational purposes rather than issues or cases requiring escalation. Follow the steps below to implement this control: Click Edit next to the Automatic escalation by role setting. A window where you can set the roles opens. You can do one of the following: Select Exclude escalation of posts from the roles below. In the following example, the roles Administrator and Moderator are selected. This ensures that discussions authored by members with these roles are not automatically escalated. Select Only escalate the posts from the roles below. In the following example, a “CategoryExpert” role is selected. This ensures that only those discussions authored by members with these roles are automatically escalated. Click Save. Scenario 2: To prevent discussions from remaining unattended for extended periods and potentially leading to unresolved issues, you can turn on the Automatic escalations for unanswered discussions option. Configure the Wait time before escalating unanswered discussions settings to ensure timely escalation. Click Edit to set the time in minutes to wait until the discussion is escalated, and click Save. In the example below, discussions in this board are escalated to Salesforce if they remain unanswered for 2 days. Scenario 3: To prevent discussions from remaining unresolved (Mark as Solution) for extended periods, you can turn on the Automatic escalations for unsolved discussions option. Configure the Wait time before escalating discussions with no solutions settings to ensure timely escalation. Click Edit to set the time in minutes to wait until the discussion is escalated and click Save. In the example below, discussions in this board are escalated to Salesforce if they remain unresolved for 2 days. View escalation details On the discussion page, members with the View Escalations permission can see the details about the escalation. Click View Details to view case details such as case number, when and by whom the discussion was escalated, the status of the case, and the last update date.
