Creating a Customer support portal

[Ryan Chown]

I am attempting to create a Customer support portal that allows people to fill in / select issues and submit details. 

Based on the forms submitted, I would like to 

Assign tasks to a user group in a round robin
Trigger specific email replies based on submitted content from the customer
Set the priority of tasks 
Allow customer/submitter replies to reopen the issue 
Trigger emails to an overseer when an issue is unresolved for more than 48h

Generally looking for advice, as i got what i feel was 50% there then hit this fundamental issue 
"If you are talking about the JSM FORM field then Unfortunately, one cannot pull information directly from FORM's element in the CLOUD env at this time unless the field is mapped to Jira/JSM issue's field.  Therefore, you cannot use automation configuration without linking the form field to jira/JSM field."

I feel like this is the most basic way to set up, and yet i cant replicate what fresh desk did in 20 min

[Peter_DevSamurai]

Hi @Ryan Chown ,

Since you're a Premium plan, those above requirements can be achieved.

Regarding the form mapping issues, JSM forms must link fields to Jira issue fields (e.g., custom fields) for automation to access the data. Unmapped form elements are "display-only" and can't trigger rules. Once mapped, everything should work out. Bear with me with this set up:

1. Create the Portal & Form

• Project settings > Portal settings > Customize portal > Add request types (e.g., "Report Issue").
• For forms: Project settings > Forms > Create form > Add fields (e.g., dropdown for issue type, text for details).
• Map each field: In form builder, link to Jira fields (ex: custom select list for "Issue Category", summary/description for details). This makes data available for automation. :)
• Customers submit via portal (no login needed if public, or email-to-Jira).
  
  

2. Round-Robin Assignment

• Use automation: Project settings > Automation > Create rule.
  • Trigger: Issue created.
  • Action: Assign issue > Round robin > Select user group (ex: "Support Team").
    
    

3. Trigger Specific Email Replies

• Automation rule:
  • Trigger: Issue created or Comment added.
  • Condition: If/else on mapped field (ex: if Category = "Billing", then...).
  • Action: Send email > Custom template (use {{issue.summary}} for personalization).
• For consistency, use email templates in Project settings > Email.
  
  

4. Set Priority

• Automation:
  • Trigger: Issue created.
  • Condition: Based on form data (e.g., if Urgency = "High", set Priority = Major).
  • Action: Edit issue > Priority field.
    
    

5. Reopen on Customer Reply

• Built-in: Project settings > Workflow > Edit "Resolved" status > Add post-function or automation.
  • Automation rule: Trigger: Comment added > Condition: Comment from customer > Action: Transition issue to "In Progress".
    
    

6. Escalate Unresolved >48h

• Automation:
  • Trigger: Scheduled (daily).
  • JQL: status != Done AND updated < -48h
  • Action: Send email to overseer (ex: manager group) with details.

You can refer to the below links:

• JSM Portal Setup
• Forms Mapping
• Automation Examples

Hope everything works out for you!

Best,

Peter

[Olha Yevdokymova_SaaSJet]

Hello @Ryan Chown 

What you quoted is unfortunately accurate: with native JSM Forms, Jira Automation can only react to form answers if those answers are mapped to Jira fields. Anything that stays “inside the form” is invisible to automation. That’s why basic things like routing, priority, or email branching start to require a lot of extra custom fields.

What works natively 

If you stay fully native, the usual pattern is:

• Decide which form answers actually drive workflow (request type, urgency, category)

• Create Jira fields for those

• Map the form questions to those fields

• Let automation handle round-robin assignment, emails, SLAs, and escalations

It works — but as forms grow, this often turns into a lot of field management just to keep automation running.

Another approach teams often use

One alternative some teams take is using Smart Forms for Jira (developed by my team) as the intake layer, and then letting Jira focus on execution.

A few practical differences that matter in your case:

• Request type selection can live inside the form
  Instead of forcing users through multiple portal request types, the form itself can ask “What are you contacting us about?” and create work item with selected work item type. Just pre-fill this field with the values of request types from Jira

• Form fields don’t all need to be mapped
  You choose what gets written into Jira fields and what stays as form data.
  This means:

  • You don’t need to create new Jira fields for every question

  • Only operational fields (priority, category, routing) are mapped

  • Everything else can stay in the form response

• Flexible field mapping
  Form answers can be mapped to:

  • Any existing Jira fields (no new fields required)

  • Or even all written into the issue description if you want a single, readable summary

• Automation still works cleanly
  Because the important decisions (priority, request type, team) are mapped, Jira Automation can:

  • Assign in round robin

  • Send different email replies

  • Trigger escalations after 48h

  • Reopen issues on customer replies (native JSM behavior)

• More flexible intake channels
  Forms can be:

  • Shared externally via a link

  • Embedded on a Confluence page

  • Embedded on an external website
    So you’re not limited to the Help Center if that’s part of what’s blocking you.