nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Portal-only duplicate issues

kyzh72

Hi,

We have a customer portal where external users can create tickets. When creating a ticket, they select a location (train station) and an associated equipment from a custom field.

Often, multiple tickets need to be created for different equipments at the same location. Currently, this is done manually, which is time-consuming.

We are looking for a way to simplify this process—for example, by creating one ticket and then duplicating it while only changing the equipment field, or by importing tickets from a CSV/Excel file.

We came across the "Elements Copy & Sync" app, which might help, but it doesn't appear to be accessible from the customer portal.

Has anyone faced a similar situation and found an effective solution? Screenshot 2026-06-10 142436.png

Accepted answers

Ron Votazz

Hi @kyzh72 ,

There's no native way for portal customers to duplicate a request or import
from CSV — the portal is strictly one-form-one-request, and apps like Elements
Copy & Sync operate on the agent side, which is why you can't see it on the
portal.

That said, there's a well-established pattern that solves exactly your
scenario:

Option A — one request with multiple equipments + Automation split
(recommended).
Instead of forcing the customer to create N tickets, let them create one:

1. Add a multi-select custom field (e.g., "Equipments concerned") to the
request form, so the customer picks the location once and selects all affected
equipment in one go.
2. Create an Automation rule: trigger Work item created (with a condition on
the request type) → Advanced branching over the values of the multi-select
field → inside the branch, Create work item copying the
summary/description/location/priority from the trigger and setting the
equipment field to the branch value.
3. The original request can serve as the first ticket or be auto-closed as an
"umbrella", whichever fits your process.

The customer fills the form once; Jira creates one ticket per equipment, each
individually trackable.

Two caveats:
- Your screenshot shows a dependent location → equipment selection. A standard
multi-select can't be filtered by the chosen station natively, so either keep
one multi-select with the location code in the option names (as you already
have), or keep the cascading setup and accept an unfiltered equipment list.
- You're on the Free plan, which includes 500 automation rule runs per month.
The good news: a rule execution counts as one run regardless of how many
tickets it creates, so one customer request splitting into 5 tickets still
consumes a single run (how usage is calculated). 500 submissions/month should
be plenty for most portals.

Option B — agent/admin side bulk creation.
If the bulk cases are predictable (e.g., maintenance rounds), your team can
create the tickets for the customer:
- An agent clones the first ticket and changes the equipment field (native
clone, a few clicks per ticket), or
- An admin imports a CSV via External System Import, with the Reporter set to
the customer's email. One catch: for the tickets to appear correctly on the
portal, the Request Type must be mapped using the portalkey/requesttype format
— Atlassian has a KB on this: https://support.atlassian.com/jira/kb/set-the-r equest-type-for-jsm-issues-when-importing-from-csv/

Option A is usually the better experience since it keeps the workflow fully in
the customer's hands.

All comments

Ron Votazz

Hi @kyzh72 ,

That said, there's a well-established pattern that solves exactly your
scenario:

Option A — one request with multiple equipments + Automation split
(recommended).
Instead of forcing the customer to create N tickets, let them create one:

The customer fills the form once; Jira creates one ticket per equipment, each
individually trackable.

Option A is usually the better experience since it keeps the workflow fully in
the customer's hands.

Mikael Sandberg

Hi @kyzh72,

Welcome to Atlassian Community!

One way to do this is to use automation to create the tickets for each equipment selected. We do something similar for Apps, the Apps field is multi-select and then we are using two automations, the first one iterates on the values selected and for each one it calls another automation that creates the ticket. You can probably now do it in a single automation by using the advanced branching.

kyzh72

Thank you for the prompt and helpful response! I’ll try option A.

Evelin Bayer - codefortynine

Hi @kyzh72 ,

I hope you've made good progress with the implementation based on @Ron Votazz's suggestions!

In case you're still looking for input or exploring alternatives, here's an additional angle from our side - disclosure: I work at codefortynine, the vendor of Deep Clone for Jira.

@Ron Votazz's Option A (multi-select field + Automation branching) is a solid approach. One thing worth noting though: the "Create work item" action inside the branch requires you to manually map every field you want to copy - summary, description, location, priority, and so on. That works fine for simple tickets, but it can become error-prone as your ticket structure grows. And most importantly: it does not automatically create an issue link between the new tickets and the original request - so your equipment tickets end up without a built-in connection to the "umbrella" ticket that triggered them.

If you want that traceability, or if your tickets are more complex (attachments with embedded images, comments, many custom fields), our Deep Clone for Jira app can slot directly into the same automation flow as a drop-in replacement for the "Create work item" step. It offers a fully integrated Jira Automation action ("Deep Clone - Single Clone") that:

Copies all configured fields cleanly based on a reusable Preset - no manual field mapping needed
Automatically creates an issue link ("CLONES" or custom issue link type as needed) between each clone and the original ticket for full traceability
Carries over attachments (including embedded images), comments, and other data that "Create work item" can't handle

The overall flow would look like this:

Customer submits the portal form (with the multi-select equipment field, as Ron suggests)
Automation triggers and branches over the selected equipment values
Per branch: Deep Clone action clones the original ticket
Per branch: Edit work item sets the equipment field on the clone to {{branch.value}}

Deep Clone does the heavy lifting (copying everything correctly and linking back to the original), and a single edit step afterwards sets the one field that differs per clone.

For more details see our Jira Automation documentation as well as the configuration options for the clone action preset.

Best, 

Evelin Bayer | codefortynine

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management