Everyone needs to have access rights to the projects that house the Request Queues but those projects also show up in everyone's project list in the Projects Tab which is confusing - because there is no good reason to ever go into them. I can't figure out how to get those off the Projects tab ie via access rights. How do other people do this?
Topics help categorize Community content and increase your ability to discover relevant content.
Hi Jill, only our Sys Admins have access rights to our request queue projects, and therefore it only shows up on our projects lists.
Under queue details, there is a selection for who can add requests to this queue, and ours is set at "Anyone" (see below):
Hope that helps,
Thanks, that is exactly what I was looking for. One more question - the reason we have more access is because when we first were onboarding, people were having access issues with the requests -- like they were limited in uploading documents or proofs, couldn't close out a request and so on (I can no longer remember what the problems were but I do remember that is why we opened the projects wide open to eliminate those frustrations). Before I make this change, are there any limitations the requesters or people assigned to a request experience? Do the requests still show up properly on reports like "requests assigned to me" and will everyone still be able to see the list of "all requests" ?
There are several layers of access that we use to make Queues available to "requestors" vs. the people assigned to the request "planners". Our Queue projects are Admin. only but available to all to make requests. We use Landing projects for the teams assigned to the requests so they have access to the project that houses the requests - but the requestors do not they only have access to the request they have submitted. I'd be happy to share our process - but not sure how to explain it all here.
Hi Jill, sorry I haven't been back here and for some reason didn't get notified of your responses. It sounds like Dawnmarie has a similar process to us. For us, anyone in our company can go to Workfront, and they are granted "Requester" access by default, and can request marketing services. Requests are converted to projects (what Dawnmarie calls Landing projects), and we assign "Planners" and "Workers" (licensed roles) to those. Requesters can only see their requests, their status/updates, and edit the request. If we keep a request a request and don't convert it to a project, then assign people to work that request/issue, those people need to have a "Work" or "Plan" license to do so.
If you share a project with the requester and they only have request access, they will have very limited view access (project details only) and can't do anything with the project.
So my question isn't about Requesters seeing the project - it's about the Workers - they have no reason for the queue projects to be visible to them in the Projects lists - but they need to be able to be assigned to work on Requests. I can't seem to have it both ways - have them able to see a request they are assigned to but not have the projects that house the requests in their "all projects" view.
That's why we have the landing projects. They house the requests that come via the Request Queue and ONLY the team members assigned to the requests see the Landing Projects. We also create dashboards for requests - so there is no need to really be in a Landing Project. We also have teams that do have Projects they manage so if they are not working on "requests" those Landing Projects are not on their list. We have about 1200 requestors and 150 planners over many groups/departments with 35 request queues so keeping it streamlined is important as well as keeping the requests themselves confidential. This is what works for us. I know there are much larger use cases and perhaps they have better processes. I'd love to hear if there is a better way.
@Jill Ackerman‚ - There are multiple settings you can do at the project level in addition to the queue details.
My suggestion would be to set the Queue details up as mentioned but then modify the project access settings so that when they are assigned to an issue they get contribute access to the issue but then not the project.