Can non WF users submit a request via a request queue?

[ssims06]

From what I've read, I believe this is a limitation, but we'd like to enable non-WF users to submit a request via a request queue. Is that possible? Or does anyone know of a workaround? 

[Heather_Kulbacki · Accepted solution]

non-users can't submit directly. We have some that submit to a form on our website, then we have an API connection that takes those inputs and enters them into Workfront.

Of course, the "entered by ID" on those submissions is our API connection profile. So the web form needs to gather who submitted the request and that data is put into custom fields on the Workfront form.

[IanRe]

Been looking at this myself and here is what i have got to

Create and external Q and 

1. Crude Option - Turn on email access (this gives you an WF email address) a external user sending an email in to that will have it land in the Q header of email is Title, body is description. the queue can as we know be set up to show to a particular team

2. More refined and uses custom forms - Give out Submitter licences to your external user but group them in and external user group make the Queue and your custom form only visible to that group not all users groups (ensure all other Queues/custom forms are only visible to the relavent internal teams/Groups, this hides them from the external group/user) Share log in page when they log in they will/should only see the relavent custom form and on completing will forward as you require based on what you have on the form you can filter Inboxes to different teams who can pick up and progress or have one inbox that is triaged and assigned to workers to deal with.

That as far as i have got and on initial testing i just need to change teh setting on my other Qs so there not visible

[JillAc]

They need a login and some semblance of a layout template to submit requests via the website. What I would like is for non-licensed reviewer licenses to be able to upload a proof, make edits on it and then submit the request to make the edits on their proof.

[IanRe]

Can i ask why you would have them upload a proof then make edits on it then submit to have the edits worked on.

Have the team responsible for the initial creation upload the proof and send to the user to capture edits and approvals. the will automatically receive a WF  notification that edits have been added to said Proof and can amend accordingly and send back as a V2, the non license user doesnt need even a reviewer licence for this. 

[JillAc]

If the design team uploads the proof, where would they put it if there is no request to attach it to? Your way adds steps, and the way it is currently adds steps. If the designer makes a proof before the request is submitted -- where is the request they attach it to -- it has to go to something and have the form with the details of what they are changing? So in your way, the requester has to ask for a proof, the designer has to find it digging through the files, and add it (adding zero value to that step, it's administrative, and a chance they choose the wrong one) and then the requester makes their edits and it goes right back to the designer. OR the way it is now, the requester adds the PDF and then has to wait for an admin (me) to turn it into a proof, and then go back and make the edits an hour later. So much faster and more efficient if one of the options would be to upload a proof to a request rather than a document.