Someone asks the same question in the Community every few weeks: the approver clicks Approve in the portal, nothing is written down about why, and the auditor asks. Can Jira force a reason?
For the native approval step, no. The Approve and Decline buttons in JSM do not behave like a workflow transition, so you get no transition screen and a validator on the next transition is not evaluated when the approver clicks. Atlassian knows. JSDCLOUD-6989 asks for screens on approve and decline; when I looked on 4 November 2026 it had 748 votes and the status Gathering Interest. JSDCLOUD-4922 asks for a required comment on a transition in the customer portal, 531 votes, status Reviewing, open since March 2017. JSDCLOUD-6988, approval steps should not bypass the workflow validator, has 494 votes. I do not know whether any of them will ship. The oldest has been open for nine years.
There are things you can do without an app. Make the decline a normal transition with a screen and a validator, which works for agents. Collect the justification in a status or form before the approval. Both move the problem, neither forces a reason at the moment of the click in the portal.
I build Approval Flow, so read the next part with that in mind. It does not stop the native buttons, because as far as I could find Forge has no module or API that hooks into or replaces JSM's native Approve and Decline. What it does is run an approval of its own on the same request. Once showing approvals on the portal is switched on, the people named as approvers see an Approvals panel on the portal request page, under the activity, and can approve or reject there. A rejection will not go through without a written reason. An approval can be set to need a comment as well, per requirement, or with one site-wide switch that also applies to the portal.
A decision made in the portal goes through the same checks as one made in Jira: separation of duties, staged approvals, the signature PIN or authenticator code if you require one. Only a customer who is named as an approver on that requirement can act, and what they see is limited to the requirement text and its status, not other people's names or reasons. The reason box shows the 500 character limit, and after deciding the customer sees their own reason back.
What I tested on 4 November 2026, on my test site: a customer who exists only on the portal, no agent licence, approved a request from the portal with a required reason and a signature PIN. The reason showed up on the portal, in the agent's panel next to the signature, and in the audit trail, which marks the decision as made "on the customer portal".
The limits, plainly. Because it is a parallel approval, a request can still be approved through JSM's own buttons, so the required reason is only enforced on approvals that go through Approval Flow. If you need "nobody can approve this without a reason", the workflow validator that Approval Flow provides on the transition is what stops the request moving on, but it does not remove the native button. I tested one customer clicking Approve, once, and I have not run Reject or every combination of settings from the portal. I have not downloaded the PDF certificate to check how a portal decision looks there. And my customer was logged in to the portal; I do not know what happens for someone who has never had an account.
Are your approvers customers in the portal, or staff who would rather just use Jira? The answer changes everything about what is worth building.
