Request/Issue Team ID and user wildcard reports

[CBuckwal]

I've been trying to find other ways to create user wildcard request team reports without using the Assigned to or Assignment team as the wild card connector to report users, since I'm finding that requests may occasionally be unassigned. So far, I've tried issue reports. I tried Issue-Team ID with wildcard user teams, but that doesn't return results. When I try Issue-Team ID as a column, the Team ID results are blank in the report. 

Resolve Project-Home Group or Resolve Task-Home Group doesn't work either to get data in a column and due to this, I'm not sure if it's worth the text mode time to pull resolve group ID into the report since it doesn't seem like it will work based on the empty report columns for the resolve project/task home group. I would appreciate any ideas to connect requests to user wild card team/group in this report?  Thanks

[skyehansen · Accepted solution]

Based on your filter screenshot, Issue / Team ID works for me as long as I am searching for requests where only one team is assigned, and as long as that team is my home team.

If I was looking for "any of my many teams" $$USER.teamIDs would be a better fit.

If there are multiple teams being assigned to the request, you should consider using Assignment Teams / ID instead.

[CBuckwal]

Thanks, Skye. For some reason, I wasn't connecting that Issue Team ID refers to the request assigned team. All clear now.

[CBuckwal]

Is there text mode to also show the request team group? I have reports for program and portfolio managers that need to see the requests but they aren't on the request team but are associated with the request team group ID, which I could use as a wildcard if I can surface it. 

I've tried {team}.{group}.{ID} and {team}.{groupID} and {opTask}.{team}.{groupID} on a request calculated field but it isn't getting any results.

[skyehansen]

From my previous response, you hopefully picked up that I am not clear what you mean by the "request team", and it'll be difficult to answer any additional questions based on the initial ambiguity.

I can separately address your calculated field question -- did you catch my response to a different question about toggling the "apply" checkbox in the calculated field?

https://experienceleaguecommunities.adobe.com/t5/workfront-questions/reporting-on-task-completion/td...

[CBuckwal]

When I'm referring to the request team, I mean the issue-team ID, which you noted in an earlier response. Sorry for not being more clear. In our set up the issue-team ID correlates to the queue topic routing rule default team. I was trying to pull out the group ID associated with the queue topic request/issue-team ID and use that group ID to match as a user group wildcard in a report. I did find text mode that worked to show the group ID, but the resulting group ID couldn't be matched with a user wild card team in reports. The report filter didn't recognize the calculated field ID I guess and the filter options didn't offer a user wild card option. 

{queueTopic}.{defaultRoute}.{defaultTeam}.{groupID}

When running audit reports, I'm finding that requests are sometimes unassigned and if that's the case, these requests won't show up on my user wildcard reports that I currently have filtered for assigned to and assigned teams matching user teams. So to account for that I'm going to add the teams ID as a filter but that doesn't cover all report options when I'm creating a wildcard report for a high level manger who isn't assigned to the work teams.  

[skyehansen]

I'm not sure I'm clear on this, but I'm definitely getting MORE clear! So would you say your problem statement is:

* queue requests are assigned to a team via routing rule

* requests then need to be assigned to a human from this team in order to populate reports keyed to this user

* this second step isn't happening reliably so a number of cleanup reports need to be created for high level managers who manage multiple teams, related through the group attribute 

I guess my initial other 2 questions would be

1) who is failing to assign a human to a request for any one team?

2) what relationship does the group bear to the high level manager (is it a home group or any one of their groups?)

[CBuckwal]

Your three problem statement bullet points are all accurate for my instance. Non-assignment isn't a huge problem now, but we're soon onboarding a very large group with multiple intake workstreams, so I'm trying to cover all the bases and make sure that no requests go missing if an assignment is missed. The group's director wants to see all the reporting, but he won't be on all the teams, but will be in all the groups. 

Intake managers remove the request team assignment and assign users. Occasionally, I think they remove the team assignment and either forget or aren't sure who to assign. Reminders and re-education on this can be done. 

Higher level managers in my system always have all the groups that their direct reports and further down the reporting chain have. Matching groups in wild card reports is much more reliable for me since all high level managers have all the same groups as those below them in the reporting chain. 

[skyehansen]

OK sounds like your problem statement was incomplete but your last response has clarified. You should split the third bullet point into two.

* this second step isn't happening reliably so a number of cleanup reports need to be created for high level managers who manage multiple teams, related through the group attribute 

* Additionally intake managers are accidentally removing the team. So we need a way to see what the team's groupID is, when there's actually no team anymore.

The above final bullet is probably why you might have started down the path of queue topic's routing team's group ID -- which is (1) great thinking and (2) nothing wrong with your syntax. But also doesn't appear to be acceptable to calculated expressions on a calculated field. Good try, though!

Instead, I would say you should pivot and experiment with partly going back to your original thinking.

A) forget about the issues with missing assigned teams for now. This is a cleanup effort you'll need to tackle separately.

B) set it up on your custom form so it never happens again. A calculated field like "IF(ISBLANK({DE:TeamGroup}),{team}.{groupID},{DE:TeamGroup})" would permanently stamp the initial assigned team's groupID into your custom form for future submitted requests from this point on.

C) Set up your high level manager reports based on filtering for your new calculated TeamGroup field.

[CBuckwal]

Thanks for all the help. I set up the calculated field 

IF(ISBLANK({DE:FDN Request Team Group}),{team}.{groupID},{DE:FDN Request Team Group})

on the custom form and it stamps the group ID on the form. But when I go to filter on the FDN Request Team Group field in a report, I still don't have the option to use the user wildcard group filter to match the group ID from the calculated field. The FDN Request Team Group filter field shows all choices (contains, does not contain and equal choices). Even choosing equal, the wild card user group choices aren't accepted.  Am I still missing something? Thanks

[skyehansen]

what happens when you put it in manually via text mode?

[CBuckwal]

Manual text mode in an issue report, using the calculated field DE:FDN Request Team Group to stamp group ID on the custom form

DE:FDN Request Team Group=$$USER.otherGroupIDs

DE:FDN Request Team Group_Mod=in

Once I remembered to add the DE: before my custom field, the report runs great! Thanks for the all the help.