How to lock the Description field in JSM after ticket creation?

Question

I have a requirement to lock the Description field on tickets after creation, for audit purposes — only a small designated group should be able to edit it afterward, while all other fields stay editable.

What I tested and ruled out:

1. JSM Behaviour (the newer native feature) — I tested this directly. Right now, the "View Types" option only offers "Portal Create" — meaning it only fires on the customer-facing Create form, before the ticket even exists. There's no option for Issue View or Portal Edit, so it can't enforce any lock once the ticket is created.

2. jira.issue.editable workflow property + self-loop transition — this can lock an issue while it's in a specific status, with a self-loop transition as an admin-only bypass. But it's all-or-nothing at the issue level — it locks every field, not just Description. Not a fit if other fields need to stay editable.

3. Field-level permissions — JSM Cloud doesn't offer granular per-field edit permissions scoped to specific groups.

The approach that worked — Revert-on-Edit via Jira Automation:
Instead of trying to prevent the edit at the UI level, this automation detects and reverts unauthorized changes to Description:

1. Trigger: Description field value changes (on edit, not on creation)
2. Condition: Check if the user making the change belongs to a designated approved group
3. Branch:
- If user is in the approved group → allow the change, no action
- If user is not in the approved group → automation reverts Description to its previous value (using the changelog smart value for that field)
4. Added a comment explaining why the value was reverted, so it doesn't look like a silent glitch to the end user

Trade-off to flag: there's a brief moment where the field does save before the revert fires (automation is corrective, not preventative — typically resolves within seconds). For most cases this is a non-issue.

Curious if anyone's found a cleaner native way to do this, or if Behaviour support for Issue View/Edit screens is on Atlassian's roadmap for JSM Cloud.

Cristian Quiroz · Accepted Answer

Hey! Good write-up on what you tested. A couple of options you might not have explored yet:

Option 1: Workflow property + field screens

You mentioned jira.issue.editable locks everything — true. But there's another workflow property you can set on a specific status:

jira.permission.edit.group = your-approved-group (group id)

This restricts the Edit permission to only that group while the issue is in that status. Everyone else sees the issue as read-only. Combined with keeping the issue in that status after creation (which is most of the lifecycle), only your designated group can edit anything.

But wait, you said you want other fields to stay editable for everyone. So this alone doesn't solve it either... unless you pair it with the next approach.

Option 2: Screen-based control on transitions

Instead of locking the field on the issue view, control it through transitions:

* On your Edit Screen (the one tied to the issue's current status), remove the Description field. This means nobody sees Description when they hit "Edit" normally.
* Create a separate transition (like a self-loop, e.g., "Update Description") with its own transition screen that includes only the Description field.
* Add a Condition on that transition: only members of your approved group can see/execute it.

Result: regular users can edit all other fields normally, but Description simply doesn't appear on their edit screen. Only the approved group gets the "Update Description" transition button, with a screen that shows just that field.

No automation delay, no revert window, fully native. The only downside is the UX — editing Description requires clicking a transition button instead of inline editing, but for audit purposes that's arguably a feature, not a bug (it creates a clear audit trail in the issue history).

Abubakar Pokam Tchawa · Accepted Answer

Remove Description from the Edit Screen — nobody can inline-edit it directly.

Create a manual automation rule (triggered via a button/action) that prompts the user to input the new description value.

Restrict the automation trigger so only the approved group can see/execute it.

The automation updates the Description field — creating a clean audit trail entry.

Lalithesh · Accepted Answer

Hey @Varun Chillamcharla

Welcome to the Atlassian community!

Option 2, suggested by @Cristian Quiroz would be a great choice if your team is comfortable using a status loop. It allows the team to make wee changes to the original Description while preserving the existing info

With the manual trigger option, you can either replace the original Description with the new input provided or update the Description to include both the original and the new information

Cheers!

Joseph Chung Yin · Accepted Answer

@Varun Chillamcharla

Welcome to the community.  I also agreed with @Cristian Quiroz option #2 approach.  However, what are you trying to prevent the description from changing?

It is because customers who reported the issue, they will not be able to change the Description field after the issue is created.  Only users (with Agent licenses in your site and setup for the project(s) in question) can change it.

Keep in mind that any issue field edit after the issue is created, the issue's audit log will track all the changes that took place - including the Description field update.

Hope this also helps.

Best, Joseph

Marc -Devoteam- · Accepted Answer

Hi @Varun Chillamcharla

Welcome to the community.

Other options (besides provides ones) are:

* Simply remove it from the Edit screen related to the work item type, then this field can't be edited.

You need to create separate screens for create view and edit and set this in Screen Scheme and link this to the Work Item Screen Scheme used on the JSM Space
* Use a Form on the Request (I mean a real form), U se a paragraph field on this form, don't link this to a Jira field and lock the form upon creation (from settings)

Now the input information is in the form only.
* If you do want to use the Description field, you could also create a custom field of type text (read-only) and have an automation to run on issue creation and copy the field Description to the read-only text field.

Your original input in the Description will then be stored in a non-editable field.