How to Push Feature Requests to Jira Automatically

You push feature requests to Jira automatically by setting up push rules in the FeatureOS Jira integration. A rule watches for a status change on a post, filtered by board, tags and who made the change, and creates the issue in the Jira project and issue type you pick. Add as many rules as you need, each pointing at a different project.

TL;DR: Connect Jira under Dashboard > Organization Settings > Integrations > Jira, then add automatic push rules: trigger status, board, tags, who made the change, target Jira project and issue type. Turn on comment push so FeatureOS comments reach the linked Jira issue, map post fields to Jira custom fields, and use the two sync toggles to decide whether Jira sends title and description changes back.

Most teams I talk to have the same gap. Customers post requests on a feedback board. A PM reads them, decides one is ready, then opens Jira in another tab and retypes the whole thing. Sometimes they forget. Sometimes the ticket lands in the wrong project. The request and the work drift apart from day one.

The Jira integration was rebuilt in August 2026 to close that gap. This post covers the automatic side of it: rules that push posts for you, comments that follow the post into Jira, and fields that stay mapped.

If you want customers to vote on issues that already live in Jira, that is a different job. Read how to set up customer feature voting in Jira instead.

What does "push to Jira automatically" mean in FeatureOS?

It means you stop clicking Create in Jira on every post. You describe the conditions once, and FeatureOS creates the Jira issue when a post meets them.

Each rule has these parts:

• The status that triggers it. For example, the moment a post moves to Planned.
• The board. Only posts on that board count.
• The tags. Only posts with those tags count.
• Who made the change. Limit the rule to changes made by specific people.
• The Jira project and issue type. Where the new issue lands.

You can add as many rules as you need. Each one can point at a different Jira project. So a Mobile board can feed the mobile project, and an API-tagged post can go to the platform team.

Manual push still works. Rules handle the routine cases. You still create or link issues by hand when a post does not fit any rule.

How do I set up automatic push rules?

1. Connect Jira. In FeatureOS, go to Dashboard > Organization Settings > Integrations > Jira > Connect. Install FeatureOS for Jira from the Atlassian Marketplace and finish the setup. The Jira integration page walks through the install in detail.
2. Open the Jira integration settings in FeatureOS.
3. Add an automatic push rule. Pick the status that triggers it, the board, the tags and who made the change.
4. Choose the destination. Pick the Jira project and issue type the new issue should land in.
5. Add more rules if you need them. One rule per routing decision is the easiest setup to reason about. Point each at the right project.
6. Turn on comment push if you want comments on a FeatureOS post to go to the linked Jira issue.
7. Map custom fields. Map FeatureOS post fields to your Jira project's custom fields. The Jira issue updates whenever the post changes.
8. Set the title and description sync toggles. These two toggles decide what Jira sends back to the linked FeatureOS post.
9. Test it. Move a test post into the trigger status on the right board, with the right tags, and check that the issue shows up in Jira.

Source: Jira Integration : Revamped, shipped 2026-08-14. The full setup guide lives in the FeatureOS help center.

How does comment push work?

Comments on a FeatureOS post can go straight to the linked Jira issue. That is the whole feature, and it runs one way: FeatureOS to Jira.

Why it matters: the useful part of a feature request is rarely the title. It is the third comment where a customer explains the workflow they are stuck in. With comment push on, that context shows up where the engineer is working, not in a tab they never open.

Do not expect Jira comments to flow back into FeatureOS. Engineers who want to reply to customers should do it on the FeatureOS post.

What do the title and description sync toggles do?

There are two toggles. One controls whether Jira sends title changes back to the linked post. The other controls description changes.

Before the revamp, turning description sync off meant asking support. Now it is a setting you control.

How to choose:

• Leave description sync on if your Jira descriptions are written for humans and you want the public post to reflect the latest spec.
• Turn description sync off if engineers rewrite Jira descriptions into acceptance criteria and technical notes. You probably do not want that showing up on a customer-facing post.
• Title sync follows the same logic. If engineering renames tickets to internal shorthand, keep the customer's wording on the post by turning it off.

How does custom field mapping help?

Jira projects often have required or reporting fields: customer tier, product area, priority bucket. Without mapping, someone fills those in by hand after every push.

With custom field mapping, you map FeatureOS post fields to your Jira project's custom fields. When the post changes, the Jira issue updates. The data you already collect on the post travels with it.

Example (hypothetical): one board, two engineering teams

A SaaS company runs one public Product board. Requests tagged mobile belong to the mobile team's Jira project. Requests tagged api belong to the platform team.

They set up two rules:

• Status moves to Planned, board is Product, tag is mobile, change made by the head of product. Push to the Mobile project as a Story.
• Status moves to Planned, board is Product, tag is api, change made by the head of product. Push to the Platform project as a Story.

Now the head of product does triage on the board and nothing else. Moving a post to Planned is the handoff. Comment push is on, so when a customer adds detail a week later, the engineer sees it on the Jira issue.

Example (hypothetical): bugs and features from the same widget

A team collects feedback from an in-app widget into two boards: Bugs and Feature Requests. Bugs should become Jira Bugs in the core project as soon as support confirms them. Feature requests should become Stories only after the PM approves them.

They set up:

• Board is Bugs, status moves to Confirmed, change made by anyone on the support team. Push to Core as a Bug.
• Board is Feature Requests, status moves to Planned, change made by the PM. Push to Core as a Story.

They map a "Plan" post field to a Jira custom field so engineering can filter by customer plan. Description sync stays off, because engineers rewrite bug descriptions with repro steps that customers do not need to read.

When is this not enough?

Automatic push rules remove the retyping. They do not remove judgment. Be honest with yourself about these limits:

• Rules fire on the conditions you set, nothing more. If a post never reaches the trigger status, it never reaches Jira. Someone still has to triage.
• Comment push is one-way. Comments go from FeatureOS to Jira. Replies in Jira stay in Jira. Customer conversations belong on the post.
• Rules do not decide priority. They route. Votes, comments and revenue context are still yours to weigh. If one loud account keeps pushing the same idea, read up on vocal minority bias before you plan around it.
• Messy tags make messy routing. A rule filtered by tag is only as good as your tagging. If tags are inconsistent, fix that first, or route by board.
• Too many overlapping rules get hard to follow. Keep one rule per routing decision and review them when teams change.

How does this fit with the rest of FeatureOS?

Jira push is the handoff from feedback to engineering. The rest of the loop lives in FeatureOS: collecting requests, merging duplicates, prioritizing, then closing the loop with voters when the work ships. Our feature request software page covers that end to end.

If you already work in the terminal, you can also triage posts from Claude Code before your rules pick them up. See how to manage feedback via Claude Code.

Try it on your own board

FeatureOS plans are seat bundles: Starter at $60/month for 5 seats, Growth at $120 for 10, Business at $250 for 15, and $15 per extra seat. There is no free plan.

Start a 14-day free trial, connect Jira, and set up your first rule. If you need more time to test it with engineering, ask us and we can extend the trial to 30 days.