Show customers the request details the portal keeps hidden
Read-only field values, the assignee, the SLA clocks and related requests on the customer portal, chosen per service desk and checked as that customer before anything renders.
This app answers a request that has been open on Atlassian's public tracker for years:
JSDCLOUD-4328,
"Add fields (view only) in Customer Portal", with 1,724 votes.
The gap
JSDCLOUD-4328 asks for view-only fields on the customer portal. It was opened in September 2016, has 1,724 votes, and is still Under Consideration ten years later. The customer sees a summary, a description and a status; everything the agent filled in afterwards — the environment, the target date, the custom field your process depends on — is invisible to the person waiting on it, so they ask in a comment and an agent answers by hand.
What it does
Pick the fields customers may see, per service desk, with per-request-type overrides.
Show the assignee (name and avatar), or deliberately do not — plenty of teams never want a named engineer exposed to customers.
SLA clocks with remaining time and breach state, selectable per clock rather than all or nothing.
Related requests, filtered to the ones that customer could already open themselves.
A short admin-written note per status, so "Waiting for approval" can say what is actually being waited on.
Comments, attachments, worklogs and security fields can never be selected, by construction.
The panel on a customer's own request: the fields the admin chose, the assignee, both SLA clocks with time remaining, and the related requests that customer can open.Per-service-desk configuration with per-request-type overrides: which fields, which clocks, whether the assignee shows, and the note attached to each status.The access check that runs before anything renders: the request is fetched as the viewer, and a viewer who could not open it themselves sees nothing.
Honest about its limits
The panel renders beside the native request form; it does not restyle it or hide native fields. Atlassian gives apps no hook for that, so the "Share with" control in particular cannot be hidden.
It shows field values and never writes them. If you need the customer to edit a field after submitting — JSDCLOUD-93 — the portal gives apps no way to write back, and this app does not pretend otherwise.
Field values come from the request key in the Forge extension context, never from a payload the browser could tamper with.
The one write path, honestly scoped: Nothing. Every scope this app holds is a read scope; the only thing it stores is the admin's own configuration.
Security & permissions
Built on Atlassian Forge: the app runs on Atlassian's own serverless platform inside your
tenant and stores its data in Forge storage.
It makes no external network calls. Every scope it requests, and why:
read:jira-work
field values, field metadata and statuses on the request
read:servicedesk-request
the request itself, its request type, its SLA clocks, and the as-the-customer access check
storage:app
per-desk panel configuration, in your tenant
The native feature it builds on
Atlassian's own documentation for what Jira Service Management does out of the box, so you can see exactly where the gap is:
No. The app runs on Atlassian Forge inside your own tenant with zero external egress,
which makes it eligible for Atlassian's Runs on Atlassian trust marker.
How is it billed?
Through the Atlassian Marketplace, on your existing Atlassian bill, priced per user like
any Cloud app. The listing has a free evaluation and the exact calculator for your tier.
