nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to make a work item "invisible" to Customers

Tim Bonney

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.

Accepted answers

Susan Waldrip

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

restrict request type.jpg

restrict request type options.jpg

Arkadiusz Wroblewski

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 🤠

All comments

Susan Waldrip

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

restrict request type.jpg

restrict request type options.jpg

Arkadiusz Wroblewski

Hi Tim,

Best,

Arek 🤠

Tim Bonney

Thank you both @Susan Waldrip and @Arkadiusz Wroblewski

Tim Bonney

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

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 🤠

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management