Requestor needs to add a file after a Project has been created

[FlorenceCr]

We have a situation where a Requestor was asked to provide a file after their request was turned into a project. Since the Requestor (with a Request license) can't add a file to a project, they added it to the original request. Unfortunately, the person working on the project didn't know the file was added so the project sat.

Has anyone dealt with this issue and come up with a resolution?

Thanks,

Florence

[CalvinFold]

Honestly…email (+Box) was our solution.

[AnthonyIm]

I usually recommend that the team uses the "Request a Document" feature, but in the Request (because the requestor doesn't have access to the project). By using the Request a Document feature, there is an email notification when the requestor has uploaded it so you know right away and can easily move it to the project.

[SamanthaIsin]

We give our requestors permission to add documents and make updates to the project. We also train them to be very diligent about making updates and tagging the owner of the project whenever they need something so nothing gets lost. Is there a reason this wouldn't work for you?

[FlorenceCr]

Our requestors aren't able to upload documents in a project. How were you able to give them permission to do so?

[AnthonyIm]

Hi Florence, when you convert an issue to a project, one of the questions is "Give {requestor's name} access to the project." Just check that box and you are set. :)

[FlorenceCr]

Thanks Anthony. I do see that the Requestor has access to View projects with the added ability to "Add Documents" and "Add Issues". However, when I log in as a Requestor and go to a project, the "Documents" tab (New Experience) doesn't show up even though I indicated in the Layout template that the Requestor layout should include the Documents tab. I wonder if this is a New Experience layout issue.

[SamanthaIsin]

What Anthony said!! We also share portfolios and programs with their accompanying requestors so permissions filter down on at least a view access. I don't know if you're organized where that's possible, but it's a good catch all.

[ElenaDooley]

Those are good suggestions. I've had similar issues with users "working" (making updates or adding documents) back in the original issues rather than the resolving project and posted a question in the community along with an idea in the idea exchange a few months ago for more flexibility in the issue/request control settings.

[FlorenceCr]

Thanks Elena. I voted for your idea to add the ability to lock converted issues.

[CalvinFold]

We're in a similar conundrum:

We don't want to delete the original request/issue, but we also don't want them editing it after it's converted to a project or task. We categorically don't give requesters access to the project, so that really isn't a workaround either.

What I did was block the path of least resistance by creating a dashboard for requesters that shows requests that have been converted, but does not give them a clickable link. Not perfect but the best we could come-up with. We also train requesters not to do post-conversion edits via PDF and video.

We deal with post-submission/post-conversion adds/changes via email, or via additional in-system requests.