Custom Fields for JSM Portal
Deutsch Get the app

For Jira Service Management Cloud

Show portal customers the fields they keep asking about

Custom Fields for JSM Portal puts the Jira fields you choose on the request page of your Help Center, with your own labels, in the customer’s language. Open a field for editing, and the customer corrects their own asset tag or location instead of raising a second request. No Jira licence for anyone.

Try it free See all features

Free for up to 10 users. 30-day evaluation. Billed through your Atlassian account.

Help Center · IT Service Management · ITSM-50

Help Center / IT Service Management / ITSM-50

Wi-Fi drops every ten minutes

RS
Rana S. Agent · 2 h ago

Thanks. We've raised the urgency. Is it only your notebook, or others in the office too?

JM
Jonas M. Yesterday

Restarted the notebook and reset the adapter, it still drops on both networks.

Status
Waiting for support
Request type
Report a system error
Added by the app Custom Fields

Additional information

Impact
Minor / Localized
Urgency
Medium
Service component
Office Wireless Network
Environment
Restarted the notebook and reset the network adapter; it still drops after about ten minutes on both the guest and staff networks.

What it does

The information is already on the request. Your customer just cannot see it.

A portal customer is an unlicensed user and sees a small, fixed set of fields. The priority, the due date, the asset tag and the cost centre stay with the agents, and every “what’s the status?” comment follows from that.

Show the fields that answer questions

Pick any custom or system field from a dropdown and give it a label your customers understand. It appears in the request’s sidebar, read live from Jira.

  • Priority, due date, components and more
  • Assets objects by name, not by number
  • Long text as a preview with “View full text”

Let customers correct their own details

Open individual fields for editing. The customer gets a dropdown, a date picker or a text box, and Jira accepts only what it would accept from an agent.

  • Off until you switch it on, per field
  • Choose who may edit, and until when
  • Every change recorded, by customer

Run it across every service desk

One default configuration, and your own for each service project. Project administrators maintain theirs; you move a proven setup to staging and production by export.

  • Up to 50 project configurations
  • Labels in 26 languages
  • Diagnosis per request and per field

Portal editing

Six checks on the server, before Jira is touched

A portal customer cannot write to Jira under their own account, so the app writes on their behalf. That is only safe if nothing the browser sends is trusted. None of these checks runs in the browser.

  1. 1

    The request

    Taken from Atlassian’s page context, never from the browser. A customer can only ever act on the request they are viewing.

  2. 2

    The fields

    Only fields marked editable in the configuration for that project. A payload naming any other field is refused as a whole.

  3. 3

    The person

    Anyone who can see the request, reporter and participants, or the reporter alone: your choice. By default only while the request is open.

  4. 4

    Jira’s own rules

    Jira must report the field as settable on that very request, which means it is on the edit screen and the app may edit there.

  5. 5

    The value on screen

    The value the customer saw is sent back. If an agent changed it meanwhile, the save is refused.

  6. 6

    The input

    Options are checked against Jira’s list for that request, plus formats, lengths and counts. Errors name the field.

Try it as the customer
Custom Fields

Additional information

Impact
Minor / Localized
Urgency
Medium
Location
Frankfurt, 3rd floor
Assigned team
Network Operations
A demo on this page. No request is changed.

Features

Everything between the field in Jira and the customer’s screen

What the customer sees is small on purpose: a few labelled values and, where you allow it, a button. Everything else is on the settings pages.

Customer sees on the request page in the Help CenterSettings for Jira and project administrators

On the request page

The panel in the request’s right-hand column, in the customer’s language and time zone.

  • Labelled field valuesCustomer sees
  • “View full text” for long valuesCustomer sees
  • Change valuesCustomer sees
  • Hints while editingCustomer sees
  • Required fieldsCustomer sees

Assets objects

Jira hands over an Assets field as an identifier. The app shows the object’s name and can offer a search limited to the types you allow.

  • Object names instead of IDsCustomer sees
  • Object search for the customerCustomer sees
  • Allowed object typesSettings
  • Detect accepted typesSettings

Choosing fields

Every field on your site, from a dropdown, by name. No field IDs to look up.

  • Field pickerSettings
  • System fieldsSettings
  • Labels and headingSettings
  • Order and placementSettings

Per service desk

Different desks need different fields. The default covers the rest.

  • Default configurationSettings
  • Project configurationsSettings
  • Project settings pageSettings
  • Editing policySettings

Languages

The app speaks 26 languages. Your own words can too.

  • App text in 26 languagesCustomer sees
  • Translated labels and hintsSettings

Rollout, diagnosis & logs

What makes it manageable on a site with fifty service desks and several administrators.

  • Apply to other projectsSettings
  • Export & importSettings
  • Check a requestSettings
  • Check in JiraSettings
  • Display check & field inventorySettings
  • Change log & customer logSettings

