How to Let External Users Change Work Item Status
Overview
Using External Share for Jira, you can share links that let external users change a work item's status. You can allow status changes broadly, or restrict external users to only the specific transitions you choose.
Enabling status changes
External users can change a work item's status only when the Status field is available and editable. To allow this, you need to ensure the status is enabled at both the space level and the individual share level.
Phase 1: Ensure status edit is enabled on space level
Open External Share and go to Space Configuration.
Click Edit configuration or Create new configuration.
In the field configuration, find Status and check the View and Edit options.
Phase 2: Enable status edit on the share
Provided that the space configuration settings allow it (as configured in Phase 1), you can choose to enable status editing for an individual share.
Open the specific share's link details.
Navigate to the Permission tab.
Enable the Status field for viewing and editing.
Once enabled on the share, external users can change the work item's status directly from the shared page.
Once enabled, external users can change the work item's status from the shared page.
Configuring allowed status transitions
By default, when status editing is on, external users can perform every transition Jira offers on that work item. To limit them to specific transitions, use the Allowed status transitions editor.
On the Status row (the same row where you set View and Edit), click the … button labeled Allowed status transitions. Only the Status row has this button.
With nothing configured, every transition Jira offers is allowed. Existing shares are unaffected.
As soon as one project (space) is added or one rule exists, the share switches to allow-list mode: only the listed transitions are allowed, across every space in the share. A space with no usable rule allows nothing.
Adding a space to the list does not open it, it locks it down. A space on the list with no rule blocks every status change in that space. That is how you say "nothing is allowed here."
Why this can't be done in the Jira workflow
Every visitor of a shared link acts as a single app account, so Jira workflow conditions and permissions cannot tell an external viewer apart from your internal team. Blocking a transition in the workflow would block it for your team too. The allow-list is the only place this policy can live.
Step 1: Add spaces to the list
At the top of the editor:
Add this share's spaces: works out every spaces the share reaches and gives each one a card. For a single-work-item or single-space share this is instant; for a filter, JQL, or board share, the app reads the query and lists the spaces behind it.
Find a space to configure… + Add: add one by name.
Step 2: Allow the transitions
Each space card offers the transitions its real workflows actually perform, not a raw list of statuses. Options read like To Do → In Progress, with trailing icons showing the work item types whose workflow offers that transition (hover for names). Jira global transitions appear as Any status → Done. Self-transitions are never offered.
Add a transition… + Add: allow one transition. Transitions already allowed drop out of the picker.
Add all transitions: allow every transition the space’s workflows currently offer. Transitions added to the workflow later are not included.
Allow all status changes here: whatever Jira offers, now and in the future. Use it to keep one space open while the rest of the share is limited.
Step 3: Check it on the shared page
Work-item share: An allowed item shows a status dropdown listing only the allowed targets. A blocked item shows no dropdown; the status is plain text.
Board share: A blocked card cannot be picked up; an allowed card can only be dropped into columns its rules permit. If the allow-list changed after the page loaded, the drop is refused and the card springs back, with an error toast explaining why.
If a submitted change is not on the list, the server refuses it and the status stays put. The external user sees a message explaining the change is not permitted and to reload the page.
Reusing a configuration between shares
At the bottom of the editor
Copy config: copies the rules and configured space list to your clipboard as JSON.
Paste config → Apply: replaces the current configuration (it does not merge). After the workflows are read, you get an itemized result of what was imported and what was ignored.
Because status and space IDs are taken as authoritative, this is intended for shares on the same Jira site.
Limits and known gaps
Removing the last rule does not re-open a space. It stays configured (and therefore blocked) until you Remove space on its card. Clearing everything returns the share to unrestricted.
Only spaces you can browse are listed. A space your account cannot browse still gets blocked without a card; add it by name, or have someone with wider permissions configure the share.
Workflow reads are cached for about 10 minutes, so a workflow you just edited in Jira may not show its new transitions immediately.
Rules are stored by status ID. Renaming a status is transparent; deleting one makes the rule inactive.
Team-managed spaces define their own statuses, so configure each one on its own card.
Limits: 500 spaces and 2000 rules per share.
Automation and metadata
To help you track the source of status changes, the system records metadata whenever a work item is transitioned through an external share. This data is stored as an Issue Property named shareUpdate and can be accessed via Jira Automation or the REST API.
Metadata Structure
The shareUpdate property object contains the following fields. Note that context fields (like boardId and jql) may be present depending on the view context the user was in when they triggered the transition.
Field Name |
Availability |
Description |
|
Always present |
UUID of the external share. |
|
Always present |
ID of the external share. |
|
Always present |
The ID of the work item that was transitioned. |
|
Conditional |
Present if the transition occurred while viewing the issue share within a Board context. |
|
Conditional |
Present if the issue share was accessed via a JQL query (e.g., Filter, Timeline, or Custom Board shares). |
|
Conditional |
The ID of the logged-in external user (if applicable). |
|
Conditional |
The email of the logged-in external user (if applicable). |
|
Conditional |
The display name of the logged-in external user (if applicable). |
This metadata can be retrieved using the Jira REST API at the following endpoint:
GET /rest/api/3/issue/{issueKeyOrId}/properties/shareUpdate
(Replace {issueKeyOrId} with the actual Key or ID of the transitioned work item.)
Example Payload
{"key": "shareUpdate","value": {"uuid": "a1b2c3d4-e5f6-7890","id": "12345","issueId": "1001","boardId": "55","externalUserId": "1","externalUserEmail": "user@example.com","externalUserDisplayName": "Jane Doe"}}