Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How to make a work item "invisible" to Customers

Tim Bonney
Contributor
July 21, 2026

Is anyone able to give me some insight from their experience in making a new Request Type, but locking it down so that it is invisible to those who are assigned the 'Customer' role for the Project space it is in, and is only able to be seen and/or modified by members of an internal 'Tech Team' group, or of the 'Site Administrator' role? We don't want any work items created under this new request type to be visible in any way to the front-end customer Portal.

I've been trying to figure out how to do this, but my fear is...If I create a new security level and security scheme and then apply this scheme to the project in question, how will doing so impact all the other work items and/or configuration within that project? Especially since this project does not currently have a security scheme associated with or applied to it.

Any insight will be appreciated. Thank you in advance.

3 answers

2 accepted

7 votes
Answer accepted
Susan Waldrip
Community Champion
July 21, 2026

Hi @Tim Bonney , have you tried setting restrictions using the Request Type "lock"?

 

restrict request type.jpg

 

restrict request type options.jpg

4 votes
Answer accepted
Arkadiusz Wroblewski
Community Champion
July 21, 2026

Hi Tim,

@Susan Waldrip  request-type restriction is a good start, but locking a request type only controls who can raise it, not who can view the work item once created. To restrict visibility, you'll need a work-item security scheme.

Create a security level (e.g., `Internal – Tech Team`) granting access only to the Tech Team and admins, explicitly excluding Reporters, Request Participants, and Portal roles. Leave the scheme’s default level set to None so existing work items remain unaffected. Then, use Jira Automation to assign the security level whenever a new internal request is created (Trigger: Item created → Condition: Request Type is Internal → Action: Set Security Level).

Remember that site admins don't automatically bypass security levels, so ensure all required users and your automation actor are explicitly included in the level. Be sure to test with a portal-only customer account before going live! or.... Well Sanbox are Good playground.🤪🫣🤠

Best,

Arek 🤠

Tim Bonney
Contributor
July 24, 2026

Arkadiusz,

If the project/space I want to utilize this process in does not presently have any Security Schemas assigned to it, does that mean I need to create a specific Security Schema to add this new Security Level to and then specifically assign that schema to the Project/Space in question? Additionally, if that is the case, since there is no Security Schema assigned to that Project/Space presently, will creating on have an adverse effect on all of the pre-existing work items, request types, etc., or just configuration in general for that Project/Space? I may be overthinking the potential negative impact, but I obviously don't want to unintentionally prevent customers from seeing everything in this Project/Sace, just for this new request type.

Thanks again for your feedback!

Arkadiusz Wroblewski
Community Champion
July 24, 2026

That's completely correct, create the scheme, add the `Internal – Tech Team` level, and associate it with your project.

To keep existing issues and normal customer requests untouched, just leave the Default Security Level set to None. Only items explicitly assigned the `Internal – Tech Team` level will be restricted.👀🤠

Also, make sure your team, admins, and automation actor are explicitly added to that security level, as admins don't automatically bypass issue security.

Best,

Arek 🤠

0 votes
Tim Bonney
Contributor
July 22, 2026

Thank you both @Susan Waldrip and @Arkadiusz Wroblewski

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events