Who Can See What on Your JSM Request Forms?

[#1]

---

TL;DR

• Your JSM request forms may be collecting more than your customers should share — or more than your agents should see. Request forms are a direct data-entry point from external customers, not just internal issues.

• Field-level visibility on a request form isn't the same as field-level visibility everywhere else. A field hidden from a customer's portal view can still be fully visible to every agent working the queue, and vice versa.

• Native Jira Service Management doesn't offer field-level security on request forms. If a field is on the form, anyone who can see the issue sees the field.

• Check both sides of the form — what the customer submits and sees in the portal, and what agents see once the request lands in the queue.

• Find the gap before a customer complains about over-sharing, or an agent misuses data they were never meant to see. Secure Custom Fields for Jira adds field-level view/edit permissions to JSM request forms — for enterprise-scale service desks running Jira at 1,000+ users. Start your 30-day free trial or book a live demo with our team.

---

Your JSM request forms are a front door. Customers submit account details, financial information, health-related requests, legal claims, or HR complaints directly through a portal — and that data lands in Jira the same way any other issue field does.

Unlike an internally-created issue, nobody reviewed what a customer typed into that field before it hit your system.

Use this checklist to find out what's actually exposed.

1. Do you know which request-form fields collect sensitive data?

Salary details, SSNs, medical information, legal case numbers, financial account numbers — request forms are often built ad hoc, by whoever set up the project, without a security review of what fields were added.

A field built for "additional notes" six months ago may now be where customers paste things it was never designed to hold.

2. Can you control what the customer sees vs. what the agent sees?

A request form has two audiences: the customer submitting it, and the agent working it. Native JSM doesn't separate these — a field on the form is visible to both, with no way to show it to one and hide it from the other.

If a field should be agent-only (say, an internal risk score) or customer-only (their own submitted ID number, not visible to every agent in the queue), there's no native control for that distinction.

3. Have you tested the portal view, not just the agent view?

It's easy to audit what agents see in the issue view — that's the familiar Jira screen. It's much easier to forget to check what the customer sees on the request portal itself, which renders differently and can expose fields nobody thought to hide.

4. Do you know which projects this even applies to?

Field-level control on JSM request forms is only relevant for Company-managed projects — Team-managed projects handle fields differently. If your service desk has a mix of both, the gap may exist on some projects and not others without anyone tracking which is which.

5. Who reviews new request-form fields before they go live?

Request forms tend to grow over time — new fields get added when a new request type is built, usually by whoever's setting up that project, without a second look at what data it's now collecting from external customers.

What did you discover?

If your request forms were built without a sensitivity review, you may not know what's actually being collected from customers.
If you haven't checked the portal view separately from the agent view, a field could be exposed on one side without you knowing.

If Team-managed and Company-managed projects are mixed in your service desk, your JSM field security may be inconsistent by project — not by design.

The good news: you don't need to redesign your request forms.

Secure Custom Fields for Jira adds:

Secure fields directly on JSM request forms — drag-and-drop placement, with view/edit permissions that apply independently of native Jira field visibility

Field-level control across the request lifecycle — configure who can view or edit a secure field whether it's on the customer-facing portal or the agent's issue view

Find the gap between what your customers submit and what your agents see — before it becomes a support ticket of its own.

Start your 30-day free trial on the Atlassian Marketplace. Running a large-scale service desk and want to talk it through first? Book a demo with our team.

[Mia Tamm _Simpleasyty_]

Really useful reminder, @Karl from RicksoftThe distinction between a field being hidden in a particular view and the data actually being protected is an important one and probably very easy to overlook as request forms evolve over time.

I especially liked the suggestion to test both the customer portal and the agent side separately. A lot of security assumptions can come simply from “I can’t see it here, so it must be hidden everywhere.” The checklist is practical too, something teams could genuinely use before publishing a new request type.

Thanks for sharing!