How to notify a user in the request queue from the custom form

[Jaxelle]

I have created a project request queue. Is there any field in the custom form that would allow you to notify a user when you're filling in the request?

I know I could have an single line text field / a drop down box, but that won't actually notify the user.

Is the only way to assign the user BEFORE the request has actually been submitted? or is there a field that can be tweaked to allow this?

[Madalyn_Destafney]

Hi there, when users are submitting something to the queue, that is coming in as an Issue. You can set up routing on your queue topics or queue to automatically go to X user (or team) - recommended if these requests will always go to same person or team - or you can include the assignment field in your queue details setup so the request can be assigned to a user/team if you want the requester to fill this in with their request (better if request assignments are more variable). The users are notified of the requests when they come in bc they are assigned (ensure their email notifications are on for this). 

If this helped you, please mark correct to help others : ) Let me know if you have more questions on this!

[Jaxelle]

Hi Madalyn,

Thanks for your response.

I don't believe the first suggestion with the routing on the queue topics will work as the idea is the requests should go to several different individuals each request rather than a team and a routing route can only go to 1 assignee or a team, right?

I can't find the assignment field you mention in the queue details set up? but this does sound like the correct path as I want the requester to fill this in with their request. Can you please elaborate where this will be?

Thank you!

[Madalyn_Destafney · Accepted solution]

Sure thing!
When you're in your request queue project (where the queue is set up and requests go to unless routed elsewhere), go to Queue Details on the left side. In the New Issue Fields, you can have 'Assigned To' selected so the requester can input a person's name they want the request to go to (by way of being assigned). Or you can have Team if it'll be to a Team. In the Assigned To, you're able to put more than one person.

If this helped you out, please mark correct to help others : )

[Jaxelle]

thanks Madalyn - but this doesn't go into the request form, this is only an action showing in the request details after the request has been submitted? 

[Madalyn_Destafney]

No, this would show at the time of request creation. It will show any field from these settings first that you have selected, and then whatever custom form you have for the requester to fill in below (whatever form(s) you have associated with the queue/queue topic). They fill in all and then submit.

[Jaxelle]

ok but then what's the difference between having a 'assigned to' on the request creation and actually assigning a person at the top right bar (in between % complete and planned completion date?)

[Richard__Carlson]

I'm not sure if I understand what specifically you're asking... "what is the difference.."

I guess one way of looking at it would be that very few people within our system have the authority to assign tasks - this is a systematic approach which utilizes pre-existing rules and a workflow which takes away the need and related permissions structure assignment for someone to assign it manually.

[Madalyn_Destafney]

The difference is when in the process the request is assigned. In the queue details, you are allowing the requester filling in request form to also choose who the issue/request is assigned to at time of submission. When this is filled in, it will show as assigned to XYZ user in that top right field you're referring to. If you don't have the assignments field and the request isn't assigned to anyone, after submission the requester or someone else would need to go into the issue and assign it.

Think about how you want your queue to work - sometimes the person receiving the request (assigned to) isn't the person executing the work. For example, if you have a request going to a project manager as a gatekeeper to review the request and convert it into a project, the request/issue is assigned to the PM for them to receive it, but then the PM may assign others the execution when converting it to a project (or even if the issue remains as an issue and never gets converted, the PM may assign it to someone else to execute).

[Jaxelle]

Got you! So I've just ticked the box 'assigned to' in the queue details and done a test form and it comes through as 'assignments' right? This is what I was looking for It makes sense now. Sorry if I was confusing it and thanks for your help! Screenshot attached. 

[Madalyn_Destafney]

All good! Yup, that assignments field in your screenshot now shows because you added the 'assigned to' checkbox in your queue details.

[Jaxelle]

Thanks so much

[Richard__Carlson]

If I could clarify what Madalyn spoke about

Requests in the system are actually parent projects - new project requests are actually issues within that project that get converted to their own project.

In order to do this you will need to identify / have permissions / edit the parent project for the request queue.  Once you open and view the correct parent project you would want to view and edit the Queue Topic section.  If you have Queue Topics defined in your request queue, by default each one can be assigned to a specific person.

If you have a Queue Topic to manufacture screwdrivers and only Bob manufactures screwdrivers you can have Workfront automatically assign screwdriver requests in that specific request queue to have them auto assigned to Bob in the Default Assignee tab

Hope this helps

[Jaxelle]

I don't see where in the queue topic there is an option to have a specific person? screenshot attached.

[Madalyn_Destafney]

If you want requests to always go to same person or team, that's the routing rule I mentioned in a previous reply. It sounds like you don't, so you'd utilize the assigned to field in your queue details so the requester can assign with their request.

I suggest you learn more about this here: https://experienceleague.adobe.com/docs/workfront/using/manage-work/requests/create-and-manage-reque... From this page, there are related links on the left side of the page about routing rules, queue topice, etc.

[BrentHat]

This is a nice solution @Madalyn_Destafney. I'm dealing with something similar, but with one wrinkle - the native fields that can be toggled on and off in the details section of a request cannot be turned on because of a shared agreement within our company and an administrative rule that won't allow a request queue to show anything other than "Subject" because it would not be appropriate for the other queue topics within the request queue. In other words, even though I can turn on "Assigned To," I'm not allowed to because it would mess up the other queue topics within the request queue. 

My first and only thought was to use the relatively new native fields feature within the custom form attached to the queue topic, but "Assigned To" isn't an option! Am I stuck here?

I can't use the routing rule that's in place because it's shared by multiple workflows. I'd like to avoid creating multiple new queue topics to handle this if possible. 

At the end of the day, we just want to notify our account manager when work is being requested of a production team that they may or may not be interested in. 

Thanks!

[Richard__Carlson]

This might be a slightly different take on the solution but we have incoming request queues and people would monitor those queues for new requests and then convert them to projects in a timely manner.  This removes the manual step where the requester has to send a message to someone to inform them that a request has been submitted.

To answer a part of your question directly - requesters do not have the authority within the system to assign work to anyone.  What you're suggesting might not be possible.

[Jaxelle]

Thanks Richard. I also have a report for each team which shows new requests coming through but that's why I'm looking for a field in the request form that will allow a worker to be notified/ and assigned (rather than doing it after the request has been submitted).