Workflow dictates how each team can modify and submit feedback.
This article applies to Pro, Team, and Legacy editions.
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 defaults 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 as 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, it's 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, as 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 is 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 aren't the changes I made to my Workflow showing up on my current feedback submissions?
Workflow changes occur immediately upon page submission, however, the changes only apply to new feedback submissions moving forward.
If you are checking your Workflow against previously submitted feedback, your changes will not be reflected unless you select Admin actions, then Break workflow. This forces your ticket to adhere to your current Workflow.
If you have any additional questions or concerns regarding workflow changes, please don't hesitate to reach out to our support team in the chat located in the corner of this browser window or via email at support@centercode.com
Related Articles
What to do when users can't submit feedback