Showing Requesters on Report - Help! :)

[MattAm]

Hello all! Wondering if anyone may know how to solve for this one: To assist with providing real-time updates to work requesters, we've created a custom "Requester" role that the person requesting the work is assigned to when a Task request is received. With this, we then set the "Assigned To" for each task to be the person actually doing the work listed first (in "Business Analyst" custom role) and the requester assigned second to (under the custom "Requester" role). My challenge has to do with having the Requester show in our reporting. While I know I can add filters to show items requested by specific individuals, etc., I'd like to have a report that shows all Tasks with all requesters (including those tasks that may not have a Requester assigned). Would anyone know if this is possible, and if so, how I might be able to go about setting up? Thanks for any help/assistance you might be able to provide! Matthew Amick

[VicAl]

Hi Mathew, Could you use the filter on Role Id (Assigned To >> Role ID) and pair that with the Task Assigned To?

[SkyeHa]

if the requestor is always second, this would be "Assignment users" | "role ID" | equals in your task report. The "Assigned to" "role ID" is for the primary assignee. But if there's no requestor listed... I assume you still put the role in the task? And then, what I haven't tested: if there's no one assigned to the role, will the task show up since the role itself is listed? Otherwise I might also try testing "Task" | "role id" equals. -skye

[NRYNR]

Hi Matthew, While some text mode trickery might sort of get you what you seek, I have to rely on the rule of thumb that I follow religiously, which is planned = work and unplanned = issue. If you have a requester, then you have to have an issue. The primary contact on the issue is always the requester by default. The issue/request should be converted into a task. The "Resolved by" connection between the original issue and the resolving task is what ties the request and the work together, but keeps the records separate from a process perspective. This keeps the requester in the loop on their original request (what's happening). When the task is closed, the issue is automatically resolved, sending an email to the requester. This is Workfront request queues 101, and is by design. Setting it up any other way is incorrect in my opinion, doesn't jive with the way Workfront was designed, and doesn't really reflect the actual process. I recommend you rethink the design so you don't run into major unforeseen challenges later. Thanks, Narayan