Restricting Access to Requests

[AnthonyPernice]

Is there a way to restrict access to individual requests made in a request queue? I have a number of different account teams making requests in a queue. I want to build a reliable dashboard for them to review and manage these requests but seeing as they all have access to the Request Queue, the therefore have access to all of the hundreds of requests made in the queue. Is there a way I can let them make requests but NOT inherit access to all of the requests it contains? Anthony Pernice Healthcare Consultancy Group

[SkyeHa]

I think so... I think I did this a few times, where I set up in the queue setup area so that people in a specific group would be able to submit requests but then I removed their view access to the project. I think when I set things up that way, they were only able to see their own requests and not all the requests in the queue. -skye

[Richard__Carlson]

The way that I'm able to control it relates to the fact that the request queues are essentially individual projects, if you share the "project" in the request queue with someone they will see it. If you take it away they won't see it. Richard Carlson Behr Process Corporation

[VicAl]

Skye & Richard are correct. Under the project that you've created to expose the queue go to Queue Details where you've obviously already checked the box to Publish as Help Desk Request Queue . Under Who can add requests to this queue? select People with view access to this project . Then you control who can see this Request queue by giving whomever you wish View access under Project Actions > Sharing. You can give access to individuals, teams, Groups (Divisions for us), etc. This is how I set up EVERY queue now. As a best practice (I believe our Workfront Implementation Consultant recommended this to us years ago) I also create a "landing" project and route all the requests there. This way you can keep your access separately. You can control access to submitting the requests in the queue project and the requests themselves in the landing project (sometimes you want to allow different people to view them). In addition, if your requests project gets too large and you have to spin off another one, you don't have to touch your Queue project (except the routing). Just feels safer. I also created naming conventions and standards to know when a project is a landing project. So for example we have a menu/queue project called Hardware Request , and the landing project is called Hardware Request Project . So I try to keep the same prefix of the queue project so I know they're related. And I keep the landing projects in a Portfolio called Processes & Workflows, so I know the nature of this project. It just helps me keep these out of reports if I want (or add them to reports �� ) and stuff like that. It also helps me know where to look when someone has an access problem. NOTE: speaking of access problems, there's a tricky equation here in that the landing project controls whether they see the custom form. Under that landing project you MUST set the access for Requests to Contribute under the Edit Project. This can be a hidden issue if you don't know about it. See screen shot. Let me know if I've confused things with my babbling.

[AdinaPi1]

We use the first option "Anyone" that way we don't have to give separate view access to the project. They only have access to view the request that they submitted themselves, and no others. Adina

[VicAl]

Hi Adina, Yeah that works too (well you knew that �� ). Of course anyone can then see that Request menu. In our case, there are some Request menus we don't want everyone to see (or be able to submit). For example, we have one that begins a workflow to Offboard people that leave the company. HR didn't want everyone to have that capability, so I did the setup like below and only gave access to the Supervisor Role. We also didn't want everyone to see every menu item as the list starts to get long and confusing for people. So that was another consideration. Hope you are well.