Requests

Overview

Requests allow you to submit bug reports, feature requests, or other needs to teams. You can link requests to Key Results to indicate that a team needs to work on specific outcomes. Teams can accept or reject requests, convert accepted ones into issues or projects in their team, and mark the work done when it is finished.

Create a request

Click the "New Request" button on the Requests page. Fill in the request title (required), description, type, and select the target team. Optionally, link the request to one or more Key Results to indicate which outcomes this request supports.

Request Types

Requests can be categorized as:

• Bug: Report a problem or issue that needs to be fixed
• Feature: Request a new feature or enhancement
• Other: Any other type of request

Key Results

You can link requests to Key Results to indicate that completing this request will help achieve specific outcomes. This helps teams understand the strategic importance of the request and prioritize accordingly.

Request Status

Every request starts in Triage, whatever its type. Triage and Pending track whose turn it is; the remaining four record an outcome.

• Triage: The target team owes a response. Every new request starts here.
• Pending: The requester owes a response. Pulse moves a request from Triage to Pending when someone on the target team comments, and back to Triage when the requester replies. A team manager can also switch between the two directly.
• Accepted: A team manager approved the request for their team, optionally with an expected completion date.
• Rejected: A team manager declined the request.
• Done: A team manager marked accepted work as finished.
• Duplicate: The request repeats one that already exists, and is tracked on that one instead.

Accept and Reject are offered only while a request sits in Triage or Pending, so a request that already carries an outcome is never reviewed twice. Done follows Accepted and nothing else. Duplicate is the one reversible status: Pulse remembers the status the request held before, and removing the duplicate link restores it.

Request templates

A team can shape what a request looks like before it arrives. A request template pre-fills the type, priority, labels, and linked Key Results, or asks the requester ordered questions first. A team can also name the template its request form opens with, and require that every request start from one.

See Request templates.

Team Workflow

Team managers can:

• Accept requests: Approve the request for their team to work on, optionally setting an expected completion date
• Reject requests: Decline the request with an optional reason
• Mark done requests: Close out an accepted request once the work is finished

After accepting a request, teams can convert it to an Issue or Project within their team and link it to track progress.

Marking a request as a duplicate is not limited to managers. The requester, a manager of the target team, or a workspace admin can point a request at the one that already covers it, and remove that link later. The request it points to cannot itself be a duplicate, so duplicate chains stay one level deep.