Report Filter For Tasks Using Complex Exists

[tnebes_og]

Hello,

There is a need to create a report that shows all tasks who have an approval process on them whose approver is the currently logged in user or one of the currently logged in user's teams.

Since the filter capability is limited to 4 relationships in text mode, I assume the EXISTS should be used.
The link between the task and the teamID/userID is:

task->approvalProcess(ARVPRC)->approvalPaths(ARVPATH)->approvalSteps(ARVSTP)->stepApprovers(SPAPVR)->teamID/userID

Do you know how this can be achieved, so that all tasks have been listed whose step approvers are $$USER.ID or $$USER.teamIDs?

I have somewhat of an idea how this should be executed but sadly Workfront throws errors:

EXISTS:A:$$OBJCODE=TASK

EXISTS:A:approvalProcess=ARVPRC
EXISTS:A:approvalPaths=ARVPATH

EXISTS:A:approvalSteps=ARVSTP

EXISTS:A:stepApprovers=SPAPVR

EXISTS:A:userID=$$USER.ID

Essentially, the idea is to use the linking objects to link all the way to the userID starting from TASK->ARVPRC.

Thanks

[skyehansen · Accepted solution]

I think you need to go back to the drawing board on this one. 

https://experienceleague.adobe.com/docs/workfront/using/reporting/reports/text-mode/create-complex-t... 

Think of your first line as "here's where I'm going to need to go to get the information I'm looking for". Think of your next line as "here is the link between the object that I'm in now, and the place I'm looking in for the information".

In your first two lines, you should be able to inform your report that from your task report, you're looking in a different object, and how you will link the two. (spoiler alert: you will not be able to use additional lines to step across multiple objects in the way you had hoped)

Looking at your string, this is all highly complex, and I don't really know that it will be able to be done in this way. In a normal situation you would simply go to one of your last two objects (e.g. approval stage or stage approvers) and be able to link straight back to the task in some way (e.g. through the approval process ID) but you can see this isn't possible.

I wonder therefore, if you would consider going through ARVSTS (the approver status collection), and linking through the task ID. I think this might provide much faster access to what you want (assuming I understand what you want!!). Sample code might look like this:

EXISTS:a:$$OBJCODE=ARVSTS
EXISTS:a:taskID=FIELD:ID

EXISTS:a:stepApprover:userID=$$USER.ID

EXISTS:a:status=AA

So there are the first two lines I was talking about. From your task report you want to link to approver statuses by using the task ID.

Then the actual filter is that the step approver user ID is the ID of whoever is logged in.

I threw in one more filter, which is that the approver status is still pending. (the logged in user is not interested in approvals that they already approved or rejected)

[Doug_Den_Hoed__AtAppStore]

Hi folks,

Shout out to @skyehansen...

I had made note of your Approval Status Collection filtering technique when you first raised it, and returned to it today to DRASTICALLY simplify some project report approval filtering for one of my other SysAdmin colleagues. Instead of checking for certain Approval Step names and/or certain Approvers (which are continually evolving, and therefor required continual maintenance on multiple report filters), we adapted your approach to this pattern:

AND:1:EXISTS:a:$$OBJCODE=ARVSTS
AND:1:EXISTS:a:projectID=FIELD:ID
AND:1:EXISTS:a:status=AA
AND:1:EXISTS:a:stepApprover:userID=$$USER.managerID
EXISTS:a:$$OBJCODE=ARVSTS
EXISTS:a:projectID=FIELD:ID
EXISTS:a:stepApprover:userID=$$USER.ID

Using the above in a filter on a Project report:

• the logged in user ($$USER.ID) can now easily see
• any Project where they were among those people approving the project (stepApprover) that is
• Awaiting Approval (AA) by their manager ($$User.managerID)
• from their manager's perspective -- as if they could "Log In As" their manager
• prepare for questions accordingly

This approach ensures the accuracy, transparency, and real-timeliness of the information, AND (bonus marks) by focusing on the USER.ID and USER.managerID, spares the SysAdmin the effort and frustration of trying to keep up with evolving Approval Path logic.

Thank you again: this was huge win.

Regards,

Doug

[skyehansen]

thanks, it's always nice to see an evolution on original design. I'm not very experienced with exists statements combined with the AND function, so this example is nice to see as well.

I'll leave this a few days in the "questions" section but will eventually move it to "discussions"