@Venkat Jira Admin , the boundary first, then the two designs that get both of your requirements.
The boundary: the customer's request page on the portal shows the fields that were on the Request form at creation, and nothing else. There is no "show after creation" switch on a Jira field. If the field is on the form, the customer is asked for it at creation (a hidden field with a preset value is not shown at all, then or later). If it is not on the form, the portal never renders it. That is why "Request form" and "Work item view" are the only two options you see: the second is the agent side. So the answer is not a field setting; it is a second surface that the portal does render after creation.
Design 1, native, no app: an external Form in submitted state. Atlassian documents this pattern as Show read-only fields in the Customer portal using Forms. Build a one-field form whose field is linked to your number field, then in your existing rule, after the copy action:
- Add form (an automation action) attaching that form to the JSM work item; set it to external in the action so the customer can see it on the portal.
- Get the form into submitted state so it renders read-only. Forms in submitted state need reopening to edit, and locked forms can only be reopened by project admins, so the customer can read the number but not touch it (view, add, or edit a form on a work item).
Requirement 1 is met because the field stays off the request form. Requirement 2 is met because the form, not the field, is what the portal shows, and its state controls editability. Test the linked-field value on the portal before you rely on it: confirm that the form displays the value the rule wrote into the Jira field rather than a blank, and if it does not, have the rule write the value into the form field on submit. I have used forms this way for read-only reference data; I have not tested this exact copy-then-add sequence on Premium this month, so run it once on a test request type.
Design 2, the plain one: a customer-visible comment. If the customer just needs to see the number, add a Comment on work item action to the rule with "share with customer" on: "Reference number: {{issue.Your Field}}". It is read-only by nature, visible on the portal immediately, and needs no form. The trade is that it is a comment, not a field, so a later change to the number means a second comment rather than an updated value. Many teams stop here and never miss the field.
Pick 1 if the number must live where the customer expects a field; pick 2 if you need it live in ten minutes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.