Feedback submitted into Centercode leverage Feedback Types. By default, you’re provided with Issues, Ideas, Praise, and Discussions. They are fully customizable to help you reach your feedback goals.
In this guide, you’ll find answers to many of our most frequently encountered questions and issues. Click the link for in-depth details and troubleshooting steps or scroll below to locate it.
Access Control is a core concept to understand in order to administrate your Centercode platform. Access to resources within Centercode, whether Surveys or software downloads, Feedback or Notices, is controlled by the combination of Teams and Roles (in this case, Feedback Roles). Teams allow you to organize and grant access to specific groups of Users within your Community and Project. Feedback Roles specifically designate the access and responsibilities to each respective team.
Together, Teams and Feedback Roles set access on a broad level, affecting multiple users. In order to provide the right level of access, you may need to adjust user Teams multiple times throughout a Project. Given this fact, there are many different ways to adjust and control a user's Team assignment, from when users are onboarded, to on-the-fly corrections. This article will cover the various methods of initiating and adjusting a user account's team assignment. (Read more)
What to Do When Users Can’t Submit Feedback?
When it comes to Feedback, there are potentially 3 platform areas to check for appropriate configuration and it's often a combination of the following:
- Feedback Roles
- Element Level Access
Feedback Roles grant access to Submit Feedback, while Workflow controls the feedback’s lifecycle and how it’s addressed. Element Level Access is an optional setting that controls how certain teams may view and modify your Feedback or Survey form. (Read more)
How do I edit feedback?
You'll need to ensure that your account is on the "Ownership Team". You can see that team when viewing feedback and looking at the right-hand side of the screen, underneath the submitter's information.
Another way to check the Ownership team is by going to Project Tools > Feedback > Click modify pencil > Workflow. You'll look down to the tester team that's submitting feedback, check the "New" row, and identify the Ownership Team. This means that when a tester submits New feedback, it goes to x team to take care of it.
This scenario typically impacts those on the project managers team because they're likely going to be solely on the Project Mangers team. Feedback typically is assigned under another team, like Beta Support. For Project Managers to have the ability to Check Out feedback, they need to be part of that team (the one you find as the Ownership Team).
What is Workflow?
Workflow dictates how each team can modify and submit feedback. Statuses are used to identify the lifecycle state your feedback is in. Ownership Destination refers to the team responsible for that feedback based on its Status and the team that moved it to that stage in its lifecycle.
This above is the Workflow of a Beta Tester Team. It can be read as follows:
- Beta Testers have access to “New” Status feedback; their feedback is defaulted under the New Status because it’s their only available Status
- Once the “New” Status feedback is submitted, the Tester Support team becomes the owner; ownership grants edit access
- External Destination is optional and typically for specific use-cases, such sending tickets to Jira (Read more)
- The Modify pencil dictates optional email template notifications, typically to the Ownership team (in this example, Tester Support) and/or submitter (Read more)
Once feedback is submitted by the Tester team, its the designated Ownership team’s Workflow to consider. We’ll build on the above’s concepts:
- Once a Beta Tester submits feedback under the “New” status, Tester Support takes over as Owner
- Tester Support may submit or place feedback into any of the designated Statuses (New, In Progress, Need More Information, Sent to Jira, and Closed)
- The Ownership team stays with the Tester Support team, shown by “No Team Change”
- Only the “Sent to Jira” status will send the feedback to Jira
- Email notification can be configured within the Modify pencil
What’s the recommended Workflow?
A typical configuration can be found here. This shows your primary Participants team able to only submit New feedback with Beta Support (Internal Members) being responsible for that New feedback. Beta Support can then change the status of feedback they own to all available to them (In Progress, Closed, etc.).
Why are teams missing in Workflow?
Teams displaying in Workflow indicate that they're able to submit Feedback. What you're then setting up in Workflow are the Statuses your Teams have access to use. Statuses then execute Team Ownership and any Notification emails. (Read more)
How do teams get email notifications for new feedback submitted?
There are 2 options to consider: Workflow notifications and Feedback Subscription
Workflow emails send out your custom email template to specifically designated teams depending on certain statuses. (Read More)
Feedback Subscription allows users to ”follow” feedback. They’ll receive email notifications for newly submitted feedback and comments. (Read More)
Missing Submit Button
If a Team does not have access to any Statuses, the "Submit" button in the left-hand menu won’t display for them (shown below). Your Team(s) must have access to submit at least the "New" Status in your Feedback Type's Workflow and at least 1 "Access" role in the Feedback Type's Role tool.
From the Project Homepage:
- Click Project Tools
- Click Feedback
- Hover over your Feedback Type
- Click Modify pencil
- Click Workflow
- Identify any Teams missing New status and grant access
- Click Submit
- Click Feedback Roles
- Ensure an "Access" role is enabled for your teams
Can a tester edit feedback once submitted?
It’s strongly discouraged because this enables feedback to shift from underneath you.
How do I change feedback statuses in bulk?
This can be done through the Mass Feedback Modify function. It’s effectively an on-the-fly Feedback Macro, but can be quick and convenient for changing the Status or other custom fields on a Filter or resulting List of Feedback. A common use-case would be to close multiple pieces of feedback at once, rather than individually. (Read more)
What are Feedback Roles and what do they do?
Feedback Roles are a static set of named Access Roles, available per Feedback Type, that allow Project Managers to provide granular control over accessing Feedback within their Projects. These Roles only pertain to Feedback, usually including Issues, Ideas, Suggestions, Discussions, or custom Feedback Types you create. (Read More)
How does Predictive Match work?
Predictive Match presents testers with feedback that matches keywords in the potential submitter’s title and description. When the potential submitter enters their title and a match is displayed, they can select “This matches,” “Not a match,” or “Create New Feedback.” When selecting “This Matches”, the “parent” (existing) feedback’s Feedback Score is increased (Read more)
Can I disable Predictive Match?
Certain use cases may require disabling Predictive Match, such as leveraging private Feedback Types (Support, Contact Us, etc). Predictive Match is specifically a Feedback Role attributed to a team in your Feedback Type’s settings. (Read more)