The Support and Build apps on the DevRev platform enable rev users to coordinate with the dev org and different parts of the dev org to coordinate with each other.

    Conversation → Ticket → Issue → Task

    In this flow, context is preserved. Between every integration hop and side conversation, important details that help define the ‘why’ behind work is lost. That context defines the problem and requirements for anyone that works on this issue.

    Both tickets and issues are always associated with rev parts.


    Conversations refer to the communication chains you have with your rev users. They begin in the DevRev PLuG widget, which enables live chat within customers' apps with just a few lines of code. Unlike most platforms, customer conversations are no longer siloed to just front-office support, sales, and customer success staff. Instead, they are accessible to everyone in the dev org through the PLuG inbox.

    You can add a title to your conversations as well as members from your own dev org and other members from the user's rev org without starting a new thread or email chain. Because there can be many tickets attached to a single conversation, there is no need to start a new thread for new topics either.

    We recommend closing the conversation whenever you feel the interaction has reached a natural end. Closing the conversation will not close the tickets and your rev users will still be able to see them in the widget.


    A conversation is typically started by rev user. It may be a short interaction, such as a quick question about a sale, that does not require a ticket. However, it could contain one or more items that you would want to capture in a ticket. A ticket is used to capture anything that you may need to follow up on from a conversation, which could be bugs, feature requests, or anything in between. A ticket is associated with a part of the product and can come from either an internal or an external user.

    For example, if a rev user wrote in and reported a crashing behavior, asked for an enhancement to an existing feature, and asked for entirely new functionality, you would likely create three tickets all linked to the same conversation. This means you do not need to ask your rev users to write in separately about each topic they'd like to discuss, while the dev org can still track each item separately.

    In the DevRev app, a support engineer can create a ticket based on a conversation they had with someone using the PLuG widget. This ticket and conversation are linked.

    A ticket should describe what the rev user is experiencing in language that is familiar to them. Developer-specific language will be reflected in issues.


    Later on, a software engineer may start work on this ticket by creating an issue and breaking that issue into smaller pieces with tasks. An issue describes what the developer will work on and is created or accepted by someone who owns or works on the associated part of the product. This distinction allows developers to break up a ticket from a rev user into issues as they see fit and delegate the work to other team members as necessary.

    Tickets and issues are linked in many-to-many relationships. It may require multiple issues to resolve a ticket, or one issue may resolve multiple tickets if different rev users experience and describe the same behavior in different ways.


    DevRev has a capability called PLuG that enables companies to embed a conversations widget within their applications. Once PLuG has been enabled, all customer conversations can be tracked within DevRev and any Conversations can be immediately linked to a ticket, a ticket to an issue and subsequently to a part (product capabilities and features).

    Work state relationships#

    The following figure shows how the stages between various work object types relate:

    Work state relationships

    Deflection and deduplication#

    DevRev proactively gets ahead of duplicate work during the work creation process using work deflection. As you're creating a new work item, the Similar Work modal appears and presents potential duplicates. You can also use this modal to link the work you're creating to other work, if appropriate.

    In traditional systems of record, duplicate work is rampant, and maintenance of the backlog can be an entire job itself. Huge engineering backlogs can have detrimental effects on developers, morale, and velocity. One way DevRev gets ahead of that is with work deflection.