How to reduce agent workload by letting customers edit their own tickets

[#1]

Imagine a customer submits a Jira Service Management request with the wrong pickup location or forgets to attach an important file. Once they hit “Submit,” they realize the mistake – but by default, they’re stuck. Jira Service Management (JSM) doesn’t let customers edit fields on a request after it’s been created. Only agents (licensed users) can modify issue fields, while customers can only add comments or attachments. This limitation often leads to frustration on both sides: customers can’t fix their own errors, and agents have to jump in to make the corrections for them. 

In this article, we’ll explore why this happens, the workarounds admins and agents use today, and how you can enable safe post-submission editing – either with Jira’s native Forms or with the help of marketplace apps – to save everyone time.

Why can’t customers edit their own tickets?

By design, JSM’s customer portal keeps things simple and secure. Once a request is created, the summary, description, and other fields become read-only for the customer. Atlassian set it up this way so that unlicensed users (your customers, employees, etc.) can’t change critical data on the issue – they only have permission to comment or add more attachments if needed. While this makes sense for data integrity, it introduces a pain point: simple mistakes or updates require an agent’s intervention. For example, if a customer picked the wrong item from a dropdown or provided an outdated phone number, they have no direct way to correct it. The agent ends up doing extra work to adjust these fields manually.

Over the years, admins have raised this as a feature request, but until a native solution arrives, support teams have developed a few common workarounds to deal with this:

• Customer comments: The customer posts a comment with the correct information or attaches the missing file. The agent then reads the comment and manually updates the issue’s fields (or just relies on the comment itself). This works, but it scatters information – some details end up in comments rather than in structured fields, and the agent must remember to update the field or note the comment for future reference.
  
  
• Agent edits: The agent edits the ticket on the customer’s behalf. For instance, the support rep might edit the “Pickup location” field to the correct one or add the attachment to the issue. This ensures the field data is clean, but it’s extra overhead for the agent.
  
  
• Reopening or duplicating: In cases where the mistake is caught late (e.g., the ticket is already resolved or in progress), an agent might need to transition the issue back to an editable state or ask the customer to create a new request with the correct information. Reopening closed tickets or handling duplicate tickets can mess with your workflow and metrics (think SLA timers or reports), and it’s not a great experience for the customer either.
  
  

These workarounds get the job done, but they’re not ideal. They create extra back-and-forth and potential confusion, and they certainly don’t scale well if your service desk gets a lot of “oops, I meant X, not Y” kind of updates. 

Thankfully, you’re not stuck with this status quo. JSM admins can enable customers to safely edit request fields after submission – either via Jira Service Management Forms (a native feature) or through third-party apps. Let’s look at both approaches.

Using Jira Forms as a safe editing workaround

Atlassian’s recommended workaround for this issue is to use Jira Service Management Forms. They can be configured to allow post-submission edits on linked fields. Here’s how it works in practice:

• Set up a Form with linked fields: As a JSM admin, you can create a form under your project’s Project settings > Forms, add the fields you want (text fields, dropdowns, etc.), and link each form field to an actual Jira field in the issue. You then attach this form to the relevant request type. For example, you might have a form section for “Pickup location details” linked to a custom field, or a form for “Additional details” that allows the customer to upload attachments or provide more info.
  
  
• Customer fills out the form upon creation: When the customer submits the request, they fill out the form fields as part of the ticket. Upon submission, those linked Jira fields on the issue are populated with the form data. At this point, the form is in a submitted state on the portal – the customer can view their entries but can’t change them yet (by default).
  
  
• Allowing edits – two approaches: If a correction is needed, you have two ways to enable it:
  
  
  1. Agent reopens the Form on request: An agent can manually reopen the submitted form from the issue view. For instance, if the support agent notices a mistake (or the customer asks for a change), the agent opens the issue, finds the form, and clicks “Open customer edits” (reopening the form). The form is now OPEN for editing, which means the customer can return to the portal and update the fields they previously submitted. The customer updates the “Pickup location” or attaches the missing file in the form, then hits save/submit again. Jira will update the linked issue fields accordingly with the new information.
  2. An agent can add a new form to the existing request: an agent can also, without reopening the form, create a new one (or use an existing form) and ask the customer to fill it out. That’s especially useful when the user needs to provide additional information rather than fix mistakes.
     
     
  3. Keep the Form open for self-service: If you prefer a more hands-off approach, you can configure the form to remain open for edits even after submission. In the form settings, there’s an option to “Keep this form open for edits.” If enabled, the form does not lock upon submission. The customer can come back to their request at any time (while it’s still active) and update the form fields directly, without needing an agent to intervene. As soon as they save the form, the linked fields on the issue update to reflect the changes. This is great for cases where you expect iterative information – for example, an onboarding request where the customer might initially fill in some info and add more details over time.
     
     

Both of these form-based methods ensure that data lands in the right structured fields and that the agent is kept in the loop (Jira will show field updates in the issue history, and you can set up notifications or simply monitor changes). The downside is that you need to plan ahead, which fields are on the form. If you have an existing request type with specific fields, you might need to reconfigure those into a JSM Form to take advantage of this editing capability.

Letting customers edit fields via Marketplace apps

What if setting up Forms isn’t feasible, or you want an even smoother experience for the customer (and your agents)? This is where third-party apps from the Atlassian Marketplace come into play. Several vendors have created solutions to lift the “no-edit” restriction on the customer portal in a controlled, admin-friendly way. These apps essentially add an “Edit request” capability on the portal side, so customers (or other permitted users, such as participants) can adjust fields without bothering the support team. Importantly, these apps are designed to be safe and configurable, so you remain in control of what can be edited and when.

Typical features you’ll find in these apps include:

• Choose which fields are editable: As an admin, you decide which fields a customer can change after submission. For example, you might permit editing of a “Location” custom field or a “Description” field, but not allow changes to something like the Issue Priority unless you’re okay with customers potentially escalating their own tickets. Most apps support standard text fields, number fields, select lists, etc. You probably want to stick to fields that won’t break your process when they change. Good candidates include addresses, contact info, descriptions/details, or attachments. It’s wise not to let customers change fields that directly determine workflow or SLA (such as Status or Request type), and to be cautious with Priority or Approver fields unless it’s intentional. The key is to open only what makes sense.
  
  
• Control who can edit: These solutions often let you specify which portal users can make edits. Usually, the default is that the reporter can edit it. Some apps let you extend this to other customers involved – for instance, participants or members of the organization that the ticket is shared with. This is useful if your requests are shared and you’re okay with any stakeholder updating the info. If not, you can restrict it so that only the original reporter can change the fields. Having this control prevents just anyone from coming in and altering requests in ways they shouldn’t.
• Decide when editing is possible: Editing isn’t always allowed, and that’s intentional. These apps let you decide when customers or approvers can make changes, based on the request’s state and your process needs. In some cases, editing can be available directly on the customer portal, independent of workflow transitions. For example, allowing users to correct details or add missing information while a request is open. In other cases, editing is tightly controlled as part of the workflow. You might allow changes only in specific statuses, or require users to provide certain fields or a justification when performing actions such as Decline, Escalate, or Reopen. For example, you can block all edits once a ticket is Closed to protect SLAs and reporting, while still offering a dedicated “Reopen with reason” action if reopening is part of your process. The key point: editing is never “always on.” Whether it’s status-based or workflow-driven, you define exactly when edits are possible without giving customers unrestricted access.
  
  
• Project- and request-type scoping: You might want this edit feature only in certain service projects or for certain request types. Marketplace apps typically allow you to enable editing on a per-project basis, and sometimes even per request type or per a specific “action” you configure. For example, you could enable “editable requests” on your IT Helpdesk project but keep it off for, say, an HR requests project if edits there would violate policy. This scoping ensures the feature is used where it makes sense and doesn’t accidentally open up things elsewhere.
  
  
• Change tracking: A major concern when letting customers change fields is making sure the support team knows about it. The good news is that these apps usually have built-in tracking. When a customer edits a field through the portal, the app will update the issue and often log an internal comment noting the change. For instance, if Jane Doe updates the “Pickup location” from “Main office” to “Branch office” via the portal, the app might add an internal note like “Customer updated Pickup Location from Main Office to Branch Office” to the issue. This way, nothing slips through silently – agents can quickly see what changed and when.
  
  
• Permissions and safety nets: Under the hood, JSM’s permission model is still respected. These apps don’t literally give the customer full Edit issue rights; instead, they act as a bridge – the app applies the customer’s input to the issue. Some apps will even let you enforce required fields on Jira transitions (a common pain point is not being able to enforce describing a reason when someone declines a request).
  
  

In the Atlassian Marketplace, you can find a few options to evaluate. For example, Modify My Request adds a super simple “Edit” button on the request page in the help center. Another tool, Actions for Jira Service Management, offers “Request actions” that admins configure – essentially custom actions like “Update details” or “Edit location” which expose specific fields to the customer for editing.

Admins decide which fields can be editable and by whom. Source: Actions for Jira Service Management

Apps like these are built to be highly configurable and non-intrusive: they won’t affect your instance beyond what you set up. If you try one, you can usually start with a free trial to see how it works in your environment. Click here to try out the Actions for JSM app by Deviniti.

Practical tips for enabling post-submission edits

Whether you go with Jira Forms or a third-party app, here are a few tips to keep the experience smooth and safe:

• Start small – Open up only safe fields: Initially, enable editing for a couple of fields that commonly need corrections. Good choices are non-critical fields like “Details/Description,” location/address info, or other text fields. Observe how often customers use it and whether it actually reduces the back-and-forth. You can always expand later. Avoid giving access to fields that could be abused or cause process issues (e.g., Priority, unless you have a policy around it, or any field that would change the request’s workflow path).
  
  
• Communicate the option to customers: If customers don’t know they can edit their request, they won’t use the feature. Consider adding a note in your request submission confirmation or an FAQ on your portal, like, “Need to update something on your request? You can edit certain details on the request page.” If you’re using Forms, the interface might not scream “you can edit me” until it’s reopened or kept open, so a short instruction can help. For apps that add an Edit button, it’s usually more obvious – but you might still highlight it by saying, “You can now edit your request details without contacting support.”
  
  
• Review your workflow & automation impacts: Before rolling out editable fields, double-check if any of your JSM workflows, automation rules, or SLA calculations rely on fields being a specific value from the start. If a customer can change those fields, will it trigger an unintended status change or a duplicate notification? For example, if changing a custom field normally would fire an automation, that same automation will fire when a customer does it via forms or an app. Usually, this is fine (it’s the same as an agent doing it), but do a dry run. If using an app that adds comments on changes, ensure you don’t have an automation like “when a comment is added by an agent, reopen ticket” – because the app’s internal comment might meet that criteria and accidentally reopen cases. Adjust your rules or the app settings accordingly (some apps let you customize whether to add comments or just silently update).
  
  
• Keep security in mind: Remember that even though you’re empowering customers to edit, they still can only see what they’re allowed to see on the portal. Standard JSM security applies – customers can’t suddenly view other fields or tickets. When choosing a marketplace app, make sure it’s from a reputable vendor (check the reviews and the Cloud Fortified badge, for instance) and that it respects JSM permissions. The goal is to make life easier, without opening any loopholes.

Conclusion: fewer mistakes, less manual work

It’s frustrating for everyone when a ticket has the wrong info – customers feel helpless, and agents spend time trying to get things right. As a JSM admin, you have the power to reduce this friction. 

By leveraging Jira Service Management’s Forms or a well-chosen third-party app, you can allow your customers to safely edit their requests after submission, within boundaries you set. This not only improves the customer experience (they feel more in control and get faster resolutions for corrections) but also frees your agents from mundane tasks like correcting typos or re-collecting missing data.

Many JSM admins aren’t aware that these options exist, especially since out-of-the-box JSM doesn’t advertise them. But the community and Atlassian have recognized the need – Atlassian’s own knowledge base outlines the Forms workaround, and vendors have stepped up with user-friendly apps to fill the gap. 

If you’ve been dealing with a lot of “Can you change this for me?” requests, it might be time to give one of these solutions a try. Start with a small pilot (maybe one project or one field) and see the impact. You’ll likely find that tickets move along more smoothly with fewer back-and-forth comments, and your team can focus on solving issues rather than doing data entry clean-up.

If you want to set up a trial run of this, I invite you to try out our app Actions for JSM. It lets you enable customers to edit selected fields after submission (you decide which ones), collect missing information later via edits or drafts instead of overloading the intake form, and avoid fragile workarounds with JSM Forms and automation. Actions works across project types, supports 30+ custom fields, requires no ongoing maintenance once configured, and scales without creating extra work for agents.

[HI Anime]

Hianime is a free site to watch anime and you can even download subbed or dubbed anime in ultra HD quality without any registration or payment.

https://hianime.vip/