Tickets, Issues; When to Use Each

This post discusses when to use each work type in the DevRev platform. Commonly tickets and issues are distributed across systems; however, with DevRev these all exist in one platform. This post defines each as well as when each should be used.

Tickets, Issues; When to Use Each

As discussed in Busting silos, the WHY of DevRev, the DevRev platform converges the operations and knowledge of objects used to build, operate, support and grow products, companies, and people.

Traditional Systems

DevRev Overview

Given this converged nature, it’s important to understand when to use what types of work.

Types of Work

If you break down the types of objects used in build and support systems, you will commonly see the following object types:

  • Items to track engineering/backend work → Issues
  • Items to track customer requests/problems → Tickets

Given the converged nature of the DevRev platform, we have both Tickets, and Issues, so when do you use what? The answer is “it depends” on what your role is on the part you’re creating the work item on. In general, issues should be restricted to those individuals that either own or contribute to a part. Tickets should be used for all customer/consumer (internal or external) items.

The following figure shows a decision tree that will help you identify what work type you should be using (this is not global but part specific):

Work Type Selector

For example, if I work on part foo, I can create issues on it. However, if I am a consumer of part bar I would create tickets which would then be triaged and potentially escalated into an issue by that team.


Noise and context switching kill productivity

Historically, a huge pain point has been that any systems being used for engineering work are commonly abused by sales, marketing and support teams. For example, a sales rep may create an issue for a developer for a customer request. In the case of support, you’ll commonly see a ton of duplicate issues when only one was really necessary. This leads to a lot of noise for developers, and devalues the notion of an “issue”. By keeping a clear line between tickets and issues, we ensure the following:

  • issues hold value
  • reduces noise as only valid issues are created/tracked
  • unifies the triage process for escalations between tickets and issues


  • If you work on a part, you create issues
  • If you are a consumer/customer of a part, you create tickets