How to Let JSM Customers Submit Jira Product Discovery Feature Requests — Without JPD Access

[#1]

When a support conversation in Jira Service Management (JSM) turns into "I wish the system could do X," you are no longer handling an incident - you are holding valuable product feedback. Licensing thousands of JSM portal-only customers in Jira Product Discovery (JPD) isn't practical or cost-effective, but you can build a clean intake pipeline that lets customers submit structured JPD ideas directly without extra site licenses.

A practical architecture uses Smart Forms for Jira as the customer-facing intake layer while keeping JPD as the product team's central system of record:

JSM Customer Request → Smart Form Intake → Automated JPD Idea → JPD Published View

The Core Friction: JSM vs. JPD Audiences

JSM manages service conversations for lightweight portal-only users. JPD helps product teams collect, organize, compare, and prioritize ideas.

Converting hundreds of portal customers into broader site users introduces unnecessary licensing costs and access-management overhead. While native JSM support lets agents curate feedback as JPD insights, teams often want customers to self-serve: intentionally submit a request, provide the specific context Product needs, and track progress without cluttering support queues.

Phase 1: Decide When Customers Receive the Request Form

Not every support ticket should create a JPD idea. Deploy the feedback form using one of three targeted triggers:

• Option A: Auto-Attach to Specific Request Types: Associate the form with request types like Product Feedback or Feature Suggestion. When created, the form appears automatically on the JSM ticket.

• Option B: Manual Support Agent Handoff: Allow support agents to attach the form manually once investigation confirms an issue is an expected system limitation rather than a bug.

• Option C: Trigger via Jira Automation: Use Jira Automation to trigger form delivery when a ticket transitions status (e.g., to Feature Suggestion), auto-attaching the form and emailing a unique shareable link to the reporter.
  

The form can be added as external or internal depending on the needs.

Phase 2: Eliminate Friction with Context Pre-Filling

Asking customers to re-type details already logged in JSM creates unnecessary drop-off. Use Smart Forms' Attach Form with Values or URL parameter pre-filling (?product={{issue.components.name}}&ticket={{issue.key}}) to pass existing context automatically:

• Customer Email & Organization (Acme Corp)

• Affected Product Area (Analytics Platform)

• Originating Support Ticket Key (SUPPORT-2841)

When the customer opens the form, known information is already populated, leaving them to answer only what Jira doesn't know.

Phase 3 & 4: Step-by-Step Smart Form & Field Mapping Configuration

Support tickets collect incident details, whereas product management requires problem narratives, workarounds, and business impact.

Step-by-Step Builder Setup:

1. Open your form inside Smart Forms for Jira.

2. Navigate to the Settings tab and enable Create New Work Item.

3. Select your target Jira Product Discovery space/project and set the work item type to Idea.

4. Configure direct field mapping between form elements and JPD fields:

Form Field Element	Element Type	Mapped JPD Field	Purpose
Feature Title	Single-line Text	Summary	Clear, concise idea title
Problem to Solve	Multi-line Text	Description	Underlying business need
Current Workaround	Multi-line Text	Description / Custom Field	Existing pain (manual steps, spreadsheets)
Business Impact	Dropdown	Impact (Custom Field)	Priority scale (Nice-to-have vs Blocking)
Users Affected	Numeric Input	Custom Field	Reach across the submitter's team
Product Area	Pre-filled Dropdown	Product Area	Taxonomy pulled directly from JPD
Supporting Files	Attachment	Attachments	Screenshots, specs, or mockups

Pro Tip (Description Block Mapping): To avoid custom field sprawl, map multiple qualitative questions directly to JPD's Description field. Smart Forms formats each input into clean [Label]: [Response] text blocks automatically.

Phase 5: Deduplicate Ideas Using JPD Published Views

To stop customers from submitting duplicate requests, add a content block at the top of your form linking to a JPD Published View:

Before submitting: Someone may have already suggested this improvement. Search existing product ideas →

Handling the Voting Limitation

Because unauthenticated/portal users cannot currently cast +1 votes on public JPD boards, use conditional form logic to collect qualitative context instead:

• Did you find a similar idea on our roadmap? → Yes

• Show conditional fields: Paste Idea Link and Explain why this matters for your organization.

A +1 vote tells you someone wants a feature; structured feedback tells Product which strategic account cares, their use case, and their business impact.

Phase 6: Streamline Questions with Conditional Logic

Keep forms short and prevent survey fatigue by using conditional show/hide rules:

• If Request Type = "Integration": Show Target System, Data Flow Direction, and Sync Frequency.

• If Request Type = "Reporting": Show Consuming Audience, Key Metrics Needed, and Export Format.

Phase 7 & 8: Deploy a Dual Intake Channel Strategy

Maintain two complementary entry points to capture feedback across all customer touchpoints:

Intake Channel	Setup Mechanism	Primary Use Case
1. Contextual Ticket Form	Form attached to individual JSM work item (auto or manual)	Converting ongoing support conversations into structured JPD ideas with pre-filled metadata
2. Permanent Portal Link	Standalone general external share URL	Embedded in Confluence, Help Center, email signatures, or documentation for direct submissions.

Phase 9: Close the Loop & Real-World Example

When the customer submits the form, customize the post-submission confirmation message to direct them back to your public JPD board or the idea that was created:

"Thank you! Your feedback has been submitted directly to our Product team. Track active exploration, planned features, and releases on our public roadmap."

End-to-End Walkthrough

1. Customer submits a JSM ticket: "I need regional approval rules."

2. Support confirms no native configuration exists and transitions the ticket to Feature Suggestion.

3. Jira Automation attaches the Product Feature Request Smart Form, pre-filling Customer: Acme Corp, Product: Workflow, and Source: SUPPORT-2841.

4. Customer opens the form link, completes missing context, and submits.

5. Smart Forms automatically creates JPD-842: Configure approval flows based on region with mapped impact scores and ticket context.

6. As Product moves the idea from Exploring → Planned → Released, the customer tracks updates via the published view without ever needing a JPD license.

What This Solves

Support stops acting as manual human middleware - reading tickets, copying text, creating secondary issues, and tracking down updates. JSM manages the service relationship, Smart Forms standardizes intake, Jira Automation handles handoffs, and JPD retains clean data for prioritization.