Capture Slack feature requests without filling Linear with noise

Keep the customer’s words and make review manageable

A feature request often starts as a Slack reply, gets repeated in a call, and disappears into a weekly spreadsheet cleanup. Product managers need a way to collect the request and its context without turning every mention into an issue for engineering.

A teammate marks a top-level Slack message with a chosen reaction. Automate.ax reads that thread, uses built-in AI to decide whether it is a feature request, and saves candidates in Airtable with the source link. When an Airtable row's status becomes Approved, the automation creates a Linear issue and posts its link in the original Slack thread.

A commenter was copying requests from Slack into a spreadsheet each week, while direct Linear creation produced a noisy backlog.Source: a SaaS team’s discussion of feature request tracking

What you'll tell the agent

• The Slack reaction that means “save this for review” and the one channel to watch.
• The Airtable base and table where product feedback should be reviewed, or permission for the agent to create them.
• The Linear team for requests a reviewer approves.
• The people who may mark Airtable rows Approved.
• Account authorization for Slack, Airtable, and Linear.

The agent will create the project and ask you for these details. When Automate.ax asks you to connect an account, authorize the integrations you want this workflow to use.

Automate.ax AI reads up to 15 messages from the marked thread, capped at 6,000 characters. Use a channel where that processing is appropriate, and keep sensitive conversations outside it.

The automation

The reaction is an intentional capture signal. AI filters out obvious non-requests, but the Airtable row still needs a person’s review. Changing its status to Approved creates the Linear issue and replies in the original thread.

import { automation, generate, t } from "automate.ax"
import { airtable } from "automate.ax/airtable"
import { linear } from "automate.ax/linear"
import { slack } from "automate.ax/slack"
import { z } from "zod"

export default automation(
  "Review Slack feature requests",
  {
    parameters: [
      { label: "Feature request channel ID", name: "channelId", type: "text" },
      { label: "Capture emoji name", name: "captureEmoji", type: "text" },
      { label: "Airtable base ID", name: "baseId", type: "text" },
      { label: "Review table ID", name: "reviewTableId", type: "text" },
      { label: "Status field ID", name: "statusFieldId", type: "text" },
      { label: "Linear team ID", name: "linearTeamId", type: "text" },
    ],
  },
  ({ parameters }) => {
    const marked = slack
      .onReactionAdded()
      .transform(({ reaction, item }) => ({
        reaction,
        conversationId: item.type === "message" ? item.conversationId : "",

What a run looks like

Set it up

1. Copy the setup prompt at the top into your coding agent.
2. Tell the agent the emoji, channel, Airtable table, and Linear team. It will map the fields and save those choices in the project.
3. Authorize Slack, Airtable, and Linear when prompted. Add the Slack app to the chosen channel.

Check the result

Post a made-up top-level feature request in a test channel, add the capture reaction, and inspect the Airtable row and source link. Change that row to Approved. Check the new Linear issue and link in the Slack thread.

Where this workflow stops

• A reaction records a candidate, not a validated feature request; reviewers still decide whether it belongs on the roadmap.
• The Slack app needs access to the channel and message. Private conversations are not available by default.
• React to a top-level message. The code does not resolve a reply’s parent thread, and reads only the first 15 messages.
• AI filtering may miss a request or include a false positive. Repeated reactions also need a duplicate policy before a larger rollout.

Common questions