Showing Requesters on Report - Help! :) | Community
Skip to main content
M
MattAm
Level 2
February 13, 2020
Question

Showing Requesters on Report - Help! :)

  • February 13, 2020
  • 3 replies
  • 683 views
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
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

3 replies

V
VicAl1
Level 10
February 13, 2020
Hi Mathew, Could you use the filter on Role Id (Assigned To >> Role ID) and pair that with the Task Assigned To?
S
SkyeHa
Level 10
February 13, 2020
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
N
NRYNR
Level 10
February 18, 2020
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
Terms & ConditionsAccessibility statement

Loading footer...