Why does my report that is "grouped" by project owner not showing all their projects in same place?

[TegwynSt]

On dashboard, I have to open all 304 projects then they show up together.

One user has 6 projects....but on dash you only see 5....less handy view if you have to continuously open it.....and it's not at like a page break and its happening for many of them....???? odd right?

[SarahNa]

Hi Tegwyn,

This is normal behavior unfortunately - you could sort by project owner and see if that helps? If you want all projects to be listed, the only other option is to change the setting on your report to show all on a dashboard, but that is a lot of projects to show. Seeing all 304 projects may also be overwhelming to users - you could use a wild card filter for project owner = $$USER.ID and only show the projects that the signed-in user owns.

Hope this helps!

[TegwynSt]

Thank you @Sarah Nau‚

the report is supposed to help everyone on team see everyone's work....and not have to mess with filters etc.

I see in new experience that you can set default for groupings to collapse (I believe) - that would be great usage here.

I have created $$USER.ID reports for them also....just...what's the point of grouping if they don't in fact "Group" - seems like unusual behavior? I group by other columns and don't seem to have this issue...what makes just one of the projects they own land somewhere else?

[SarahNa]

When the project list spans multiple pages, the grouping only works for what is shown on the page. Would a chart of projects work? Then users can easily click into the pie segment or bar chart line to see all of the projects for that individual.

[TegwynSt]

I got a solve ---it is a $$USER.ID on the report --which works well

I like this chart idea too though ---think they'd like to see that as another view

TY 😀

[SarahNa]

Glad you found something that works for you!

[CalvinFold]

I wish I could think of a way to suggest to WF how to resolve this UI issue. I think the time I've spent explaining and re-explaining this grouped-by-page behavior to co-admins, users, etc. probably adds up to weeks by now.

It's especially a problem in Dashboards where "View All" is not an option. Which means pre-grouping is often invalidated as way to cut through the clutter on a dashboard.

Then if they go the extra mile to click open a specific report on the dashboard (which few do), they still have to remember to "View All' to make groups work.

Hoping NWE has tools to help? (We're on Classic for a while longer yet.)

[SarahNa]

Hi Kevin - I'm in NWE, same issue...

[TegwynSt]

I have not really used the $$USER.ID as a filter on a dash report, I use it for report itself but proving handy here....most of the users want to see all their own stuff so just click of a carrot and only view "shared" with them...but for their director....well, I might just create a view filter by "region" on same report and....

I'm just so happy I got a calculated field on here that tech support was not able to provide...I shared with them thanks again @Narayana Raum

[Matt-Thomas]

Thank you for sharing this use case with us and the pain associated with it. We can definitely see why this would be frustrating to have only the items on the page being grouped instead of it getting all the projects for each group. Some of you may be aware, but we are in the process of building the next iteration of reporting. In the new version issues like this will not exist because of major enhancements to the back end architecture and similar enhancements on the front end. If you would like some time to walk through this initiative or provide more feedback please schedule some time with me https://calendly.com/matt-thomas-wf/30min.

Thanks!

Matt Thomas

Workfront PM - Reports and Dashboards

[CalvinFold]

Not sure to whom your offer was extended to, but I took you up on it. I can likely show some examples if you need them.

Hours reports right now are the big PITA…we easily have 10,000+ hours records for all subordinates under a given Director for a fiscal quarter. Groups (and subgroups) fail miserably, and we can't really filter it down any farther. So we resort to export and dealing with it in Excel; a bit time sink.

I get why View All for 10,000+ records presents an issue, but at the same time, the "2000 per page" is a major problem.