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; } } }

Internal and external forms

Robert V_qjsvu9

Hello Community,

I have a form, inside of a project, that is tied to a request type that is utilized by both internal customers (within our organization) and external customers (outside of our organization). Also, within the same project there are other forms, tied to different requests types, that are only meant for internal customers.

Is there a way to segregate the form from the rest of the population so external customers cannot see the internal forms (requests types)?

Thank you in advance.

Rob

Accepted answers

Dirk Ronsmans

Hey @Robert V ,

i'm afraid there is no way to limit the visibility of the request types out of the box. Once a customer has access to the project they will see all the forms available.

There might be some apps that allow you to do it if you wish to go that route. (we'll have to check they are cloud compatible tho)

All comments

Dirk Ronsmans

Hey @Robert V ,

i'm afraid there is no way to limit the visibility of the request types out of the box. Once a customer has access to the project they will see all the forms available.

There might be some apps that allow you to do it if you wish to go that route. (we'll have to check they are cloud compatible tho)

Robert V_qjsvu9

Thank you @Dirk Ronsmans

Follow up, would Organizations solve the problem? Putting all internal employees in an organization based on email domain and moving the form outside of the current project?

I tested this and noticed all members of the organization received every other member's ticket notifications, is that customizable so that doesn't happen?

Thanks again,

Rob

Dirk Ronsmans

Hey @Robert V ,

Simply putting the internal "customers" in to an organization won't do you much good. the concept of organizations is mainly to be able to share issues with each other.

As you mentioned by default an issue is created and shared with the organisation (but that can be configured). This is however helpfull if you set up organisations as teams/departments where the customers want to share their issues with each other for follow up.

Keep in mind that even tho you have organisations it is still up to the customer at time of creation to share it or not. (which of course can be overruled by an agent)

As far as visibility goes for the "ability to create certain request types" that won't have any effect based on organisations.

If you move the form outside of the current project tho, so a 2nd project where only your internal employees are customers then they will be split off from the external customers. But that would create the hassle of managing 2 projects and in essence 2 service desks.

Michelle B_n42cdb

We've had a problem where we only want external customers to communicate with us through email and not use our portal so we hid the request types from the portal and removed the request link from the outbound customer email.

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