Expand my Community achievements bar.

Locking down requests

Avatar

Level 2
Hi Community, (if I've posted this incorrectly, please let me know. My first ever post.) After processing a request for a project, we've run into some issues where people are updating the request issue instead of the converted project. The offenders aren't paying attention to where they're posting and it's causing communication issues. Is there a way to "lock down" the request so no one can access it except for administrators (after it's been converted to a project)? If not, what would some suggestions be to keep this from happening? Jen Bobo Furman University
6 Replies

Avatar

Level 5
Hi Jen, We recently started running into this issue as well now that there is a new PM who is not familiar with the system. We agreed to just close the request manually once the project was made so the request history was in the system and so it didn't cause further confusion. You can also just remove their permission levels under Request/Issue Actions > Sharing. I need to research if there is a way to have the request close when converted instead of deleted. I'll try to update if I find anything and I look forward to seeing what else people mention. Hope that helps! Jazmin Allen-Collins Analog Devices, Inc.

Avatar

Level 10
Hi We had this issue when we first started and so decided to turn on the option to delete the Issue once the Project is created so that there is only one place to post updates. Jill Ackerman

Avatar

Level 3
We recently switched our request queue into Workfront, and came across this same problem. If you go into your Setup area, find Project Preferences > Tasks & Issues. Once you're there, you can toggle the option to have issues delete (first option, "Keep the original..."). This should solve your problem! Justin Enzor Insperity

Avatar

Level 5
Hi Jen, your response came through via email, so not sure if you meant to add here or message directly. Either way, to answer your two questions: Have you run into any issues with deleting the Request? Loss of info, history, etc that you would've needed had you kept the original request? We're afraid of doing that and losing vital info. When you convert the project and opt to have it deleted, it does bring over all the information - documents, updates, etc. We just want to know which projects came in via the request queue vs. which were created as projects (usually internal, but not for legacy items), which is why I want the history. You do have to have a project version of any custom forms, though, to bring that data over. And the form needs to be tied to the project before you delete the request. It can be tied during the conversion process. With the permissions change you suggested, how does that affect them in regards to putting in requests (if at all)? Our offenders are everybody at every access level (except administrators). Permissions can be set at a request-level so that it only affects that one request. As long as your queue settings note who can add requests, any other permission settings are per item (project, task, request). So, long story short - no effect to anything but the request(s) you want them to not comment on. Overall, I would look at it like this: If you want to keep the request record, don't tie the resolution and just manually close it. If you don't care about the record (because the project pulls in updates, docs, etc.), opt to have it auto-delete. Hope this helps!! Jazmin Allen-Collins Analog Devices, Inc.

Avatar

Level 1
I would not delete issues or requests and would leave them as "resolved by.." Best practice. If you are having trouble then it's more a training issue and the lack of clear visual cues from Workfront (hard to tell whether you are in the request versus the project except for the little icon beside the name). We had a lot of trouble with this at my last company. Creative teams (designers, writers, etc.) need a stronger visual cue as to where they were within Workfront, and we did not want them to get bogged down in Workfront training when they are supposed to be spending time creating. My project management team made a habit of adding "R-" in front of every request name during our morning meetings. So, for example ..."R-Halloween Campaign" was the request and once converted (keeping the original issue and tying the resolution) "Halloween Campaign" was the project name. This was much easier for the creative team to navigate, and we went from 2-3 times weekly problems as you describe, to zero problems moving forward. It was a highly effective and easy solution. Christine Barrera Federal National Mortgage Association (Fannie Mae)

Avatar

Level 10
Elegant solution, Christine. Thanks for sharing. As founding PMI member Bill Shakespeare put it, "What's in a name? That which we call a rose By any other name would smell as sweet." Unless it's an r-rose, of course. In which case, the first smell is more of a sniff test. If it's approved, well then the cloned rose will definitely smell sweet. And the r-rose will smell just as sweet. But for goodness sake, don't comment on the latter. Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads