Product Issue - Development Queue

Contents

Purpose
Development Status
Process Flow
Reject a Possible Issue
Salesforce Case Closing

Purpose

This document walks through how a product issue case moves through the development process and when the customer and case owners are notified of changes in status.   

The Product Issue Flow outlines how a case will be moved between resources/departments throughout the process.  It also highlights the automated customer messaging that is sent at each stage.    

Development will base priority on many factors.  Cases will be ranked on several criteria listed in the Dev Case Priority Dashboard.  This dashboard is used to determine which cases have the highest priority.  

Return to Contents

Development Status

The status of a case while in the development process will always reflect Transferred.  It is the status of the linked Dev Ops request that will reflect where in the development process a case is and what updates are sent to customers and when.  The Dev Ops information is located in the QW Connector section of the case. 

The following fields are key to understanding the flow: 

  • Work Item/Issue Number: Linked Dev Ops case number
  • Work Item/Issue Status: Status of the case
  • Sprint Path: The development sprint the cases is currently scheduled in for fix.  Sprint scheduling is fluid and based on many factors.  Thus a case may  be moved to a future sprint at any time
  • Released In:  The product release that contained the fix

The ID and Dev Link fields allow the user to open the Dev Ops case to review.  

Below are the different statuses that will trigger an update to the customer:

  • New:  Transferred to Development from the Triage queue awaiting scheduling
  • Active: Assigned to a developer for deeper review and fix
  • Resolved In QA testing
  • Closed: Passed initial testing, awaiting release

There are additional Dev ops case status levels that will not trigger an update to the customer:

  • Waiting - Development team is waiting on more information to resolve the issue
  • Review - the case is in QA for review

Return to Contents

Process Flow

The diagram below shows the way points for customer notifications:

The customer messaging triggers when the case is open in the development queue are as follows (see section below for closed status information):

  • Account = Is not blank
  • Case Status = Transferred
  • Case Owner = Development
  • Category = Possible Issue
  • Work Item/Issue Number = is not blank
  • Work Item/Issue Status is changed to one of the following 
    • Active 
    • Resolved

Return to Contents

Reject a Possible Issue

If Development determines the case submitted as a Possible Issue is not a product issue, the following fields on the Salesforce case will need to be updated by Development prior to closing the Dev Ops case and transferring the Salesforce case to the appropriate department for next steps:

  1. Category: Change from Possible Issue to another category type from the available options  
  2. Case Activity: Post an update with the reason the case is being removed from a Possible Issue category to another
  3. Transfer the case to the new department owner
  4. The Dev Ops case can now be closed

Return to Contents

Salesforce Case Closing

When the Dev Ops case reaches a closed status and has been assigned a release number, the Salesforce cases with the Dev Ops number linked will automatically be closed and the customer notified that the fix will be available in the release listed in the Released In field.  

The following fields on the cases will also be updated automatically:

  • Case Status = Closed
  • Resolution = Solved (Permanently)
  • Resolution Details = Solved in (Release Info field data inserted)
  • Cause code = Defect
  • Sub Cause Code
    • Original issue report case (Parent case field is null) = New Defect
    • Subsequent reports (Parent case field is not null) = Existing Defect
  • Product = Product entered
  • Sub Product = Sub Product entered
  • Billable/Non-Billable = Non Billable
  • Request Type = Software Issue
  • Request Category = Problem or Issue

The automation will look for the following fields to trigger the customer notice:

  • Case Owner = Development
  • Case Status = Closed
  • Category = Product Issue
  • Work Item/Issue Number = is not blank
  • Work Item/Issue Status = Closed
  • Released In = Not blank
     

Return to Contents

Was this article helpful?
Thank you for your feedback!
User Icon

Thank you! Your comment has been submitted for approval.