See all features

For larger service organisations

Built for sites where one setting reaches thousands of customers

The app adds very little surface to your portal. What it adds is controlled at three levels: which field, which audience, which project.

Delegate to the people who run each desk

Project administrators maintain their own project’s fields, labels and editing rules under Project settings. The default configuration, the project list and the languages stay with Jira administrators.

Safe with several administrators

If someone else saved while you had the settings open, your save is refused rather than silently overwriting theirs, and you are offered their version to re-apply your change on.

Staging to production, not retyped

Export a complete configuration as text and import it on another site. Apply one configuration to many service projects in one step.

Edits you can account for

Jira’s history names the app for a portal edit, because a customer cannot write with their own account. The app’s own log names the customer, the request and the fields.

The rollout we recommend

  1. Show, don’t editThree fields on one project. Priority first.
  2. One low-risk fieldA location or an asset tag. Nothing that drives an SLA.
  3. Check in JiraConfirm the edit screen and permission, then try a real request.
  4. Watch the logA week of “Changes by customers” tells you who uses it.
  5. WidenApply the proven setup to other projects.

Read the enterprise rollout guide →

Security & compliance

The app lets unlicensed users read and write. So it keeps almost nothing.

It runs entirely on Atlassian Forge. There is no vendor infrastructure in the path, and we as the vendor never receive your data.

QuestionAnswer
Where does the app run?Entirely on Atlassian Forge, inside your Atlassian tenant.
Does any data leave Atlassian?No. The app declares no external endpoints and makes no external calls.
Are field values stored?No. They are read from Jira each time a request is viewed and never cached.
What is stored?Your configuration, and two capped logs of account IDs: who changed the configuration (last 100) and which customer changed which field (last 200).
Can a customer reach another request?No. The request comes from Atlassian’s page context, never from the browser.
What happens on uninstall?All stored data is removed. There is no vendor-side copy.

Security & compliance details

Use cases

What service desks put in the panel, and why

Each guide names the fields worth showing, the ones worth opening, and the setting that matters most for that kind of desk.

Let customers correct their own asset tag and location

The IT desk case: fewer “wrong device” comments and no second request to fix a detail.

Read more

Show HR requests’ progress without opening the approval trail

Effective dates and case categories visible, anything approval-related read-only, editing for the reporter alone.

Read more

Show Assets objects by name on the JSM portal

Why portals show an Assets field as blank or a number, and how to let customers pick the right object.

Read more

Roll portal fields out to fifty service desks

A default, per-project overrides, delegation to project admins, and staging to production by export.

Read more

Pricing

Simple licensing through your Atlassian account

Small sites

Free

On sites with up to 10 users, with every feature including portal editing.

From 11 users

USD 1.00

Per user and month for users 11 to 100, with the unit price falling in every higher tier. The Marketplace shows the price for your tier.

Before you buy

30 days

A full evaluation on your own site. If a subscription lapses, the portal shows a licensing notice instead of values, and your configuration is kept until you renew.

BillingThrough your existing Atlassian account. Atlassian is the merchant of record.
TermsThe standard Atlassian Marketplace end user agreement. No separate contract.
SupportMonday to Friday, business hours (CET). First response within one business day.
Get it on the Marketplace

FAQ

Questions service desk teams ask before installing

Do portal customers need a Jira licence?
No. The app reads values, and writes a permitted change, with its own app-level permissions. Customers need nothing beyond access to their request.
Which fields can be shown?
Custom fields of every common type and Jira system fields such as Priority, Due date, Components, Versions, Description and Resolution. Two kinds are refused whatever you configure: the issue security level, and containers such as comments, worklogs, attachments and issue links.
Which fields can customers edit?
Text, multi-line text, number, URL, date, date and time, select lists, radio buttons, checkboxes, cascading selects, labels, versions and Assets objects, plus ten system fields. People and group fields are never editable, so a customer can never browse your user directory.
I switched editing on but there is no button in the portal.
Jira has the last word: it accepts a change only if the field is on the project’s edit screen and the app holds “Edit issues” there. Check in Jira on the field names which one is missing.
Why does the issue history show the app instead of the customer?
An unlicensed customer cannot write to Jira under their own account, so the change is applied with the app’s permissions. That is why the app keeps its own log of which customer changed which field on which request.
Is the data up to date?
Yes. Values are read from Jira each time the request is viewed. There is no copy to go stale.
Is there a Data Center version?
No. It is a Forge app for Jira Service Management Cloud.
How do I get support?
Through our support portal, or by e-mail to support@vi2va.de. The Check a request result on the Diagnose tab usually answers the question before we do.

Start with the three fields your customers ask about most

Show them first. Open one for editing when you are ready. Nothing becomes editable until you switch it on.

Get it on the Marketplace Documentation