Support has said it's not possible for reports and dashboards we share with Reviewers to include a view of all of the projects we're involved with unless we share access to each and every project.
This it means we're unable to provide a complete picture of the workload and workflow with senior leadership and stakeholders that would never be resource managers for every project that comes through our group.
Shared reports and dashboards that don't include projects are of little use to us.
This is very disappointing because this level of transparency and communication were basic expectations that influenced our decision to select Workfront as our project management resource.
Are there other ways to achieve our objective?
Topics help categorize Community content and increase your ability to discover relevant content.
Hi Rick,
Would it be possible to leverage the Report Options > "Run As" feature on the report(s) in question (i.e. so that the data returned includes all the projects that the Run As user can see), and then share that report with the the Reviewers (hmm....although as I type that, I have a hunch doing so might be verboten, from a licensing perspective...)
Regards,
Doug
Option 1 -- Doug's suggestion -- I don't see that it's breaks any rules, licensing wise. We do it a lot. The only caution being that if there's sensitive information, some thought goes into what is shared, and reports are a little more locked down so that there's no way to access any information outside of what's on the report. e.g. if the user creates a view that shows a column with sensitive information on it that wasn't in the original report view (same for filter and grouping). Oh, and the other caution that if your run-as user permissions change, the report will become useless (e.g. if they leave the company)
Option 2 -- just want to check in and see what's in Rick's head. Why exactly is it a hardship to share all the projects? Why would reviewers need to be resource managers? Does he know about Inherited Access? (i.e. As long as you give View access at the portfolio or the program level, they will see all the projects stored in the higher level object.]
Option 2.5 -- in the recent User Group meeting on system maintenance, we gave out a handout that included a list of best management practices. One is: "Set up leadership job roles per group and standardize sharing objects to them, so that if leaders come into the system they can automatically see pertinent work". As one of our strategists is fond of saying: "be kind to your future self!" Assume someone is someday going to want to see everything and you're not going to want that person to have system admin rights.
Views
Replies
Total Likes
This. We create Stakeholder Groups, Leadership Groups, (Dept) Manager group.
So on our templates, we have project sharing permissions to share access with Sales projects to the Sales Manager Group, and so on so forth. We're not sharing each individual project since it's the default on the template setup.
Views
Replies
Total Likes
I want to make sure I understand Option 2.
Would sharing at the portfolio level allow those people the portfolio is shared with to view the programs and projects in that portfolio?
Views
Replies
Total Likes
hey Rick, so here's the steps I would suggest. The summary is not to trust anything we say, and always read and test in your own system or preview environment, so I give you steps for both.
0) Search on One for "inherited permissions" and read up on this.
1) Create a test Review user in the system (or if you have one, use this account to test with). A test account usually has very little shared with it.
2) Create a Test Group or a Test Job Role and add this user to it. (we recommend this because the two objects are much less visible to other users, whereas with teams those can get assigned to work or tagged in an update
3) Share a portfolio with the test group or job role.*
4) Start testing:
4a) look at the programs in the portfolio, one by one -- who the programs are shared with -- do you see the Inherited Permissions line? Open the dropdown and see if the test account is on that list.
4b) look at the projects in that portfolio one by one -- who are these shared with -- what is on the inherited permissions line
4c) Start sharing reports with the test account and make sure they see what has been shared with them at the portfolio level even if they are not shared to the project specifically.
5) If this works for you, I would definitely escalate your helpdesk ticket to Support management with your solution. My opinion is that Support's answer was too narrow in scope, and Option 2/2.5 is a key best management practice that is common amongst customers. It's worth it to give them that feedback (what assumption you leapt to when they asked you to share all your projects, and what else they could have said to help you to understanding).
* I really recommend using this practice. Think in lines of someone who gets a temporary promotion up to be a VP and has to see everything for two months, before a replacement gets hired. You add this person to the group or role, and when they get demoted in two months, they are removed from all sharing automatically.
Thanks so much Skye. I really appreciate your insight and advice.
I'm now working with your recommendations.
Views
Replies
Total Likes
You're welcome, Rick. For other handy system maintenance tips, refer to https://one.workfront.com/s/question/0D54X00006msfHdSAI/user-group-followup-july-27-2021-workfront-s... for the recording, slides, and handouts.
Views
Replies
Total Likes
@Rick Booth‚ : "Would sharing at the portfolio level allow those people the portfolio is shared with to view the programs and projects in that portfolio?"
In theory, yes. But I'm not going to claim that I know as much as Skye or that I 100% understand what you are trying to do. I would test it, as Skye proposed.
We give our Workers view-only access to projects they are assigned a task to, and Planners view-only access to every project in the Portfolio they work under. We do not give Reviewers much access at all outside the task they are involved with; and WF may strictly limit via hard-coding what Reviewers can do (you might have to give them some form of super limited Worker access instead).
Views
Replies
Total Likes
Views
Likes
Replies